A destination token address identifies the asset’s local representation

A destination token address identifies the contract or mint that represents an asset on the receiving chain. It is not the recipient’s wallet address, and it is not necessarily the address of the token on the source chain. The distinction matters because a bridge can deliver tokens to the correct wallet while using a different local token contract than the one a user expects.

In Wormhole’s Wrapped Token Transfers (WTT), a token is identified by its origin chain and origin token address. The destination token bridge uses that pair to find or create the corresponding wrapped asset. A comparison of Wormhole bridge transfer types covers the broader design choice; the address question here is about how one transfer type represents the asset. The destination address is the local result of that mapping, not a universal address shared across chains.

What does a destination token address identify?

It identifies the token contract or mint that the destination chain uses for that asset. On an EVM chain, this is usually an ERC-20 contract address. On Solana, it is a token mint address. Other chains use their own account or type systems, so “contract address” is not a universal format.

For WTT, the bridge’s asset identity is the tuple of origin chain and origin token address. The destination token bridge uses metadata attested from the origin to initialize a wrapped asset when one has not yet been created there. That asset represents the origin token on this destination chain. A symbol or token name alone cannot establish this identity: different contracts can share both.

The transfer also carries a recipient field. That field tells the destination bridge where to deliver or mint the tokens. It does not specify which token they are. The bridge determines the token from the authenticated transfer message and its origin information, then credits the recipient with that token.

How does the bridge resolve the destination address?

The destination token bridge resolves the address by looking up the origin chain and token address in its wrapped-asset records. On a first transfer to that chain, the token’s metadata must be attested so the bridge can create the wrapped asset. Later transfers for the same origin pair use the existing asset.

The flow separates message verification from token selection. The source bridge locks native tokens or burns wrapped tokens, then publishes a transfer message. Wormhole Guardians sign the message as a Verifiable Action Approval (VAA). Once the VAA is submitted to the destination token bridge, that bridge verifies it and processes the transfer: it releases tokens held in custody or mints the mapped wrapped asset. It also records the message as consumed to prevent replay.

This mapping means a token does not get a new identity just because it travels through an intermediate chain. In WTT, the destination representation is keyed to the original chain and token, so a transfer from the origin to a third chain can resolve to the same wrapped asset as a route that passes through another chain. Each chain still has its own local address.

The mechanism differs across transfer designs. Wormhole’s Native Token Transfers (NTT) can use burn-and-mint or hub-and-spoke arrangements, where a project manages native token contracts across chains. WTT instead uses lock-and-mint for wrapped representations. The destination address therefore depends on the transfer design and the chain, not just on the ticker displayed by a wallet.

How can you check that the address is the right one?

Check the destination chain and the full token address, then confirm that the token’s origin chain and origin address match the asset you intend to receive. A familiar symbol is not enough. For a wrapped WTT asset, check that its bridge metadata points to the intended origin pair.

• Confirm the network selected in the wallet or explorer. The same address format can exist on different chains without referring to the same token.
• Compare the full destination token address against the bridge’s record or the project’s stated deployment details.
• Inspect the origin chain and origin token address associated with a wrapped asset. Do not rely on its name, symbol, or logo.
• Keep the recipient wallet separate from the token address when reviewing transfer details. One receives the balance; the other identifies the asset.

A transfer can reach the intended wallet and still leave the user with an unexpected asset if the destination token mapping is wrong or the interface labels it poorly. Wrapped assets may also lack explorer metadata that makes their origin obvious. The address and origin pair are the useful checks; presentation fields are not proof of identity.

There is one important limit to what an address tells you. A correct destination token address confirms which local token contract or mint is involved, but it does not by itself establish that a bridge route is safe, liquid, or interchangeable with another token that has the same ticker. For WTT, the destination address is the chain-specific representation of an origin asset, resolved through the token bridge’s mapping. That is the key distinction to preserve when reviewing a transfer.