When Three Transactions Are an Expensive Mistake
A user wants to add liquidity to a Uniswap V3 pool. Real process: approve token A, approve token B, mint position. Three separate transactions—three MetaMask confirmations, three gas payments. If a front-run occurs between approve and mint, the position is created at an unfavorable price, and the user loses funds. Each separate transaction requires gas payment—with the batch approach you pay only once, saving up to 46% on intrinsic cost. For Ethereum mainnet at 20 gwei, each batch saves approximately $0.50 per transaction.
Batch transactions solve the problem: one confirmation, one gas, atomic execution. Our team specializes in batch system development for DeFi and NFT platforms. We'll evaluate your project within 2 days—contact us for a consultation. With over 5 years of experience and 50+ blockchain projects, our team delivers enterprise-grade batch solutions. Our DeFi development services include batch transaction integration. A custom batch executor can handle complex logic.
Why Batch Transactions Are More Profitable
Each EVM transaction costs at least 21,000 gas (intrinsic cost). Batch of 5 operations in separate transactions: 5 × 21,000 = 105,000 gas just for intrinsic. Via Multicall3—once 21,000 + router overhead (~2,000 gas) + gas per call without intrinsic cost. Achieve significant Ethereum gas savings with batch transactions. Batch transactions are 3 times cheaper than sequential execution for typical DeFi operations.
| Scenario | Separate Transactions | Batch (Multicall3) | Savings |
|---|---|---|---|
| 3 ERC-20 transfers | 3 × 65,000 = 195,000 | ~125,000 | ~36% |
| 5 approve + swap | 5 × 46,000 = 230,000 | ~148,000 | ~36% |
| 10 NFT mints | 10 × 120,000 = 1,200,000 | ~650,000 | ~46% |
Actual figures depend on logic, but 30-50% savings on intrinsic cost is a conservative estimate. Smart contract atomicity ensures all operations succeed or fail together, preventing partial failures.
How to Implement Batch Transactions: 4 Steps
- Choose an approach. Determine whether Multicall3 is sufficient or a custom BatchExecutor with whitelists is needed.
- Develop contracts. Write Solidity code using Foundry or Hardhat, testing on a fork.
- Test. Cover reentrancy, gas overflow, and atomicity scenarios with Slither and Mythril.
- Integrate with frontend. Use viem or ethers.js to call batch functions.
How to Choose Between Multicall3 and Custom BatchExecutor
Router pattern—a contract aggregator that accepts an array of calls and executes them sequentially. The simplest option is Multicall3 by MakerDAO, deployed on most EVM networks at address 0xcA11bde05977b3631167028862bE2a173976CA11.
struct Call3 {
address target;
bool allowFailure;
bytes callData;
}
function aggregate3(Call3[] calldata calls)
external
payable
returns (Result[] memory returnData);
allowFailure: false makes the whole batch atomic—if one call reverts, everything rolls back. allowFailure: true allows continuation on error (partial execution). The problem with the router pattern: the user must approve tokens to the router contract address. The user must trust the router not to drain tokens. For custom routers, this creates a UX barrier and requires an audit.
EIP-4337 (Account Abstraction)—a different level. The user controls a smart contract wallet that can execute multiple calls in one UserOperation. Approve + action are atomic, without intermediate trust in a router. Stack: Biconomy, Safe{Core} AA SDK, ZeroDev.
| Criteria | Router (Multicall3) | EIP-4337 |
|---|---|---|
| Requires approve? | Yes, to router | No (wallet approves itself) |
| Atomicity | Yes (via allowFailure) | Yes |
| Trust in contract | High | Minimal |
| Integration complexity | Low | Medium |
| Flexibility | Medium | High |
Choice depends on context: for protocol-level batching—router, for wallet-level automation—EIP-4337.
When Multicall3 Isn't Enough: Custom Batch System
Multicall3 doesn't accept ETH with distribution per call (only a shared msg.value). It doesn't support callbacks. It doesn't store state between calls in a batch. For complex scenarios, we write a custom batch executor with optimizations leveraging EVM opcodes like CALL and STATICCALL, and proper gas stipend distribution:
View BatchExecutor smart contract code
contract BatchExecutor {
struct BatchCall {
address target;
uint256 value;
bytes data;
bool requireSuccess;
}
function executeBatch(BatchCall[] calldata calls)
external
payable
returns (bytes[] memory results)
{
results = new bytes[](calls.length);
for (uint256 i = 0; i < calls.length; i++) {
(bool success, bytes memory result) = calls[i].target.call{
value: calls[i].value
}(calls[i].data);
if (calls[i].requireSuccess) {
require(success, _getRevertMsg(result));
}
results[i] = result;
}
}
}
Typical Mistakes When Developing Batch Systems
- No whitelist of target addresses—attacker can call any contract from BatchExecutor and drain tokens.
- Missing
requireSuccesscheck for critical calls—partial failure can leave the system in an inconsistent state. - Ignoring gas limit overflow—a batch of 50+ calls may exceed the block gas limit, also consider SLOAD/SSTORE costs under EIP-2200.
What's Needed for Frontend Integration?
On the client side, we form the list of calls and encode via viem:
import { encodeFunctionData } from 'viem';
import { multicall3Abi } from './abis';
const calls = [
{
target: tokenAddress,
allowFailure: false,
callData: encodeFunctionData({
abi: erc20Abi,
functionName: 'approve',
args: [spenderAddress, amount]
})
},
{
target: protocolAddress,
allowFailure: false,
callData: encodeFunctionData({
abi: protocolAbi,
functionName: 'deposit',
args: [amount]
})
}
];
await walletClient.writeContract({
address: MULTICALL3_ADDRESS,
abi: multicall3Abi,
functionName: 'aggregate3',
args: [calls]
});
What's Included in Batch System Development?
- Architectural document with approach choice (router / AA / custom)
- Smart contracts with tests (Foundry/Hardhat) and Slither/Mythril report
- Frontend integration (wagmi/viem) with code examples
- Testnet deployment and deployment instructions
- Thorough contract audit by our certified team (reentrancy check, gas optimization)
- Training your team on using the batch system
- One month of support after delivery
Timelines: Integrating Multicall3 into an existing dApp—1-2 days. Custom BatchExecutor with whitelist logic and tests—3-5 days. Full system with EIP-4337 and frontend—from 2 weeks. Estimated development cost: from $2,000 for basic integration to $15,000 for a full EIP-4337 system. For a typical DeFi project executing 100 batch transactions per day, gas savings can amount to $50 daily, or $1,500 per month.
Get a consultation on implementing batch transactions in your project—our highly experienced team, with a proven track record of 50+ successful deployments, will assess the complexity and propose the optimal solution.