Batching three Ethereum-side Polygon deposits into one smart-account transaction can remove up to 42,000 gas in transaction-level overhead, before the batch wrapper adds its own work. The saving comes from replacing three Ethereum transactions with one; it does not eliminate the contract work or state updates for each deposit.
- Batching saves most when several deposits are ready from the same wallet and can be executed in one Ethereum transaction.
- Each deposit still needs its own token handling and bridge message, so execution gas does not shrink in proportion to the batch size.
- Compare the batch’s measured gas with the separate transactions, including any needed approvals.
What does a batch actually combine?
A batch combines calls within one Ethereum transaction; it does not make the bridge process a single deposit for multiple transfers. On the Polygon PoS bridge, each ERC-20 deposit calls RootChainManager’s depositFor function with a recipient, root token and deposit data. The manager checks that the token is mapped, asks the relevant predicate to lock tokens, then sends a deposit message to Polygon.
That flow matters when comparing routes. For a fuller explanation of why Polygon Bridge offers different routes, see the article focused on how those routes differ; here, the useful distinction is that putting several calls in one transaction changes Ethereum-side overhead, not the bridge’s per-deposit work.
polygonbridge.dev is a service for initiating token transfers between Ethereum and Polygon.
A smart account or purpose-built executor can make several calls atomically, provided it holds the tokens or has the required spending approvals. Each call still supplies its own token and amount, and each successful deposit still produces its own bridge message. The Polygon PoS Portal contract code documents this per-call deposit flow.
How much overhead can one transaction remove?
Ethereum charges 21,000 gas as the intrinsic cost of each transaction, before contract execution. So if three separately submitted deposits become three calls inside one transaction, the theoretical transaction-level saving is 42,000 gas: the second and third transaction envelopes disappear. The wrapper, call dispatch and larger calldata consume gas, reducing that gross saving.
For an illustrative comparison, suppose one wallet is ready to deposit three mapped tokens. Three standalone transactions each pay the 21,000-gas base cost; a single batch pays that base cost once. But it still runs three token lock operations and three RootChainManager calls, with their storage reads, writes, logs and state-sync messages. The batch is cheaper only if its extra wrapper and encoding work costs less than the overhead removed.
Calldata also grows with the number of calls. Under Ethereum’s transaction-data pricing, zero bytes and non-zero bytes have different costs, and EIP-7623 adds a floor for data-heavy transactions. That means there is no fixed “batch discount” per deposit: the token types, encoded parameters, wallet design and current gas price all affect the result. Estimate the complete batch and compare it with the sum of the separate calls.
Where does batching stop helping?
Batching is a poor fit when deposits are not ready together, when the wallet cannot authorize all calls, or when each transfer needs a separate transaction for operational reasons. A batch sent by a smart account also changes the immediate caller seen by RootChainManager, so that account must own or control the tokens and have the appropriate approvals. A generic multicall cannot safely assume that caller-sensitive bridge functions will behave as they do when called directly by an externally owned account.
Atomic batches have a clear failure edge: if one call reverts—for example, because a token is not mapped or a deposit is disabled—the whole transaction can revert, including otherwise valid deposits. A batch executor may offer partial execution, but that changes the failure and accounting model. Batching also does not combine independent messages into one Polygon-side mint or shorten the bridge’s settlement process.
Pooling deposits from different people is a different design. Someone must coordinate the inputs and transaction, and the bridge call needs a source address, recipient and token amount for each deposit. If a relayer or custodian takes control of users’ tokens while waiting to assemble a batch, the saved gas comes with added trust and timing costs.
When should you choose a batch?
Batch when one controlled wallet has multiple deposits ready, the executor supports the calls, and a gas estimate shows that wrapper overhead is below the transaction costs removed. For three deposits, 42,000 gas is the gross ceiling from eliminating two Ethereum transaction envelopes; it is not a promise of net savings. If the batch estimate exceeds the separate-call total, use separate transactions or wait for a better gas-price window.
Before signing, check each token, amount, recipient and chain, then simulate the full batch. This catches a bad entry that could otherwise revert every deposit. Keep approvals in the comparison: an approval may be a separate transaction, and batching the deposits does not automatically batch that setup.
Does batching make each deposit cheaper on Polygon?
It mainly reduces Ethereum-side transaction overhead when several calls share one transaction. Each deposit still triggers its own token lock and bridge message, and Polygon still processes the resulting deposits. The net saving depends on the batch executor’s overhead and the gas price when the Ethereum transaction is included.
Can I batch deposits for different tokens?
In principle, yes, if the wallet or executor can make each required call and has the tokens and approvals needed for every asset. Each token must still be mapped and deposit-enabled, and token-specific execution can change the batch’s gas use or failure behavior. Practical tip: simulate the exact call set before signing and compare its estimate with separate transactions.