Web3 API Essentials: How Dapps Talk to Chains in 2025

In 2025, production-grade dapps are powered by a Web3 API stack that's not just richer and faster but also way more standardized than it was just a year back. This guide breaks down the key changes (and why they’re important) and gives you real, actionable patterns you can implement right now for reads, writes, indexing, real-time delivery, and reliability.

TL;DR (description)

Ethereum’s Dencun (EIP‑4844) and evolving standards like EIP‑1193/6963 have totally revamped the API landscape that dapps rely on every day. At the same time, decentralized RPCs and indexing pipelines--like The Graph Substreams and QuickNode Streams--are now offering data that’s not only exactly-once but also aware of reorgs. This post is packed with practical implementation tips, a look at provider trade-offs, handy code snippets, and best practices that are ready for 2025.

---

1) What actually changed since 2024

• Blob transactions are officially live on the mainnet as of March 13, 2024, thanks to EIP‑4844 via Dencun! These transactions introduce type‑3 "blob" transactions, which come with some cool new features for blob gas pricing and commitments. This means you can expect a significant drop in L2 data costs. Just a heads-up: your tools, fee logic, and transaction builders need to get acquainted with maxFeePerBlobGas and blobVersionedHashes. Check it out here: (theblock.co)
• Block tags are now safer than ever! With EIP‑1898, many JSON‑RPC methods now accept “safe” and “finalized” block tags. These are your go-to options when you need to prioritize accuracy over speed, like in settlements or finance. Find more details here: (eips.ethereum.org)
• Integrating front-end wallets and providers just got a lot smoother! EIP‑1193 lays out a basic request/event framework while EIP‑6963 helps with discovering multiple injected providers, which should help eliminate those annoying wallet-extension conflicts. Make sure your app is on board with both! More info can be found here: (eips.ethereum.org)
• Fee APIs have expanded their horizons. The eth_feeHistory function is the go-to for setting EIP‑1559 fees, and if you’re working on chains with blobs, you’ll also find baseFeePerBlobGas and blobGasUsedRatio showing up in your responses. Dive deeper here: (quicknode.com)
• The Graph has officially sunset its Hosted Service in 2024 and transitioned core activities over to Arbitrum. On top of that, Substreams/Firehose have improved with new chains and enhanced performance. If you're still relying on the old hosted endpoints, it’s time to catch up! Check out the update here: (thegraph.com)

What this means for you is that your API layer should have fee logic that's clued into EIP-4844 and EIP-1559, along with “safe/finalized” reads when necessary. You’ll also want to focus on modern wallet discovery and make sure your indexing and streaming can cope with reorgs and high throughput.

---

2) The API surface you actually use (and how to use it safely)

• When you’re doing reads (like eth_call, eth_getBalance, eth_getCode, eth_getStorageAt), make sure to include a block parameter. You can choose from:
  • A specific blockHash or block number (just follow the object format in EIP‑1898), or
  • Use the “safe” or “finalized” tags to get consistent and reliable results. Check it out here: (eips.ethereum.org)

Example: check out a contract's state at the last finalized block:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_call",
  "params": [
    { "to": "0xYourContract", "data": "0xabcdef..." },
    { "blockTag": "finalized" }
  ]
}

• When it comes to logs (eth_getLogs), there are some practical limits you should be aware of. Providers set caps on both block ranges and payloads, so it's a good idea to design your crawlers to be paginated and incremental:
  • QuickNode: On paid plans, you can work with a range of up to 10,000 blocks (but it’s only 5 blocks on free trials). For more info, check out their documentation.
  • Chainstack: Depending on your plan, you can get anywhere from 100 to 10,000 blocks. They also have some recommended ranges based on the network, like 5,000 for Ethereum and 3,000 for Polygon. Take a look at their guidelines.
  • Alchemy: They specify ranges for each chain and keep responses capped at 150MB. You can find the details in their docs.

Paginated getLogs (illustrative):

Here's a quick look at how to handle paginated logs using the getLogs function. This function is super useful when you're dealing with a ton of logs and need to fetch them in smaller, more manageable chunks.

Example Code

async function getPaginatedLogs(page = 1, limit = 10) {
    const response = await fetch(`/api/logs?page=${page}&limit=${limit}`);
    const data = await response.json();
    
    return data.logs;
}

// Usage
const logs = await getPaginatedLogs(1, 10);
console.log(logs);

Explanation

• Function Parameters:
  • page: This is the current page number you're fetching. It defaults to 1 if you don't provide one.
  • limit: This defines how many logs you want to fetch per page. You're looking at 10 by default here.
• Fetch Logs: The function hits the API endpoint to grab logs based on the supplied page and limit.
• JSON Response: After fetching, it converts the response into JSON and grabs the logs from the data.

With this setup, you can easily navigate through your logs page by page! Happy coding!

async function* rangeLogs(client, filter, from, to, step=5000) {
  for (let start = from; start <= to; start += step) {
    const end = Math.min(start + step - 1, to);
    const logs = await client.request({
      method: 'eth_getLogs',
      params: [{...filter, fromBlock: `0x${start.toString(16)}`, toBlock: `0x${end.toString(16)}`}]
    });
    yield logs;
  }
}

• Gas fees (EIP‑1559 & blobs). To figure out a tip (priority fee), you can use eth_feeHistory and set your maxFee. If you're working with blob-chains, don't forget to calculate maxFeePerBlobGas too. Check it out here: (eips.ethereum.org)

---

3) Sending transactions in a post‑4844 world

• So, Type‑3 blob transactions come with a few key components:
  • max_fee_per_blob_gas (that's a uint256, by the way)
  • blob_versioned_hashes (which are KZG commitment hashes)
  • Just a heads up, you can't create contracts with these, so you must use a 20‑byte address. (eips.ethereum.org)
• When you're working with eth_sendRawTransaction, remember that the network form has to include the payload body along with blobs, commitments, and proofs. Make sure your SDK is set up to handle this properly! (docs.web3j.io)

Minimal Build (Pseudocode):

Here's a simple way to tackle a minimal build.

// Define the main function
function main() {
    initializeProject(); // Step 1: Initialize your project
    configureSettings();  // Step 2: Set up your settings
    buildProject();       // Step 3: Build your project
    runTests();          // Step 4: Run any tests you've set up
    deploy();            // Step 5: Deploy the build
}

// Initialize the project
function initializeProject() {
    // Your code here for initialization
}

// Configure settings
function configureSettings() {
    // Code to configure settings
}

// Build the project
function buildProject() {
    // Code to build the project
}

// Run tests
function runTests() {
    // Code to run tests
}

// Deploy the build
function deploy() {
    // Code to deploy
}

// Start the main process
main();

This structure should help you keep things clean and organized while you work on your minimal build. Each function has a specific job, making the whole process smoother and easier to manage!

// Outline: set EIP-1559 (maxFeePerGas, maxPriorityFeePerGas)
// and EIP-4844 fields (maxFeePerBlobGas, blobVersionedHashes)
const tx = {
  type: '0x03',
  chainId,
  to: L2BatchPoster,
  maxPriorityFeePerGas,
  maxFeePerGas,
  gas: 250000,
  data: postCalldata,
  maxFeePerBlobGas,
  blobVersionedHashes: [hash1, hash2],
  accessList: []
};
// Sign & sendRawTransaction with SDK that supports blob sidecars.

Operational note: Blobs communicate through the consensus client sidecar, so execution clients only get to see the references. Make sure your monitoring connects the transaction receipts with the blob sidecar stats (like blob_gas_used and excess_blob_gas found in the headers). You can read more about it here.

---

4) Real‑time data: WebSockets, webhooks, and “exactly‑once”

• Just a heads-up: eth_subscribe is only available through WebSocket, so you'll want to use it for things like new heads, logs, or pending transactions. Some providers might throw in their own twists and even limit certain subscriptions, so it's a good idea to check their documentation. (geth.ethereum.org)
• When it comes to scalability, push notifications are way better than polling. QuickNode Webhooks give you serverless, filter-based, and reorg-safe push notifications. Plus, their Streams feature ensures you get exactly-once delivery in the order of finality, along with historical backfills and traces. These tools are perfect for building trading bots, wallets, and all sorts of analytics. (blog.quicknode.com)

Key Implementation Detail

Make sure to set up reorg handling and sequential processing on your destination. Streams will hold off on advancing until your system confirms that the delivery happened. This approach helps maintain consistency. Check it out here: (quicknode.com)

---

5) Indexing and analytics: Subgraphs, Substreams, and where The Graph is now

• The Graph’s Hosted Service is no longer in action as of June 12, 2024. Now, all queries are running on the decentralized network, and a bunch of network operations, including rewards, have shifted to Arbitrum in 2024 to help save on costs and speed things up. Check it out here.
• Substreams + Firehose, brought to you by StreamingFast, are shaking things up big time! We're talking about high-throughput, stream-first indexing with new chains rolling out through 2025. The latest updates have introduced Substreams RPC v3 and added some cool sinks (think SQL with nested message support). If you're still crafting indexers from scratch, seriously consider giving Substreams a shot first. More details can be found here.

Tip: Utilize Substreams for Heavy Lifts

When it comes to doing heavy-duty tasks like DEX swaps, managing total value locked (TVL), or handling multi-contract joins, consider using Substreams. They’re perfect for these kinds of operations!

Here’s the deal: keep a lightweight API exposed to your app. This way, your subgraphs can focus on providing flexible queries, while Substreams handle the heavy lifting for better throughput.

---

6) Wallets, smart accounts, and Account Abstraction (ERC‑4337)

• ERC-4337 introduces some cool features like UserOperations, an alternative mempool, and an on-chain EntryPoint. This opens the door for gas sponsorship (thanks to paymasters), session keys, and a seamless user experience without needing any tweaks to the Layer 1 protocols. Check it out here: (docs.erc4337.io)
• Here's what we should aim to standardize in 2025:
  • Bundler RPC, which includes eth_sendUserOperation, estimateUoGas, and getUserOperationReceipt.
  • Paymasters that allow for gas sponsorship or ERC-20 payments for gas.
  • Modular smart accounts (ERC-6900) that enable plugins, including features like multi-owner setups and session keys. Dive deeper here: (docs.erc4337.io)

Production options:

• Alchemy Account Kit (v4) comes with some cool stuff like audited Light/Modular Accounts, a Rundler (that’s a Rust bundler), and a Gas Manager packed with enterprise tools. Plus, it's got EIP‑1193/viem compatibility baked in. Check it out here: (alchemy.com)
• Pimlico brings you public test bundlers along with verifying/ERC‑20 paymasters. Just remember to look into those rate limits and surcharges when you're in production. For more info, head over to: (docs.pimlico.io)
• Biconomy provides sponsorship options and ERC‑20 paymasters, complete with dashboard “gas tanks”. They’ve also got SDK methods that make getting fee quotes easier. Find out more at: (docs.biconomy.io)

Minimal Bundler Client (Pimlico Public)

The Minimal Bundler Client, often referred to as Pimlico public, is designed to streamline your development process. Here’s what you need to know:

Features

• Lightweight: This client is focused on minimalism, so you won’t find unnecessary bloat.
• Easy to Use: With a simple interface, you can quickly get started without a steep learning curve.
• Fast Performance: Optimized for speed, it helps you bundle your projects efficiently.

Getting Started

To get up and running with Pimlico, follow these steps:

1. Installation: To install, just run:

   npm install pimlico

2. Setup: Create a basic configuration file, like so:

   // pimlico.config.js
   module.exports = {
     entry: './src/index.js',
     output: {
       filename: 'bundle.js',
       path: __dirname + '/dist',
     },
   };

3. Build Your Project: To bundle your project, use this command:

   npm run build

Resources

For more detailed information and documentation, check out the official Pimlico GitHub page.

Conclusion

Pimlico public is a fantastic choice if you're looking for a straightforward, efficient bundler. Whether you're a seasoned developer or just getting started, it’s here to help simplify your workflow!

import { createSmartAccountClient } from "permissionless";
import { createPimlicoClient } from "permissionless/clients/pimlico";
// ...
const bundler = createPimlicoClient({ transport: http("https://public.pimlico.io/v2/8453/rpc") });
// smartAccountClient.sendTransaction({ calls: [...] });

(docs.pimlico.io)

---

7) Traces, simulations, and when to go beyond vanilla JSON‑RPC

• Traces, like trace_block and trace_transaction, are super useful for debugging, compliance, and analytics. However, they can be quite heavy and often come with some access restrictions. Erigon offers a robust trace_ module, and while many providers have this feature, it’s usually tied to a specific plan or add-on. Check it out here: (docs.erigon.tech).
• When it comes to providers, QuickNode is a good example. They provide access to trace_* across a bunch of chains, but be mindful that you’ll need a plan for that. If you're planning on pulling in traces at scale, make sure to factor in costs for both throughput and storage. More info can be found here: (quicknode.com).
• Now, let's talk simulations! Tenderly has you covered with transaction simulation through RPC and an extended tenderly_* namespace. They’ve also rolled out Virtual TestNets that include some admin “cheatcodes,” and you’ll find their pricing laid out clearly in Tenderly Units (TU). These simulations are perfect for getting pre-trade previews, performing safety checks, or even getting user confirmations. Learn more about it here: (blog.tenderly.co).

---

8) Reliability, performance, and correctness in production

• Multi-provider fallback. Go for an SDK that can handle fallback transports, like viem’s fallback transport, which ranks, retries, and batches requests. This helps cut down on tail latency and lessens the chances of hitting rate limits. Check it out here: (viem.sh)
• Rate-limit hygiene. Make sure you’re ready for 429 errors by implementing exponential backoff with a bit of jitter. Keep an eye on provider-specific headers when they’re available. Alchemy has some great info on retry patterns, and you’ll find many RPCs will throw a 429 with some helpful advice. Dive into the details here: (alchemy.com)
• Choose “safety” for critical reads. For those important settlement steps, stick with the blockTag “finalized” or “safe.” Pair this with EIP-155 chainId replay protection and, when it makes sense, use the CHAINID opcode in your smart contracts. You can find more info here: (eips.ethereum.org)

Production Checklist:

• For reads: Make sure to use EIP‑1898 objects or safe/finalized tags.
• For logs: Don't forget to slice ranges, cap those payloads, and checkpoint progress.
• For writes: Implement the EIP‑1559 fee policy using eth_feeHistory; if you're working with blob chains, remember to include maxFeePerBlobGas.
• For UX: Utilize the EIP‑1193 provider, EIP‑6963 discovery, and account abstraction (AA) where it can give a boost to conversion.
• For resilience: Set up a multi-provider fallback, use exponential backoff, and ensure you have good observability in place.

---

9) Decentralized RPCs: where they fit in 2025

• The Shannon upgrade for Pocket Network, which rolled out on June 3, 2025, has really changed the game. It has turned Pocket into a Cosmos-native, permissionless API network, offering usage-based economics and even supports data sources beyond just RPC. Plus, it's aiming for top-notch enterprise-level quality of service (QoS) through its gateways and staking economics. You’d want to check this out for better censorship resistance, geographic diversity, and to keep things vendor-neutral. (docs.pocket.network)
• With Lava Network’s v5, we've got some cool new features like on-chain QoS/Reputation and pairing lists that score based on latency, availability, and sync-freshness. The architecture smartly routes to the best-performing providers during each epoch. This is definitely something to think about when multi-chain and reputation-weighted routing come into play. (docs.lavanet.xyz)
• Infura is stepping up its game with the Decentralized Infrastructure Network (DIN), which is making strides toward becoming an EigenLayer AVS. This expansion is opening up decentralized gateway options across more than 12 chains. It's really handy if you’re looking for governance backed by Consensys but still want a decentralized group of operators. (prnewswire.com)

---

10) Architecture blueprints (copy‑paste mental models)

• Real-time trading/alerts:
  • We’re talking streams and webhooks here (with a focus on exactly-once delivery and finality order) that feed into a queue, then hit the risk engine, followed by a Tenderly simulation. Once that’s all set, we send the transaction through the main RPC and have a viem fallback to secondaries just in case. For quick alerts, we use newHeads and logs subscriptions to get those immediate signals, and we keep everything in check with finalized Streams. Check it out here!
• Consumer app (AA wallets):
  • For the frontend, we’re using EIP-6963 and EIP-1193. This works alongside the Alchemy Account Kit for smart accounts and Rundler. Plus, there’s the option to integrate Pimlico or Biconomy for those gasless transaction flows. We make sure to maintain read consistency with safe tags for balances and allowances. Learn more here.
• Analytics/indexing:
  • We’ve got Substreams (Firehose) to handle all that high-volume decoding, which then gets sent to a warehouse sink (think SQL/Parquet) for business intelligence. It’s smart to keep those subgraphs around for flexible GraphQL queries and avoid massive eth_getLogs pulls. Dive into Firehose here!

---

11) Code snippets: fees, safety, logs

Fee Policy (EIP-1559 + Blobs):

EIP-1559 introduced some pretty significant changes to how the Ethereum network handles transaction fees. Here’s a quick rundown of what that means, especially when we factor in blobs.

What is EIP-1559?

EIP-1559, or Ethereum Improvement Proposal 1559, was designed to make transaction fees more predictable. Instead of users bidding for gas fees, there's now a base fee that adjusts based on network demand. This way, you get a clearer idea of what you're going to pay.

The Basics of the Fee Structure:

• Base Fee: This is the minimum fee to get your transaction included in a block. It changes according to how busy the network is.
• Tip: You can also add a tip for miners. This is optional but can help speed up your transaction if the network is congested.
• Burn Mechanism: The base fee is burned, which helps reduce the total supply of ETH over time.

Blobs in the Picture:

With blobs, we’re looking at an enhancement to how data is processed on the Ethereum network. Blobs, or large chunks of data, help improve scalability.

Why This Matters:

• Efficiency: With EIP-1559 and blobs working together, Ethereum can handle more transactions smoothly, reducing congestion.
• User Experience: You can say goodbye to the days of guessing how much to bid for gas fees, which leads to a much smoother experience overall.

Closing Thoughts:

Keeping an eye on these developments is crucial for anyone involved in the Ethereum ecosystem. EIP-1559 and blobs are paving the way for a more efficient, user-friendly platform. If you want to dive deeper, check out the full details here.

// Get recent fee stats; pick percentiles for tip
const res = await client.request({
  method: 'eth_feeHistory',
  params: [10, 'latest', [25, 50, 75]]
});
// baseFeePerGas -> next block base fee
// reward[?] -> priority tip percentiles
// On blob-enabled chains, also read baseFeePerBlobGas.

(quicknode.com)

Safe/Finalized Call (EIP-1898):

EIP-1898 introduces the concept of a safe or finalized call. This is a nifty addition aimed at improving the security and reliability within the Ethereum network. The key highlights include:

• Safe Calls: These calls ensure that any transactions are executed with a guarantee of safety. If something goes wrong, such as running out of gas, the transaction doesn’t get executed, which helps in preventing unexpected outcomes.
• Finalized Calls: This is where the magic happens. When a call is finalized, it means it has been confirmed and can’t be changed. This adds another layer of trust, ensuring that once a transaction goes through, it stays as is.

If you're curious to dive deeper into the nitty-gritty of EIP-1898, check out the full document here: EIP-1898.

In Summary:

• What It Is: A safety net for calls and transactions on the Ethereum network.
• Why It Matters: Enhances security and trust, reducing the risk of unexpected failures.

Keep an eye on this EIP as it evolves--it could make a big difference in how transactions are handled moving forward!

{
  "method": "eth_getBalance",
  "params": ["0xAddress", {"blockTag":"finalized"}]
}

(eips.ethereum.org)

Provider Fallback with Viem:

When you're working with Viem, managing your blockchain connections is super important. One handy feature is the provider fallback, which lets you switch to a backup provider if the primary one goes down. Here’s how to set it up!

Step 1: Installing Viem

First things first, you need to have Viem installed. If you haven't done that yet, run the following command:

npm install viem

Step 2: Setting Up Providers

Now, let’s create a couple of providers. You can start with your main provider and a fallback one. Here’s a simple way to do it:

import { createClient, fallbackProvider } from 'viem';

const mainProvider = createClient({
   // Your main provider options
});

const fallback = createClient({
   // Your fallback provider options
});

const provider = fallbackProvider([mainProvider, fallback]);

Step 3: Using the Provider

Once you've got your providers set up, it’s easy to use them in your app. Just call the provider when you need to interact with the blockchain.

const response = await provider.request({
   method: 'eth_blockNumber',
});

Benefits of This Approach

• Reliability: With a fallback provider, you minimize downtime.
• Flexibility: Easily switch between providers based on your needs.
• Simplicity: The setup is straightforward and keeps your code organized.

Conclusion

Provider fallback with Viem is a game-changer for anyone working with blockchain. It ensures that your application remains robust and reliable, even if one of your providers runs into issues. Give it a shot and see how it can improve your project!

For more details and examples, you can check out the official Viem documentation.

import { createPublicClient, fallback, http } from 'viem';
const client = createPublicClient({
  transport: fallback([
    http('https://mainnet.providerA.io/v3/...'),
    http('https://eth-mainnet.g.alchemy.com/v2/...'),
    http('https://rpc.ankr.com/eth')
  ], { retryCount: 5, retryDelay: 200 })
});

viem.sh

---

12) Procurement questions to ask RPC/indexing vendors in 2025

• Data correctness:
  • Do you support EIP‑1898 blockHash objects and the “safe/finalized” tags for eth_call/getProof/getLogs? Check it out here: (eips.ethereum.org).
• Throughput and limits:
  • What are the limits for eth_getLogs block ranges per chain/plan? Are the response payloads limited in size? You can find more info on this at (alchemy.com).
• Trace/simulation:
  • Which trace_* and debug_* methods do you have enabled (and on which clients)? Do you offer built-in simulation features (like the Tenderly namespace) and cost metrics? More details can be found here: (docs.erigon.tech).
• Real‑time:
  • Do you provide exactly-once, finality-ordered streams, and how do you manage reorgs and backfills? Get the scoop at (quicknode.com).
• Decentralization/SLA:
  • Can you route through decentralized backends (like Pocket, Lava, or DIN) or assure multi-region redundancy and verifiable quality of service? Check out the details here: (docs.lavanet.xyz).

---

Final takeaways for decision‑makers

• Make sure your reads and writes align with the 2025 standards:
  • Check out EIP‑1193/6963 for browser interactions, EIP‑1898 for reads, and EIP‑1559 plus EIP‑4844 (when it makes sense) for writes. (eips.ethereum.org)
• Instead of relying on brute-force polling, go for streams and indexing. QuickNode Streams/Webhooks and The Graph Substreams are great options for scaling and keeping things safe during reorgs. (quicknode.com)
• Always be ready for the unexpected. Set up multi-provider fallbacks, use exponential backoff, and prioritize safe/finalized reads to cut down on incidents and save some cash. (viem.sh)
• Take another look at decentralization and vendor risk. Tools like Pocket, Lava, and DIN offer fresh options--make use of them where governance, neutrality, or regional resilience is key. (docs.pocket.network)

If you’re looking to build or refresh your tech stack in Q4 2025 to H1 2026, here’s what you should tackle first: upgrade your SDKs to support blob transactions; refactor your reads to fit EIP‑1898 with those safety tags; replace heavy polling with streams or Substreams; and make sure to standardize on EIP‑1193/6963 for your frontend. This is the way dapps are going to communicate with chains--smoothly and reliably--in 2025.