Treasury token migrations: keep bridge claims redeemable

A token migration changes the asset’s identity only when the issuer or bridge changes the contract mapping; it does not move balances by itself. For treasury teams, the key is to establish which contract holds the old supply, which contract represents the replacement on each chain, and whether the canonical bridge can still redeem both.

A migration changes the token mapping, not the old balance

An ERC-20 balance belongs to a contract address, so deploying a replacement token does not transfer balances or update a bridge’s configuration. The issuer must define a migration path, such as a burn-and-mint swap, a claim against a snapshot, or an exchange rate between old and new units; until then, the old balance remains in the old contract.

Bridging adds a second mapping: a source-chain token contract is paired with a destination-chain representation. Manta Pacific’s token list records the Ethereum root address and the Pacific address separately; for example, it lists DAI on Ethereum Mainnet against a different DAI contract on Pacific. Manta Bridge’s two route options determine which chain’s contracts your transfer procedure must check. The ticker and decimals help identify a token, but neither proves that two contracts are interchangeable.

The bridge’s pair determines what can be redeemed

In a canonical lock-and-mint flow, a deposit locks the source asset and causes the paired destination token to be minted; withdrawal burns that representation and releases the locked asset. An issuer migration does not automatically replace either side of that pair. If the bridge still recognizes the old source contract, sending the replacement token may fail, or require a new bridge listing and a corresponding destination representation.

Compare two cases. If the issuer keeps the same contract and upgrades its logic, the bridge pair may remain valid, subject to the upgrade’s effects on transfers and allowances. If the issuer deploys a new contract and asks holders to swap, the bridge may continue to accept only the old contract; the replacement needs an explicit pair or an issuer-approved route. Manta Bridge should therefore be treated as a route for supported contract pairs, not as a token-migration service.

Migration creates separate costs and failure points

Budget for each on-chain action independently: an approval if needed, the bridge deposit or withdrawal, and the issuer’s swap or claim. A deposit normally incurs Ethereum gas for the source transaction, while destination execution and later transfers use Manta Pacific gas; a withdrawal also has its own source-side transaction and finalization requirements. Exact costs move with network conditions and contract paths, so quote them at execution time rather than treating migration as a single bridge fee.

The operational edge case is a split inventory: some units remain in the old bridge representation while others have been swapped into the new token. A withdrawal can then fail because the old representation is paused, unsupported, or no longer redeemable by the issuer, even though its displayed symbol and balance look unchanged. Ethereum.org’s ERC-20 guidance reinforces the practical check: contract address and behavior matter; name and symbol are not unique identifiers.

Reconcile both sides before changing treasury flows

Before moving material balances, record the source and destination contract addresses, decimals, bridge pair, issuer migration rate, cutoff block or claim deadline, and the party responsible for any migration transaction. Test a small amount through the intended path, then verify the received contract address and redemption behavior on the destination chain before updating payout allowlists or accounting mappings.

Keep old and new balances in separate ledger entries until the issuer confirms the conversion and the bridge confirms support for the new pair. If the old asset cannot be withdrawn directly, use only the issuer’s documented migration route and reconcile the resulting amount against the old balance; do not infer a 1:1 conversion from matching tickers.

I would migrate treasury flows only after the new contract pair is documented and a small round trip succeeds; otherwise, keep the old route and representation isolated until redemption is confirmed.

Comments

Post a Comment

Popular posts from this blog

How to Judge a Changing Swap Quote Before You Sign

Image
When a swap quote changes, compare the new output and minimum received before signing; accept only if both still suit you. A quote is an estimate based on current pool conditions, while your signed transaction executes later. On Avalanche, that gap can matter even if you spend the same amount. A quote moves when pool balances or routes change A decentralized exchange often gets prices from liquidity pools: smart contracts holding pairs of tokens that traders swap between. Each trade changes the pool’s token balances, which changes the next estimated price. A larger trade usually moves the price more in a shallow pool than in a deep one. Suppose you enter 1,000 USDC to receive WAVAX. The first estimate is 10 WAVAX, but another trader swaps against the same pool while you review. Your refreshed estimate might be 9.94 WAVAX. Those figures are examples; the actual output depends on the pool, trade size, fees, and route available at that moment. A route is the path tokens take through one ...
Read more

Token Allowlists Explained for Cross-Chain Routes

Image
A token allowlist is the set of token contracts a route accepts, and the check can differ between the two chains in one transfer. Your wallet may hold a token with a familiar name, yet a route can reject it if its contract address is not accepted. This is separate from approving a transaction. An allowlist checks the token contract on each chain A token is a smart contract that tracks balances on a blockchain. An allowlist names which token contracts a protocol or route will handle. The ticker, such as USDC, is only a label; it does not prove two tokens are the same asset. For a cross-chain transfer, the route checks the token you send on the origin chain and the asset it can deliver on the destination. A route may accept one USDC contract on Base and deliver a different USDC contract on Arbitrum. These are illustrative cases: support depends on the route’s current configuration. Compare that with a second case: your wallet holds a wrapped token, which is a version issued by another c...
Read more

How to Recover a Pending Avalanche Swap

If your Avalanche swap is pending or failed, check its C-Chain status before retrying: a pending transaction may need time or a same-nonce replacement, while a finalized failure needs diagnosis and a new transaction. The distinction matters because submitting another swap does not cancel the first one. Check whether the transaction reached the C-Chain A wallet can show a transaction as pending even when it has not reached the network. Use the transaction hash in the Avalanche C-Chain explorer to see whether it is pending, final, or absent. A final transaction has been processed; if its execution failed, it cannot be reversed or sped up. Find the transaction hash. Open the swap’s entry in your wallet and copy its hash. Search that hash in the C-Chain explorer, checking that the network is Avalanche C-Chain and the sending address is yours. Compare the wallet with the explorer. If the explorer shows the transaction as pending, it is waiting for inclusion. If it shows a final status, in...
Read more