Wormhole

Wormhole is cross-Chain Messaging Validated by Guardian Signatures

Wormhole is a way for blockchains to exchange instructions, formally a cross-chain messaging protocol validated by a network of independent Guardian operators. Applications use its signed Verified Action Approvals, or VAAs, to move token representations, deliver governance actions and coordinate contracts across networks such as Ethereum and Solana.

It is a cross-chain messaging protocol for sending data and transferring assets via 13-of-19 Guardian-signed VAAs, but security depends on Guardian quorum and receiving contracts.

Guardian quorum defines the central trust boundary

The Guardian quorum decides whether Wormhole accepts a cross-chain observation, making signer integrity and source-chain observation the protocol's most consequential assumptions for every message.

The canonical set contains 19 Guardians and a valid VAA needs 13 signatures. Thirteen signatures form the two-thirds-plus quorum required to validate a Wormhole message. This threshold tolerates six unavailable Guardians; a seventh unavailable signer leaves only 12 and stops new approvals. Ethereum and Solana receive direct observation from all 19 Guardians. Some other chains use a delegated subset that observes the source first, after which canonical Guardians wait for that subset's configured quorum, confirm the agreed observation and still produce a standard 13-of-19 VAA. Delegation therefore adds a chain-specific observation assumption without changing the destination contract's signature rule.

Signature quorum authenticates what the Guardians observed; it doesn't prove that the source application was correctly designed or that its chosen finality level was conservative. Receiving contracts must also restrict the expected emitter chain and 32-byte emitter address, reject replayed messages and enforce their own limits.

That security model is transparent and uniform, while a light-client bridge asks the destination chain to verify source-chain consensus instead of relying on a fixed external signer set.

VAA fields make each approval deterministic

A VAA becomes deterministic when every signer derives the same body, allowing destination contracts to verify both Guardian signatures and application-defined message fields.

Its header starts with a 1-byte version, followed by a 4-byte Guardian-set index and a 1-byte signature count. Each signature entry adds a 1-byte Guardian index plus a 65-byte ECDSA signature. The body uses 4 bytes for the source timestamp, 4 bytes for the nonce, 2 bytes for the Wormhole chain ID, 32 bytes for the emitter address, 8 bytes for the emitter's sequence and 1 byte for the consistency level. A variable-length payload follows those fixed fields.

Guardians sign a double Keccak-256 hash of the body. The destination Core Contract checks the active Guardian set and signature threshold, then returns the parsed body to the receiving application. Because the payload is arbitrary bytes, a VAA can carry a token-transfer instruction, a governance vote or contract-specific data without giving the relayer authority to rewrite it. This separates validation from delivery, unlike bridge designs that bind both roles to one operator.

Source emission and destination execution stay separate

Another page walks through the same ground in detail. A Wormhole message completes only after a source contract emits it, Guardians approve it and someone submits the resulting VAA on the destination chain.

The Core Contract records an emitter address, sequence and consistency level in the source transaction log. A VAA is identified by a three-part tuple: emitter chain, emitter address and sequence. Wormhole chain ID 1 identifies Solana, ID 2 identifies Ethereum and ID 23 identifies Arbitrum; these protocol IDs are distinct from each network's native chain identifier. The sequence is an unsigned 64-bit counter for each emitter.

Finality enters before signing. On Solana, consistency level 1 means confirmed and level 32 means finalized. The lower setting reduces waiting time but increases exposure to a chain reorganization. Irreversible instructions therefore use the stronger setting supported by the source chain.

VAAs contain no universal destination field, so the signed proof is multicast. Application payloads narrow the intended receiver, and destination contracts decide whether to consume it. That design supports governance dispatch, Pyth data delivery and coordinated DeFi actions as well as token movement, whereas a transfer-only bridge exposes a narrower instruction set.

Financial infrastructure for the modern economy beside a pale grid

Wrapped Token Transfers preserve one origin asset

Wrapped Token Transfers preserve backing by locking an origin token and minting its representation elsewhere, then reversing that process when value returns to origin.

For an ERC-20 asset leaving Ethereum, the WTT contract holds the native token and the destination contract mints a Wormhole-wrapped representation. Returning the representation burns it and releases the locked original. SPL tokens on Solana follow the same economic pattern through chain-specific programs. Backing remains 1:1, while liquidity and contract addresses remain chain-specific.

WTT normalizes transfer amounts to 8 decimal places before encoding them. Its Transfer payload uses type ID 1, AssetMeta uses ID 2 and TransferWithPayload uses ID 3. When an asset has never reached that chain, metadata attestation precedes creation of its wrapped representation. The destination contract address distinguishes that wrapped asset from native USDC delivered through Circle CCTP, which produces native USDC instead of a Wormhole-wrapped representation.

Relay pricing combines two chain costs

Manual Wormhole delivery requires two on-chain transactions, while an automatic route asks the user to sign one source transaction and prices destination execution in advance.

The source transaction pays that chain's gas and any message fee exposed by its Core Contract. Manual delivery then needs the user or application to fund a second transaction on the destination. Executor automation obtains a signed quote from a relay provider; the quote includes route parameters, a payment amount and an expiry time. The provider pays destination gas and completes the call if the quote remains valid.

Three live inputs drive the payable amount: source gas conditions, destination gas conditions and the provider's quote. The WTT Transfer payload also carries an optional token-denominated arbiter fee that must remain below the transferred amount. Price movement and swap slippage belong to any separate exchange route, not to VAA verification itself. Compared with manual relay, Executor pricing buys a one-signature user flow and shifts destination-gas handling to the provider.

Eight-decimal normalization in one worked example

Every changing input in this hypothetical WTT example is stated here: a 9-decimal ERC-20 token, a requested 25.123456789-token transfer and a zero token-denominated relay fee. WTT keeps 8 decimal places in the transfer payload, so 25.12345678 tokens cross the bridge. The remaining 0.000000009 token is removed as dust from the encoded amount and returned to the caller. If the destination representation also exposes 9 decimals, its credited balance is 25.123456780. The concrete result is 25.12345678 tokens delivered and no ninth-decimal unit stranded in bridge custody.

Preparation starts with the route and recipient contract

A reliable Wormhole operation starts by selecting the asset model and chain pair, then confirming wallets, gas balances, recipient format and delivery path before signing.

An end user reaches the protocol through Wormhole Connect, Portal or an application that embeds the Connect widget. The route preview should identify the source asset, the destination asset contract, whether the output is wrapped or native and whether delivery is manual or automatic before the wallet presents source-chain approval. Ethereum, Solana, Arbitrum, Optimism, Base, Avalanche, Polygon and BNB Smart Chain use different gas assets or transaction formats, even where the interface unifies the steps. Keep enough native gas on the source chain for initiation; manual redemption also requires destination gas. An address valid on one chain isn't automatically valid on another virtual machine.

Record the source transaction identifier before leaving the interface. It anchors the emitter, sequence and VAA lookup if delivery pauses.

Verification has two layers. First, confirm that a quorum-signed VAA exists for the source event. Second, confirm the destination transaction succeeded and the expected contract emitted its completion event. A source confirmation alone doesn't establish destination execution. If the destination call runs out of gas or fails an application check, the same authenticated message remains available for a permitted retry.

Developers use the Wormhole TypeScript SDK, chain-specific SDKs or Core Contract interfaces. Receiver maintenance includes allowlisting emitters, recording consumed message hashes, testing Guardian-set rotations and monitoring relay quote failures. Keep integration tests on testnet for both normal delivery and retry paths.

Connect offers the shortest entry path for asset transfer, while direct Core integration gives an application tighter control over payloads, finality and recovery.

NTT and CCTP change the destination asset model

Native Token Transfers and Circle CCTP matter when the destination must receive an issuer-controlled token rather than a Wormhole-wrapped representation held against origin custody.

NTT lets a token issuer deploy native contracts across chains and choose burn-and-mint or lock-and-release operation. Its managers support per-chain inbound and outbound limits, pausing and configurable transceiver thresholds. Rate limits replenish continuously over a window whose default duration is 24 hours, although an issuer sets the final policy at deployment. The W token uses NTT across Solana and EVM networks, appearing as an SPL token on Solana and ERC-20 on Ethereum, Arbitrum, Optimism and Base.

Circle CCTP is specific to USDC. It burns native USDC on the source chain and mints native USDC on a supported destination after Circle's attestation. Wormhole messaging adds composable instructions and Executor delivery when an application uses the integration. CCTP v1 and CCTP v2 are separate route families, and both endpoints must support the selected version. WTT remains the broader option for standards-compliant tokens that don't use an issuer-native transfer system.

How did Wormhole become a messaging platform?

Wormhole became a general messaging platform by expanding a 2020 Ethereum - Solana token bridge into reusable contracts, Guardian-signed data packets and application-facing transfer tools.

The original bridge established the lock, observe, sign and redeem pattern. Subsequent releases separated generic Messaging from products built on it, including Wrapped Token Transfers, Native Token Transfers, Connect, Queries and MultiGov. That shift matters because the same VAA format now supports arbitrary application data as well as token-transfer payloads. The W governance token launched in 2024 and became natively multichain through NTT; holding W isn't required to publish an ordinary Core message.

Today the name can refer to the protocol, its transfer products or the broader developer stack. Precise evaluation starts by naming which layer an application uses. A Connect route and a custom Core message share Guardian validation, yet their custody, fee and execution paths differ from the original two-chain bridge.

The right Wormhole alternative is determined by the verifier set an application wants, the token model it needs and how much pathway configuration it will maintain.

LayerZero V2 lets each application choose required and optional Decentralized Verifier Networks for a pathway, with Executors separated from verification. That gives integrators finer control than Wormhole's shared 13-of-19 VAA rule, along with greater responsibility for matching send and receive settings. Each path can also use a different confirmation requirement in each direction.

Chainlink CCIP supplies Router contracts, decentralized oracle networks and a Cross-Chain Token standard. Axelar anchors messages in a proof-of-stake blockchain whose validators coordinate gateway activity. Both provide data and token paths, but their verification assumptions differ from a fixed Guardian quorum.

Choose by mapping custody, verification, finality, delivery and upgrade control for the exact chain pair. Wormhole offers a consistent attestation format across heterogeneous chains; LayerZero emphasizes application-configured verification, Chainlink CCIP emphasizes a managed oracle-network stack and Axelar emphasizes stake-weighted network consensus.

Wormhole questions worth asking

Does holding W pay Wormhole transfer fees?

Holding W doesn't automatically pay source gas, destination gas or relay quotes for Wormhole transfers. Each chain charges its native gas asset, and an automated route includes the relay provider's terms. W functions as a governance token and moves across supported networks through Native Token Transfers. A wallet therefore needs the route's required gas assets even when it holds W, unless the application explicitly supplies gas abstraction.

Can an old Guardian set prevent VAA redemption?

An old Guardian set can prevent a delayed VAA from verifying after that set's target-chain expiration time. The VAA header names a Guardian-set index, and the Core Contract checks that set during verification; rotation therefore creates a deadline even though the payload has no expiry field. Current Guardian observations can be gathered to rebuild the same message with active-set signatures when available. The receiving application may impose another deadline, so both signature validity and application state must be checked.

Which wallets work with Wormhole Connect?

Wormhole Connect works through the wallets enabled by the host application and the selected chains. EVM routes commonly use wallets that support Ethereum-style accounts, while Solana routes require a Solana-compatible signer; other virtual machines use their wallet formats. The decisive requirement is chain compatibility, not a universal Wormhole account. The connected wallet also needs the source asset and enough native gas for every transaction it must sign.

Is a wrapped token address identical on every chain?

A wrapped token uses a different contract or mint address on each destination chain. The WTT metadata attestation links each representation to its origin chain and origin address, while the local deployment supplies that chain's executable token contract. Symbols and names can match without making addresses interchangeable. Applications should bind balances, approvals and accounting to the exact chain-and-address pair, because an Ethereum ERC-20 address and a Solana SPL mint use entirely different address systems, account models and execution standards.

Why might destination execution lag behind source confirmation?

Destination execution follows source finality, Guardian signing, VAA availability and relay submission, so source confirmation completes only the first cross-chain stage. An automatic route also waits for a provider to act within its quote terms and pay destination gas. Manual delivery waits for the second transaction. Tracking the emitter, sequence and destination receipt separates a signing delay from a relay delay or a receiving-contract rejection.

Can a destination contract reject a valid VAA?

A destination contract can reject a cryptographically valid VAA when its application rules aren't satisfied. Core verification establishes Guardian quorum, message format and Guardian-set validity; it doesn't authorize every emitter or payload. The receiver should check the source chain, emitter address, destination fields, replay state and local limits before executing. Gas exhaustion or a contract invariant can also stop the call after VAA verification. A permitted retry uses the same authenticated body unless application state has made it ineligible.

Is one VAA usable on several chains?

A VAA is multicast at the Core protocol layer and contains no mandatory destination field. Any supported Core Contract can verify its signatures, but application payloads decide where execution is valid. A receiver checks the expected emitter chain, emitter address and destination data before acting. Broadcast designs can reuse the approval across chains, while a transfer payload remains constrained by its encoded recipient and chain fields.

Does Wormhole set an exchange rate for token transfers?

Wormhole's VAA verification doesn't set an exchange rate. A plain WTT transfer represents the same locked asset at a 1:1 backing relationship, subject to eight-decimal normalization, while CCTP burns and mints native USDC. Any conversion between assets comes from a separate swap, intent or liquidity route selected by the application. That route introduces its own pool fee, price impact and quote rules, which should be evaluated independently from Guardian signing and cross-chain delivery for the chosen route.