What Is Multicall? A Developer Guide to Batching Ethereum Smart Contract Calls

Every blockchain developer eventually hits the same wall: your application needs to read data from multiple smart contracts, but making separate requests for each call is slow, expensive, and inconsistent. Enter multicall, a smart contract design pattern that aggregates multiple function calls into a single transaction or request. This guide explains how multicall works, when to use it, and how modern cross-chain infrastructure builds on these batching principles.

A multicall contract accepts multiple function calls as inputs and executes them together within a single transaction. Instead of sending individual requests to the Ethereum network for each piece of data you need, you bundle everything into one call that returns all results at once.

The concept is straightforward: your application packages several contract calls (including target addresses and encoded function data), sends them to the multicall contract, and receives an aggregated response containing all results. This batching approach works because the multicall contract uses low-level Solidity calls to iterate through your request list and collect return data.

MakerDAO originally developed multicall to aggregate multiple constant function call results into a single response. The pattern proved so useful that developers created improved versions over time, with Multicall3 now representing the most widely adopted implementation. Multicall3 is deployed at the same address across over 100 EVM-compatible chains, making it a reliable tool for cross-chain development.

The efficiency gains from multicall come from two distinct sources, depending on whether you're reading data or writing state changes.

For read operations using eth_call, multicall primarily reduces your RPC usage and costs. Each separate JSON-RPC request to services like Infura or QuickNode consumes API credits and adds network latency. By batching calls into a single request, you dramatically cut both expenses and response times. A practical example: fetching five separate token balances normally requires five API calls. With multicall, you need exactly one.

For write operations that modify blockchain state, the savings come from reduced base transaction costs. Every Ethereum transaction carries a fixed 21,000 gas overhead regardless of what it does. When you batch multiple state changes into a single multicall transaction, you pay that base cost once instead of multiple times. Academic research published in the ACM International Symposium on Blockchain found that multicall can provide savings between 56.8% and 98.9% of fixed per-transaction costs compared to sending transactions individually.

Beyond cost savings, multicall guarantees data consistency. All values returned come from the same block, eliminating the risk of reading stale or inconsistent data when separate requests hit different block states.

Multicall3 represents the evolution of the original multicall concept, offering backward compatibility with earlier versions while adding flexibility and deploying to more chains. The contract lives at 0xcA11bde05977b3631167028862bE2a173976CA11 on most EVM networks.

The core method most developers use is aggregate3, which accepts an array of Call3 structs containing target addresses, call data, and a flag indicating whether individual call failures should revert the entire batch. This flexibility matters because sometimes you want atomic execution (all succeed or all fail), while other times you need partial results even if some calls fail.

For more complex scenarios, Multicall3 provides additional methods. The tryAggregate function lets you specify whether any failed call should cause a revert. The aggregate3Value method supports sending ETH along with your batched calls. Helper functions like getBlockNumber, getCurrentBlockTimestamp, and getEthBalance return useful metadata alongside your primary results.

The contract implements several gas optimization techniques including caching array lengths in loops, using unchecked blocks for incrementing counters, and employing prefix increment operators. These micro-optimizations compound across batched operations.

Multicall excels in specific scenarios. The most common use case involves reading multiple token balances or allowances for a single address. DeFi dashboards that display portfolio information across dozens of tokens benefit enormously from batching these balance checks.

Price aggregation presents another strong fit. Fetching prices from multiple DEX pools or oracle contracts in a single call ensures you receive consistent pricing data from the same block state, critical for accurate calculations.

Configuration checks that require reading settings from multiple related contracts also map well to multicall. Rather than making separate calls to verify each parameter, you batch everything and process results together.

For write operations, multicall works well when you need atomic execution of related state changes. If your application requires approving tokens and then depositing them, bundling both operations ensures neither happens without the other.

However, multicall has limitations. Very complex calls or large batches can exceed block gas limits or trigger timeout errors from RPC providers. The Chainstack comparison of batch requests versus multicall notes that both approaches require significant computational resources and can trigger errors for complex operations. Additionally, when using multicall from an externally owned account (EOA), the Multicall3 address becomes the msg.sender for all subsequent calls, limiting usefulness for operations where sender identity matters.

Several alternatives exist for batching blockchain operations, each with different tradeoffs.

HTTP batch requests bundle multiple JSON-RPC calls into a single HTTP request. Performance tests show batch requests often slightly outperform multicall for pure read operations, but multicall typically counts as a single request against rate limits while batch requests count each call individually.

EIP-5792 introduces wallet-level batching through the Wallet Call API. This standard enables users to approve multiple transactions through a single wallet popup, improving user experience dramatically. However, EIP-5792 requires wallet support and focuses on user-facing transaction flows rather than backend data aggregation.

EIP-7702 proposes allowing EOAs to temporarily function as smart contracts, enabling native batching without requiring separate multicall deployments. This approach offers potentially lower per-operation costs but requires significant infrastructure changes.

Permit2 and Permit3 address a related but distinct problem: token approvals. Rather than batching arbitrary calls, these standards optimize the specific workflow of approving tokens for spending. Eco's Permit3 extends this concept to enable multichain token permissions with a single signature, eliminating the need for separate approval transactions on each chain.

Multicall3 offers the widest chain support and most established track record. Its deployment at a consistent address across 100+ networks makes it reliable for multi-chain applications. The main limitations involve complexity for cross-chain scenarios and the msg.sender considerations mentioned earlier.

Viem and Ethers.js provide native multicall integration within their libraries. This approach works well for applications already using these tools, though it still requires developers to manage batching logic themselves.

Custom implementations make sense when your application has specific requirements around error handling, gas limits, or call patterns that standard solutions don't address.

Multicall delivers meaningful benefits across several dimensions:

Every solution involves tradeoffs:

Modern development libraries handle most multicall complexity automatically. Viem's native Multicall3 integration lets you batch calls with minimal configuration:

For applications focused on stablecoin operations, the Eco Routes SDK provides an even simpler abstraction. Rather than manually batching contract calls, you express intents describing desired outcomes and let the protocol handle execution:

This intent-based approach eliminates the need to manage multicall batching, gas optimization, and cross-chain coordination manually. The SDK handles quote aggregation, route optimization, and execution.

Batch size matters for implementation. The recommended range is 10-50 calls, depending on complexity. Start with smaller batches and increase based on your specific call patterns and the chains you're targeting.

Error handling requires attention. Decide upfront whether individual failures should abort the entire batch (atomic execution) or return partial results (graceful degradation). The allowFailure flag in Multicall3 gives you this control per-call within a single batch.

Cross-chain applications face unique challenges that go beyond single-chain multicall. Reading consistent data across multiple networks, coordinating transactions that span chains, and managing different gas tokens all add complexity.

The fragmented stablecoin landscape illustrates this challenge. Liquidity exists in isolated pools across 50+ blockchains, making efficient cross-chain operations difficult even with multicall available on each network individually.

Eco's infrastructure addresses this through intent-based cross-chain execution. Instead of managing multicalls on each chain separately, applications express transfer intents and rely on a solver network to execute optimal routes. This approach abstracts away per-chain implementation details while maintaining execution guarantees.

For developers building multichain applications, combining multicall for on-chain batching with cross-chain protocols for inter-chain coordination provides the best of both approaches.

Multicall contracts are stateless by design, which provides inherent safety properties. The contract should never hold funds after a transaction completes, and you should never approve Multicall3 to spend your tokens. Following these rules prevents the most common attack vectors.

When using multicall for write operations, understand the msg.sender implications. Calls from an EOA through multicall will show the Multicall3 address as the sender, potentially breaking access control logic in target contracts.

For delegatecall scenarios, msg.value handling requires extra caution since the value doesn't change across delegatecalls. Relying on msg.value within a multicall can create vulnerabilities if not handled carefully.

The Multicall3 contract itself is unaudited, though it's been battle-tested through widespread deployment. For production applications handling significant value, consider whether the efficiency gains justify any additional risk.

What is a multicall in blockchain? A multicall is a smart contract pattern that batches multiple function calls into a single transaction or request. Instead of making separate calls to read data or execute operations on different contracts, you send one bundled request and receive aggregated results.

How does multicall save gas? For read operations, multicall reduces RPC costs by bundling requests. For write operations, it eliminates duplicate base transaction fees (21,000 gas each) by combining multiple state changes into one transaction.

Is Multicall3 safe to use? Multicall3 is unaudited but widely deployed and used. Key safety practices include never leaving funds in the contract after transactions and never approving spending tokens. For high-value operations, evaluate whether the efficiency gains justify any additional risk.

What chains support Multicall3? Multicall3 is deployed at the same address on over 100 EVM-compatible chains including Ethereum, Arbitrum, Optimism, Base, Polygon, and many others. Check the official deployment list for specific chain support.

How is multicall different from batch requests? HTTP batch requests bundle multiple JSON-RPC calls into one HTTP request but are processed individually by the node. Multicall executes all calls within a single EVM transaction, ensuring consistent block state and typically counting as one request against rate limits.

Can I use multicall for cross-chain operations? Standard multicall operates within a single chain. For cross-chain batching, you need additional infrastructure like intent-based protocols or cross-chain messaging systems that can coordinate execution across networks.