RPC is a protocol that allows your application to communicate with blockchain nodes. When you want to check an account balance, read smart contract data, or send a transaction, your application makes an RPC call to a blockchain node.

Common RPC Methods:

• eth_blockNumber: Get the latest block number
• eth_getBalance: Check an address's balance
• eth_call: Read data from a smart contract
• eth_sendRawTransaction: Submit a signed transaction
• eth_getLogs: Query event logs

Example RPC Request:

When you connect your wallet to Uniswap and check your token balance, the dApp makes an RPC call like:

{
  "jsonrpc": "2.0",
  "method": "eth_call",
  "params": [{
    "to": "0xA0b86991...",
    "data": "0x70a08231..."
  }, "latest"],
  "id": 1
}

This request asks the blockchain: "What's the USDC balance at this address?"

Different providers offer different features, pricing, and performance characteristics. Here's what matters:

Alchemy:

• Strengths: Enhanced APIs, NFT API, webhooks, best-in-class debugging tools
• Free Tier: 300M compute units/month
• Best For: Production apps needing advanced features
• Unique Features: Notify API for real-time webhooks, NFT API for metadata

Infura:

• Strengths: Industry standard, excellent reliability, IPFS integration
• Free Tier: 100k requests/day
• Best For: Teams wanting battle-tested infrastructure
• Unique Features: Integrated IPFS gateway, gas price API

QuickNode:

• Strengths: Ultra-low latency, global infrastructure, dedicated nodes
• Free Tier: Limited free plan
• Best For: Applications requiring maximum performance
• Unique Features: Token API, marketplace for add-ons

Ankr:

• Strengths: Decentralized, free public RPCs, multi-chain support
• Free Tier: Public endpoints (rate limited)
• Best For: Budget-conscious projects, testing
• Unique Features: Decentralized node network, staking integration

Cost Comparison (Ethereum Mainnet):

• Free tiers: Good for development and small apps (1-10k daily users)
• Paid plans: Typically $50-500/month for mid-sized apps (10k-100k daily users)
• Enterprise: Custom pricing for high-volume applications (100k+ daily users)

Your infrastructure choice depends on several factors:

Development Stage:

• Prototyping: Use free public RPCs (Ankr, public endpoints)
• Testing: Free tiers from Alchemy or Infura
• Production: Paid plans with guaranteed uptime and support

Application Type:

• NFT Projects: Alchemy (NFT API), Moralis (NFT indexing)
• DeFi: QuickNode (low latency), Alchemy (webhooks for events)
• Multi-chain: Ankr, Moralis (broad chain support)
• Historical Data: Providers with archive nodes (Alchemy, QuickNode)

Budget Considerations:

• Start with free tiers during development
• Monitor usage before committing to paid plans
• Consider decentralized options (Ankr, Pocket Network) for cost savings
• Use multiple providers for redundancy (discussed later)

Performance Requirements:

• Geographic distribution of your users
• Latency requirements (trading bots need sub-100ms)
• Request volume (requests per second)
• Data freshness (how recent does data need to be?)

Running a blockchain node gives you maximum control and privacy, but it's resource-intensive.

Node Types:

• Full Node: Stores recent blockchain state (~500GB for Ethereum)
• Archive Node: Stores complete historical state (~12TB+ for Ethereum)
• Light Client: Minimal storage, relies on full nodes for data

Hardware Requirements (Ethereum Full Node):

• CPU: 4+ cores
• RAM: 16GB+ (32GB recommended)
• Storage: 2TB+ SSD (must be fast)
• Network: Stable connection, 25+ Mbps
• Cost: ~$100-300/month for cloud hosting

When to Run Your Own Node:

• You need guaranteed uptime and control
• Privacy is critical (hiding which addresses you query)
• High request volume makes providers expensive
• You're building infrastructure for others
• Educational purposes (understanding the protocol)

When NOT to Run Your Own Node:

• Just getting started with Web3 development
• Building a consumer application (use providers instead)
• Need multi-chain support (running nodes for 10+ chains is impractical)
• Limited DevOps resources for maintenance

Node-as-a-Service providers give you dedicated nodes without the operational overhead.

QuickNode Dedicated Nodes:

• Provision a dedicated node in minutes
• Choose your region for optimal latency
• Full or archive node options
• Add-ons for tracing, debugging, NFT data
• Pricing: $50-500+/month depending on chain and features

Chainstack:

• Enterprise-focused node infrastructure
• Multi-cloud deployment (AWS, GCP, Azure)
• Compliance and security features
• Support for consortium chains
• Custom SLAs available

Use Cases for Dedicated Nodes:

• High-Volume Applications: When shared RPC is rate-limited
• MEV/Trading: Minimize latency for competitive applications
• Privacy: Your queries don't mix with others
• Custom Configuration: Special node settings or modules

Blockchain data is optimized for security and decentralization, not for queries. If you need to find "all NFTs owned by this address" or "all swaps on Uniswap in the last hour," querying raw blockchain data is slow and expensive.

The Graph - Decentralized Indexing:

The Graph indexes blockchain data using GraphQL APIs called subgraphs. Instead of scanning millions of blocks, you query an indexed database.

Example: Querying Uniswap Swaps

query {
  swaps(
    first: 10
    orderBy: timestamp
    orderDirection: desc
    where: { pair: "0x...", amount0: { gt: "1000000" } }
  ) {
    transaction { id }
    timestamp
    amount0In
    amount1Out
  }
}

This query would take hours to execute via raw RPC calls. With The Graph, it returns in milliseconds.

Building a Subgraph:

1. Define your data schema (what entities to track)
2. Write mapping code (how to process events)
3. Deploy to The Graph's decentralized network
4. Query using GraphQL from your dApp

Cost: Free for queries, pay GRT tokens for indexing on decentralized network

Several providers offer ready-made APIs for common blockchain data needs.

Moralis:

• NFT API: Get NFT metadata, ownership, transfers
• Token API: Price data, balances, transfers
• Wallet API: Complete transaction history for addresses
• Use Case: Quickly build NFT galleries, portfolio trackers
• Pricing: Free tier: 40k compute units/month

Alchemy NFT API:

• Comprehensive NFT metadata
• Ownership tracking
• Floor prices and sales data
• Spam detection for NFT collections

Covalent:

• Unified API across 100+ blockchains
• Historical balance data
• Portfolio tracking
• DeFi positions

When to Use High-Level APIs:

• Rapid prototyping (get to market faster)
• Common use cases (NFT galleries, wallet views)
• Multi-chain applications (avoid integrating 10+ different RPCs)
• Team lacks blockchain expertise (APIs abstract complexity)

Trade-offs:

• Pros: Faster development, less code, maintained by provider
• Cons: Less flexibility, vendor lock-in, potentially higher cost at scale

IPFS is a peer-to-peer network for storing and sharing files. Instead of location-based addressing (URLs), IPFS uses content-based addressing (CIDs).

How IPFS Works:

1. Upload a file to IPFS
2. Receive a unique CID (Content Identifier): Qm...
3. Anyone can retrieve the file using its CID
4. File content is cryptographically verified

Example - NFT Metadata:

Instead of storing an image URL on-chain:

"image": "https://myserver.com/nft/1.jpg"

You store an IPFS CID:

"image": "ipfs://QmYHj7..."

Benefits:

• Immutability: Content can't be changed (CID would change)
• Decentralization: No single point of failure
• Permanence: As long as someone pins it, it exists

Challenges:

• Pinning: Files disappear if no one hosts them
• Speed: Slower than centralized storage (CDN)
• Gateways: Often accessed via HTTP gateways (centralization risk)

IPFS Pinning Services:

• Pinata: $20/month for 1GB pinned storage
• NFT.Storage: Free for NFT data (Filecoin-backed)
• Web3.Storage: Free tier (Filecoin-backed)
• Infura IPFS: Integrated with their RPC service

Best Practices:

1. Always pin important content
2. Use multiple pinning services for redundancy
3. Consider hybrid approach (IPFS + CDN)
4. Include CID in blockchain records for verification

IPFS requires active pinning to keep files available. For truly permanent storage, consider these alternatives:

Arweave - Pay Once, Store Forever:

Arweave offers permanent storage with a one-time payment. The protocol economically incentivizes miners to store data perpetually.

• Pricing: ~$2 for 1MB (one-time payment)
• Use Cases: NFT metadata, historical records, archives
• Access: Via HTTP gateway or native protocol
• Guarantee: 200+ year storage endowment

How It Works:

1. Pay upfront storage fee (based on file size)
2. Miners store your data to earn block rewards
3. Economic incentives ensure long-term storage
4. Access data via content addressing

Example - Storing NFT Metadata:

// Upload to Arweave
const transaction = await arweave.createTransaction({
  data: JSON.stringify(metadata)
});

await arweave.transactions.sign(transaction);
await arweave.transactions.post(transaction);
// Transaction ID is permanent reference
const url = https://arweave.net/${transaction.id};

Filecoin - Decentralized Storage Market:

Filecoin creates a marketplace for storage. Storage providers compete on price and reliability.

• Pricing: Market-driven, very cheap (~$0.000002 per GB per day)
• Use Cases: Large datasets, backups, archives
• Deals: Negotiate storage deals with providers
• Verification: Cryptographic proofs ensure data is stored

NFT.Storage & Web3.Storage:

These services provide free IPFS and Filecoin storage for Web3 applications, backed by Protocol Labs.

• Upload files via simple API
• Automatically pinned to IPFS
• Backed up on Filecoin
• Free for public data

Choosing a Storage Solution:

• NFTs: Arweave or NFT.Storage (permanence matters)
• Application Data: IPFS with pinning (fast access)
• Archives: Filecoin (cost-effective for large data)
• Hybrid: IPFS for hot data, Filecoin for cold storage

Traditional push notifications require centralized servers and user contact information. Web3 needs a decentralized alternative.

Push Protocol (formerly EPNS):

Push Protocol enables wallet-to-wallet notifications without exposing email or phone numbers.

How It Works:

1. DApp creates a "channel" on Push Protocol
2. Users opt-in to receive notifications from the channel
3. DApp sends notifications to subscribers via Push Protocol
4. Users receive notifications in Push-enabled apps

Use Cases:

• DeFi Alerts: "Your loan is near liquidation"
• Governance: "New proposal available for voting"
• Social: "Someone followed you on Lens Protocol"
• NFT: "You received an offer on your NFT"
• Gaming: "Your match is starting"

Integration Example:

// Send notification to a user
await PushAPI.payloads.sendNotification({
  signer,
  type: 3, // targeted notification
  identityType: 2, // direct to wallet
  notification: {
    title: 'Loan Alert',
    body: 'Your health factor is below 1.5'
  },
  payload: {
    title: 'Loan Alert',
    body: 'Consider adding collateral to avoid liquidation',
    cta: 'https://app.example.com/positions/123'
  },
  recipients: '0xuser_wallet_address'
});

Benefits:

• No email/phone collection
• User controls their notifications
• Encrypted and decentralized
• Cross-platform (mobile, web, extension)

Web3 social and communication features need messaging protocols that work across applications.

XMTP - Extensible Message Transport Protocol:

XMTP enables wallet-to-wallet messaging with end-to-end encryption.

Key Features:

• Wallet-Native: Messages tied to Ethereum addresses
• E2E Encrypted: Only sender and recipient can read messages
• Portable: Messages follow you across apps
• Composable: Any app can integrate XMTP

Use Cases:

• NFT Marketplaces: Buyers and sellers negotiate
• DAOs: Member communication
• Social Apps: Decentralized Twitter DMs
• Customer Support: Protocol support channels

Integration Example:

import { Client } from '@xmtp/xmtp-js';

// Initialize client with user's wallet
const client = await Client.create(wallet);
// Start conversation
const conversation = await client.conversations.newConversation(
  '0xrecipient_address'
);
// Send message
await conversation.send('Hello from my dApp!');
// List conversations
const allConversations = await client.conversations.list();
// Stream new messages
for await (const message of await conversation.streamMessages()) {
  console.log(New message: ${message.content});
}

Comparison:

• XMTP: Direct messaging, E2E encrypted, wallet-based
• Push Protocol: Notifications and announcements, channel-based
• Together: Use Push for broadcasts, XMTP for conversations

Traditional application monitoring tools don't work well for blockchain applications. You need specialized tools that understand smart contracts and on-chain events.

Tenderly:

Tenderly provides simulation, monitoring, and debugging for smart contracts.

Key Features:

• Transaction Simulation: Test transactions before sending
• Debugger: Step through failed transactions
• Monitoring: Real-time alerts on smart contract events
• Analytics: Gas usage, function calls, state changes
• Alerts: Get notified of anomalies

Use Cases:

• Debug Failed Transactions: See exactly where and why a transaction failed
• Gas Optimization: Identify expensive operations
• Security Monitoring: Alert on suspicious activity
• Testing: Simulate complex scenarios

Example - Simulating a Transaction:

// Simulate a swap before executing
const simulation = await tenderly.simulator.simulateTransaction({
  from: userAddress,
  to: uniswapRouter,
  input: swapCalldata,
  value: 0
});

if (simulation.status) {
  // Success - proceed with real transaction
} else {
  // Failed - show user why it would fail
  console.error(simulation.error);
}

Other Monitoring Tools:

• Alchemy Monitoring: Request analytics, error tracking
• Blocknative: Mempool monitoring, gas price predictions
• OpenZeppelin Defender: Security-focused monitoring and alerts

Proactive alerting helps you catch issues before users complain.

Critical Alerts to Configure:

1. RPC Errors: Alert if error rate > 5%
2. Gas Spikes: Notify when gas prices exceed threshold
3. Failed Transactions: Track failed transaction rate
4. Smart Contract Events: Monitor critical contract interactions
5. Balance Alerts: Notify when hot wallet balance is low
6. Security Events: Alert on unusual admin calls or suspicious transfers

Example Alert Configuration (Tenderly):

// Monitor a lending pool for liquidations
const alert = await tenderly.alerts.create({
  name: 'Large Liquidation Alert',
  network: 'mainnet',
  contractAddress: lendingPoolAddress,
  eventSignature: 'LiquidationCall(...)',
  conditions: [
    {
      parameter: 'debtToCover',
      operator: 'GREATER_THAN',
      value: '100000000000000000000000' // 100k USDC
    }
  ],
  actions: [
    { type: 'WEBHOOK', url: 'https://api.example.com/alerts' },
    { type: 'EMAIL', email: 'team@example.com' },
    { type: 'SLACK', webhook: slackWebhookUrl }
  ]
});

Alerting Best Practices:

• Start with critical alerts only (avoid alert fatigue)
• Set appropriate thresholds (too sensitive = noise)
• Use multiple channels (Slack, PagerDuty, email)
• Include runbook links in alerts
• Test alerts regularly
• Review and adjust based on false positives

Never rely on a single infrastructure provider. Even the best services have outages.

Multi-Provider Strategy:

// Fallback provider configuration
const providers = [
  new JsonRpcProvider(alchemyUrl),     // Primary
  new JsonRpcProvider(infuraUrl),      // Fallback 1
  new JsonRpcProvider(ankrUrl)         // Fallback 2
];

class FallbackProvider {
  async request(method, params) {
    for (const provider of this.providers) {
      try {
        return await provider.send(method, params);
      } catch (error) {
        console.error(Provider failed: ${error});
        // Try next provider
      }
    }
    throw new Error('All providers failed');
  }
}

Load Balancing:

• Distribute requests across multiple providers
• Implement retry logic with exponential backoff
• Track provider health and route around failures
• Use different providers for different chains

Circuit Breaker Pattern:

class CircuitBreaker {
  constructor(provider, threshold = 5) {
    this.provider = provider;
    this.failureCount = 0;
    this.threshold = threshold;
    this.state = 'CLOSED'; // CLOSED, OPEN, HALF_OPEN
  }

  async request(method, params) {
    if (this.state === 'OPEN') {
      throw new Error('Circuit breaker is OPEN');
    }
try {
  const result = await this.provider.send(method, params);
  this.onSuccess();
  return result;
} catch (error) {
  this.onFailure();
  throw error;
}

  }
  onSuccess() {
    this.failureCount = 0;
    this.state = 'CLOSED';
  }
  onFailure() {
    this.failureCount++;
    if (this.failureCount >= this.threshold) {
      this.state = 'OPEN';
      // Reset after timeout
      setTimeout(() => this.state = 'HALF_OPEN', 60000);
    }
  }
}

Infrastructure costs can grow quickly as your application scales. Here's how to optimize:

Caching Strategy:

// Cache blockchain data that doesn't change
const cache = new Map();

async function getTokenMetadata(tokenAddress) {
  const cacheKey = metadata:${tokenAddress};
  // Check cache first
  if (cache.has(cacheKey)) {
    return cache.get(cacheKey);
  }
  // Fetch from blockchain
  const metadata = await fetchFromBlockchain(tokenAddress);
  // Cache indefinitely (metadata doesn't change)
  cache.set(cacheKey, metadata);
  return metadata;
}
// For changing data, use TTL
async function getTokenPrice(tokenAddress) {
  const cacheKey = price:${tokenAddress};
  const cached = cache.get(cacheKey);
  if (cached && Date.now() - cached.timestamp < 60000) {
    return cached.data; // Cache for 1 minute
  }
  const price = await fetchPrice(tokenAddress);
  cache.set(cacheKey, { data: price, timestamp: Date.now() });
  return price;
}

Request Batching:

// Instead of 10 separate calls
const balances = await Promise.all(
  tokens.map(token => provider.getBalance(token))
);

// Batch into single call
const multicall = new Multicall(provider);
const balances = await multicall.aggregate([
  tokens.map(token => ({
    target: token,
    callData: erc20.encodeFunctionData('balanceOf', [address])
  }))
]);

Optimize Query Frequency:

• Don't poll for updates every second if every 10 seconds is fine
• Use webhooks instead of polling (Alchemy Notify, Push Protocol)
• Implement exponential backoff for retries
• Aggregate user requests (don't fetch same data multiple times)

Choose Appropriate Data Sources:

• Static Data: Fetch once, cache forever (token metadata)
• Slow-Changing: Cache with long TTL (30m-1h) (TVL data)
• Real-Time: Use websockets, not polling (price feeds)
• Historical: Use The Graph or indexer, not raw RPC (past events)

Monitor and Alert on Costs:

• Set up billing alerts with providers
• Track compute unit usage weekly
• Identify expensive queries and optimize them
• Consider switching chains for lower gas fees (L2s)

Free Tier Optimization:

• Use multiple free accounts (for different environments)
• Combine free tiers from different providers
• Use public RPCs for non-critical read operations
• Upgrade to paid only when you hit limits consistently