A treasury that makes recurring cross-chain transfers can lower some EVM gas overhead when its exchange reuses deployed deposit channels. The saving comes from avoiding repeated deposit-contract deployment; it does not remove the gas for every deposit or sweep, and it depends on channel availability, asset type, and transaction batching.
What does reusing a deposit channel save?
On EVM networks, a deposit channel can be a smart contract at a deterministically derived address. For each swap, Chainflip reserves a channel and derives its address using CREATE2 and a salt; after the deposit is witnessed, a deposit contract is deployed there to let the Vault retrieve the funds.
Contract deployment is a separate gas cost on top of moving assets. When a previously deployed channel becomes available for a later swap, the Vault can fetch from it without deploying another contract. The address is assigned to a new channel, so reuse is a protocol optimization across successive channel assignments—not a standing address for one treasury to use repeatedly.
How does the address move from one swap to the next?
The State Chain records the channel request, including swap details and a reserved index. The derived address identifies where the treasury sends the source asset. Validators witness the deposit; the protocol then uses the channel contract to move the funds into the Vault, where the swap is accounted for and settled.
Channels close after 24 hours. After closure, many Vault types can make the address available for a future channel. A new user or treasury transfer must still open a fresh channel for each swap and send the deposit promptly; a remembered address may have expired or been reassigned, so address reuse should never be treated as permission to reuse yesterday’s payment instructions.
For an EVM treasury, the lifecycle is therefore: request a channel, verify the request and destination details, send the deposit to the derived address, and allow witnessing and Vault retrieval to complete. The contract can persist at that address after its first deployment, while its channel assignment and the swap details change.
Which costs remain, and when is the saving material?
Reuse removes a deployment from eligible later uses; it does not make ingress free. A token transfer may still require a Vault fetch to sweep the token, while a native asset deposit can in some cases flow atomically from an already deployed channel into the Vault without a separate fetch. The exact path depends on the asset and Vault design.
Batching is a separate saving. The EVM Vault can bundle actions so one signature verification covers multiple transfers or fetches. The protocol documentation gives illustrative approximate costs of 80,000 gas for signature verification and 10,000 gas for an asset transfer in Vault logic: five batched transfers would average about 26,000 gas each for those components, versus about 90,000 each if verified separately. These are examples, not a quote for a particular swap; network gas prices and transaction contents change the actual charge.
For recurring payouts, the useful question is how much deployment overhead the protocol avoids across the flow, not whether your team can keep one deposit address. Compare the path for the actual asset and chain, and include the remaining transfer or fetch work, signature overhead, and prevailing gas price. Address reuse matters most when it avoids a costly deployment; batching matters when several Vault actions can share verification.
How should a treasury apply the trade-off?
Consider a business that sends a weekly USDC payout from an EVM chain into a cross-chain swap. Each week it requests a new channel and sends to that week’s address. If the assigned address already has a deployed deposit contract, the protocol can avoid another deployment; it still pays for token movement and any required fetch. If several eligible Vault actions are batched, signature cost can also be shared, but neither optimization guarantees a fixed per-transfer saving.
Keep channel creation and payment execution close together in the treasury workflow, and reconcile the request hash, address, asset, amount, and destination before releasing funds. This is especially useful when a payout queue retries or delays a transfer: the original channel’s 24-hour lifetime makes stale instructions an operational failure mode, even though a later user may eventually receive the same address under a new assignment.
Chainflip is one way to run native-asset cross-chain swaps with this kind of Vault flow. Before acting, ask whether the expected gas reduction on your chain and asset is large enough to matter after the remaining ingress work and the cost of your own payment controls; for the full swap sequence, see how Chainflip routes a native cross-chain swap.