A bridge moves tokens, not their vesting schedule

Vested tokens move across networks only when the claim is transferable or the vesting arrangement is deliberately migrated. A bridge can carry a token balance, but it does not automatically carry the schedule that controls when locked tokens become claimable.

Can tokens move before they vest?

Only if the vesting contract allows the claim itself to move, or its owner can change under the contract’s rules. Many arrangements hold tokens in a contract and release them to a beneficiary over time, so the beneficiary cannot bridge tokens that have not yet been released.

Some contracts let an administrator update a beneficiary or migrate a position. That changes who can claim, but it is a separate operation from bridging a token balance. For a fuller look at the route trade-off, see when a native-asset bridge is the right route.

What does a bridge move?

A bridge typically locks tokens on one network and releases or mints a corresponding representation on another. Some systems instead burn tokens on the source network and mint them on the destination. In either design, the bridge handles balances and cross-network messages; it does not recreate the original vesting contract’s start date, cliff or release rules.

A token trading on Biswap may still be a different contract from the vested asset. A market price or pool balance does not show whether the original vesting contract recognizes that token or its holder.

• Released tokens can usually be bridged if the token and route are supported.
• Unreleased tokens remain subject to the original contract unless the claim can be migrated.
• A destination representation needs its own vesting logic if restrictions must continue after transfer.

How should a vesting position be moved?

First, check the vesting contract’s rules for transfers, beneficiary changes and claims. Then confirm whether the destination network has a compatible token and a supported route. A transfer of the released balance is simpler than moving an unvested position, because it does not require reproducing claim rights.

If a project migrates an unvested allocation, the destination arrangement should preserve the remaining schedule and prevent the same allocation from being claimed on both networks. That usually requires contract-level controls and a verified migration process, not just a bridge transaction.

For most holders, the clearest route is to claim only what is available and bridge it through a supported route. Moving the vesting position itself is viable only when the project’s contracts explicitly preserve the restrictions.