How does avalanche warp messaging handle cross-subnet token transfers?

31 October 2026

Avalanche Warp Messaging (AWM) is the protocol that lets independent subnets on the Avalanche network talk to each other directly. When you move a token from one subnet to another, AWM does not move the actual token. Instead, it sends a signed message that unlocks a corresponding amount of the token on the destination subnet. This is how cross-subnet token transfers work without routing through the C-Chain or relying on a centralized bridge.

The Basic Flow of a Cross-Subnet Transfer

A cross-subnet token transfer using AWM happens in three phases: burn, message, and mint. Each phase has a specific job.

Phase 1: Burn on the source subnet. You start by sending your tokens to a special contract or module on the subnet you are leaving. That contract locks or burns the tokens so they cannot be spent twice. The subnet's validators include this burn in a block, and the block becomes part of that subnet's state.

Phase 2: Sign and deliver the message. Once the burn is confirmed, a validator or relayer on the source subnet constructs an unsigned AWM message. The message contains the destination subnet's ID, the destination address, the amount, and a payload that identifies the token. The source subnet's validators then sign that message using their BLS key shares. This creates a warped message - a compact proof that the burn happened.

Phase 3: Mint on the destination subnet. The warped message is submitted to the destination subnet. That subnet's validators check the BLS signature against the source subnet's public key. If the signature is valid and the message hasn't been used before, the destination subnet mints the equivalent tokens to the address specified in the message.

The key point: the token never leaves the source subnet. What crosses the subnet boundary is a cryptographic message that proves ownership and intent. The destination subnet issues its own representation of the token.

What the warp message actually contains

An AWM message is not a big data packet. It is a compact structure with four main parts:

• Source subnet ID - identifies which subnet the transfer originated from.
• Destination subnet ID - identifies where the message is going.
• Payload - the actual transfer instructions: recipient address, token identifier, amount, and any extra data.
• BLS signature - a 96-byte aggregate signature from the source subnet's validators.

The BLS signature is what makes the message trustworthy. Avalanche subnets use a BLS multisig scheme where each validator contributes a key share. To produce a valid warp message, a threshold of validators (for example, 70% of the staked weight) must sign the same message. This threshold is defined by the source subnet's own rules. If enough validators sign, the message is considered valid by the destination subnet.

How the Destination Subnet Validates the Message

Validation is not free. The destination subnet must check three things before minting:

1. Signature validity - The BLS signature must verify against the source subnet's public key. This proves the message was signed by the source subnet's validator set.
2. Source subnet state - The destination subnet needs to know the source subnet's current validator set and public key. It gets this from the P-Chain, which tracks all subnet registrations and validator weights.
3. Nonce or replay protection - The message must not have been used before. The destination subnet tracks a nonce or a hash of previously processed messages to prevent someone replaying the same message to mint tokens twice.

If any of these checks fail, the message is rejected. If all pass, the mint happens atomically - either the full amount is minted or the message is discarded.

Important details and limitations

Token standards are not universal. AWM handles messages, not token standards. The actual token logic lives in the smart contracts on each subnet. For a cross-subnet transfer to work, both subnets must have a compatible token contract. Most subnets use ERC-20 style contracts. The payload tells the destination contract which token is being moved and how much to mint. If the destination contract does not recognize the token ID, the transfer fails.

Not every token can be moved this way. Native subnet tokens - the ones used for gas and staking - cannot be transferred via AWM in the same way as ERC-20 equivalents. Native tokens are tied to the subnet's own state and validator economics. Moving them requires a separate mechanism, often involving the P-Chain and a burn-to-unlock process. If you want to move native tokens, you typically burn them on the source subnet, send a message to the destination, and then have the destination mint its own native token. But this only works if the destination subnet has its own native token with its own supply schedule.

Bridges still exist for a reason. AWM is direct and trustless between subnets that recognize each other's validators. But it does not solve the problem of moving assets to or from other blockchains like Ethereum or Bitcoin. That still requires a bridge - either Avalanche's official bridge or a third-party one. AWM handles subnet-to-subnet transfers; it does not handle external chains.

The C-Chain is just another subnet. The C-Chain is itself a subnet on Avalanche, so AWM works between the C-Chain and any other subnet. This means you can move ERC-20 tokens from the C-Chain to a custom subnet without going through a bridge, as long as the custom subnet has the right contracts deployed. The same burn-sign-mint flow applies.

What can go wrong

AWM is not magic. It has failure modes.

• Validator threshold not met. If less than the required threshold of validators signs the message, the destination subnet will reject it. This can happen during validator rotations or if a large validator goes offline.
• Stale validator sets. The destination subnet checks the source subnet's validator set at the time of the message. If the source subnet changed validators between the burn and the message, the signature may not verify against the current set.
• Contract bugs. The burn and mint contracts are code. A bug in either can lock tokens or mint unbacked tokens. Both are serious.
• Replay attacks. If a destination subnet fails to track used messages correctly, an attacker could replay a valid message to mint tokens repeatedly. The protocol includes nonce tracking to prevent this, but it relies on correct implementation.

Practical Advice

If you are moving tokens between subnets, check the source and destination addresses carefully. AWM messages specify the destination address in the payload. If you enter the wrong address, the tokens will mint to that address. There is no reversal.

Also, verify the token contract on the destination subnet. A malicious or fake contract could accept the message and return nothing, or return a different token. The message itself does not verify token authenticity - that is the job of the destination contract.

Finally, confirm the source subnet's validator threshold. If you are moving a large amount, a subnet with a low threshold or a small validator set is more vulnerable to a malicious majority. AWM is secure as long as the source subnet's validators are honest. If a majority of the staked weight is compromised, they can sign a message that mints tokens on the destination without a corresponding burn. That is a property of the protocol, not a bug.

AWM is a clean, direct mechanism for cross-subnet transfers. It is not a bridge in the traditional sense - it does not lock assets in one place and issue a claim elsewhere. It simply lets one subnet prove to another that a burn happened. The security rests on the BLS threshold signature scheme and the honesty of the source subnet's validators. That is the whole story.

Back to avalanche