Token upgrades can break treasury transfers

A token upgrade can leave treasury balances intact and still change how a payment works. The key is to check the contract’s stored data and every rule that moves tokens before the new code goes live.

How does a token contract upgrade work?

Many upgradeable tokens use a proxy: a contract that keeps the data and sends each call to a separate implementation contract, which holds the logic. Replacing that logic can preserve balances, but only if the new code reads the stored data in the same way.

That makes storage layout a first check. If a new version inserts or changes a variable in the wrong place, the code may read an old value as something else. A treasury’s balance could appear wrong, or an access role could point to the wrong address. For the user-facing side, this guide to Biswap’s bridge and wallet swaps gives more detail on the routes tokens can take. Treasury reviews should include those routes as well as direct payments.

What can change in a treasury transfer?

An upgrade can change who may send tokens, which addresses are blocked, or what the recipient receives. A fee rule, for example, may mean a transfer of 100 tokens delivers less than 100. A pause switch may stop transfers altogether. The treasury’s records must match the token’s actual behavior.

Before approving an upgrade, trace a payment from the treasury’s wallet to the recipient. Check the amount and unit, the sender’s permission, any fees, and the balance change on both sides. Then compare the token’s transfer event—the on-chain record of a movement—with the amount the treasury system records.

• Confirm the treasury address and its role in the new code.
• Check that existing balances and allowances still use the right storage fields.
• Test exact transfers, including any fee or pause rules.
• Match emitted events and final balances to the treasury’s accounting.

How should a team check an upgrade before it goes live?

Use the current contract state as the starting point. Run the proposed code against a copy of that state, then test the treasury’s real transfer paths: routine payments, approvals, and any route that moves tokens through another contract. A clean test of a fresh token is not enough if the live token already has balances, roles, and allowances.

Also check the upgrade transaction itself. The address receiving the new implementation should be the intended one, and the person or multisig approving it should have the right authority. If the token cannot be upgraded, a new contract and a balance migration may be needed instead. That gives the team a clean starting point, but requires holders and treasury systems to move to the new token.

For most teams, the safer choice is to preserve the existing transfer rules unless the change requires something different. Write down what the treasury expects to send and receive, then verify those outcomes against the new code before approval. An upgrade is ready when balances, permissions, events, and payment records all agree.