How to Convert Treasury Tokens Before a Project Migration

Before converting treasury-held tokens in a project migration, verify the destination contract, conversion terms and authority to move each balance. A migration may burn old tokens and mint replacements, exchange them through a dedicated contract, or require a claim after a snapshot. Those mechanisms produce different records and failure modes. The project’s approved migration instructions and contract addresses are the source of truth; a ticker or token name alone does not identify the correct asset.

What does a token migration change for a treasury?

A token migration changes which contract represents the project’s token and how old units become new units. In a burn-and-mint migration, the old units are destroyed and the destination contract issues replacements, usually according to a stated conversion ratio. In a swap-contract migration, the treasury sends old units to a contract that handles the exchange. In a snapshot or claim migration, eligibility is recorded at a specified point and replacement tokens are claimed later.

The first task is to map every treasury position to its actual custody and control. A wallet balance is only one category. Tokens may also sit in vesting contracts, staking or governance contracts, liquidity pools, exchange accounts, custodians, or bridge escrow. A migration contract cannot convert units it cannot receive, and a snapshot may treat a contract-held balance differently from a directly held balance.

Build an inventory by chain, address, token contract, balance, and control path. Record whether each position is liquid, locked, delegated, or subject to a withdrawal delay. Reconcile the inventory against the project’s internal ledger and the migration’s stated eligibility rules. If tokens are distributed across chains, establish whether the migration accepts each chain directly or requires an intermediate transfer. For a migration that needs a cross-chain leg, the route is a separate decision; the thor swap guide explains what to compare when choosing one.

How do you verify the conversion contract and ratio?

Verify the destination and migration contracts against an approved project announcement or governance record before signing a transaction. Confirm the chain, full contract address, token decimals, conversion ratio, eligibility window, and any deadline or claim step. A matching symbol does not prove that a contract is official. If the project publishes no verifiable contract address or conversion terms, the treasury cannot establish that a proposed transaction is the authorized migration.

Read the contract’s relevant functions and state where practical, or have a qualified reviewer do so. Determine whether the migration transfers old tokens to a burn address, calls a burn function, or leaves them in a contract. Check whether new tokens are minted immediately, released later, or claimed in a separate transaction. Review any limits, pause controls, admin permissions, and conditions that can prevent or reverse execution. The ratio can be one-for-one, but it need not be; token redenominations may change unit counts while preserving an intended economic allocation.

Compare the contract behavior with the approved terms. A stated ratio is not enough if the contract applies fees, caps conversions, excludes certain holders, or requires a separate registration. Confirm whether conversion is atomic: if the old tokens are transferred but replacement issuance depends on a later step, document who controls that step and what recourse exists if it fails. Also check whether allowances are needed. An approval gives a contract permission to transfer tokens up to an amount; it does not itself perform the conversion.

How should a treasury execute and account for the migration?

Execute from the authority that controls the relevant assets, using the project’s required governance or multisignature process. Separate preparation from execution: verify the proposal and addresses, test the transaction path where a safe test environment is available, then have authorized signers review the exact calldata and expected token movements. For a large or operationally complex treasury, a small initial conversion can reveal interface or accounting issues before remaining eligible balances are moved, provided the migration terms allow staged execution.

• Save the approved proposal, migration instructions, contract addresses, and a copy of the transaction data.
• Record pre-migration balances, allowances, locked positions, and the expected replacement amount under the published ratio.
• After each transaction, verify the old-token movement and new-token receipt on the relevant chain; retain transaction identifiers and block details.
• Reconcile remaining legacy balances and any unclaimed replacement allocation against the treasury ledger.

Do not count a submitted transaction as a completed conversion. Confirm its final status on the chain and check the destination balance or claim state. If tokens remain in vesting, staking, liquidity, or custody, track each position through its own exit and migration steps. Some positions may be ineligible or may need to be unwound first; doing so can incur costs or change exposure, so follow the project’s published treatment rather than assuming the same path applies to every address.

Once conversion is complete, keep legacy and replacement token balances distinguishable in treasury records. Note the migration date, ratio, method, fees, unconverted amount, and any outstanding claim. The practical rule is simple: establish eligibility and control for every balance, verify the contract’s actual behavior against approved terms, and reconcile only after the destination tokens are confirmed.