A bridge change does not move a rollup treasury’s assets

When a rollup changes its bridge, a treasury should pause new transfers and move existing balances only after confirming which contracts and routes are affected. A change to a bridge interface or routing provider does not, by itself, move tokens already held on the rollup. Those balances remain at their existing token contracts until the treasury submits transactions that transfer or withdraw them.

The first distinction is between a route change and a token migration. A route change may alter how new transfers are submitted while the token contract and its backing remain the same. A token migration can require a separate transaction, such as swapping an old representation for a new one. A rollup upgrade may also change bridge contracts without making every asset holder move funds. The operator’s job is to identify which of these has happened before choosing a path. For an overview of route selection and swaps, see this explanation of Acrossbridge route choices for apps.

What should a treasury check before moving funds?

Start with a balance and contract inventory on the source rollup, then match each asset to the destination contract the treasury intends to use. A token symbol is not enough: the same symbol can refer to a canonical asset, a bridged representation, or an issuer’s native deployment. Record the chain, token contract address, balance, and any migration instructions from the rollup or token issuer.

Next, confirm what the bridge change actually affects. Check whether the old bridge still accepts deposits and withdrawals, whether the destination asset remains supported, and whether a replacement contract or route has been announced. Verify this through the rollup’s own published information and the contract addresses surfaced by the treasury’s established transaction workflow. A new interface is not evidence that an old contract has been disabled; an announcement about a new bridge is not evidence that old balances migrate automatically.

For a multisig treasury, also map the operational dependencies before signing. The source chain needs enough native gas currency to execute the transfer, and the destination may need a separate reserve for later transactions. If the route uses an ERC-20 allowance, confirm the spender address and allowance amount in the transaction data. Assign who checks the destination balance and who reconciles the ledger after completion.

Which route should move the treasury’s assets?

For most treasuries, the preferred route is the one with the clearest asset mapping and verifiable settlement, even if it takes longer. A rollup’s canonical bridge generally follows the rollup’s deposit and withdrawal process. A withdrawal to the parent chain can involve a waiting period, particularly on optimistic rollups, so it is less suited to an immediate liquidity need. In return, it avoids depending on a separate liquidity provider to deliver the destination asset quickly.

A third-party liquidity route can deliver funds faster by paying from liquidity already available on the destination chain. That can reduce time spent waiting for a canonical withdrawal, but speed is not free: the treasury must assess the route’s bridge mechanism, available liquidity, fees, slippage, and the exact asset it will receive. A swap-and-bridge route adds another leg. If it converts the source token into a different destination token, the treasury has changed both its location and its exposure.

Compare the routes against the treasury’s actual requirement: preserving the same asset, meeting a deadline, or reducing operational steps. A slow canonical exit may be preferable when the destination balance is not urgent and provenance matters most. A liquidity route may suit a time-sensitive payment if the treasury has approved its trust assumptions and can confirm the received token. Neither route should be chosen on quoted speed alone; the signer should be able to explain what contract receives the source asset and what claim the destination balance represents.

How can a treasury migrate without losing track of funds?

Move in stages, with a small test transfer before the main balance. The test should confirm that the transaction used the intended source contract, completed the expected bridge or swap steps, and credited the intended destination contract. Check the destination chain directly and reconcile the resulting balance against the treasury record; a successful source transaction is not the same as a completed destination transfer.

• Pause automated transfers that still point to the old route.
• Verify the destination chain, token address, recipient, spender, and transaction limits.
• Send a test amount and confirm its final destination asset and balance.
• Move the remaining amount in batches sized to the treasury’s controls and liquidity needs.

Keep the old route available in the runbook until the new process has been exercised and reconciled. If the bridge change requires a token swap or contract migration, record the old and new addresses and the conversion or redemption step; do not treat a matching ticker as proof of equivalence. Retain transaction hashes, approvals, and post-transfer balances so another operator can reconstruct the move.

The decision is less about finding a universally best bridge than matching settlement guarantees and timing to the treasury’s purpose. Watch for explicit notices about bridge deprecation, withdrawal completion, token support, and contract addresses. Those signals determine whether the next action is to update the route for future transfers, withdraw existing balances, or migrate the token representation itself.