WPRC 2026#025

Wormhole 101

WPRC-025· KL· 2025. 05· INFRASTRUCTURE

Wormhole 101

Wormhole is a multichain messaging protocol that allows different blockchains to communicate with each other, acting as a trust-minimized bridge that enables users and developers to transfer data, tokens, and messages between blockchain networks.

Contributors

Shuen Rui·Yudhishthra·Wei Hup

Stable Draft

The WhitePaper Reading Club KL [03]	10 May 2025
Wormhole 101	[Shuen Rui, Yudhishthra, Wei Hup, OTHERS]
https://github.com/wormhole-foundation/wormhole/tree/main/whitepapers \| https://arena.wormhole.com/home

source: https://web3forall.xyz?id=wormhole

Summary

Wormhole is a multichain messaging protocol that allows different blockchains to communicate with each other. It acts as a trust-minimized bridge that enables users and developers to transfer data, tokens, and messages between blockchain networks.

Why This Is Important

Wormhole solves interoperability issues between different blockchains by:

Facilitating multichain smart contract execution – enabling dApps to interact across different blockchains
Bridging assets & data – allowing seamless movement of tokens, NFTs, and messages.
Providing a decentralized verification system – ensuring security through a network of independent validators called Guardians.

Key Innovation

The Core Contract on every supported chain is the on-chain hub that accepts incoming messages and produces a hash for verification. A decentralized set of Guardians observes that hash, and when a quorum is formed, they package the result into an untamperable VAA (Verified Action Approval). Relayers then fetch the VAA and deliver it to the Core Contract on the destination chain. Because the VAA is cryptographically signed by a Guardian majority, the target chain can trust it and execute the cross-chain action.

Overview

Wormhole is a leading cross-chain messaging protocol that enables secure and efficient transfers of data, tokens, and NFTs across more than 30 blockchain networks, including Ethereum, Solana, Binance Smart Chain, Polygon, Avalanche, and others. It serves as a foundational infrastructure for decentralized applications (dApps) in DeFi, NFTs, gaming, and governance by facilitating interoperability between otherwise incompatible blockchains. Below is a detailed update on its status, covering recent developments, technical advancements, ecosystem growth, and challenges.

Team

Launched in 2020 by Certus One (later acquired by Jump Trading), Wormhole initially focused on bridging Ethereum and Solana. It has since evolved into a general-purpose messaging protocol (Wormhole V2) that supports over 30 blockchains.

Key Components

Generic Message-Passing Core (VAA):

Problem	Early-stage Wormhole was coupled to a single application: token-bridging between Solana and Ethereum. The envelope that left one chain and appeared on another already contained fields such as Asset, Amount, TargetChain, and TargetAddress. Every time the community wanted to add NFTs, stream oracle data to many chains, or build “slow-path / fast-path” insured transfers. The core protocol itself had to be patched. That tight coupling slowed shipping, complicated audits, and forced every new idea to inherit the same custody semantics even if it only needed a lightweight attestation.
Solution	Wormhole v2 introduces a generic, application-agnostic envelope called a Verifiable Action Approval (VAA). The VAA header has only three jobs that is to prove who signed it (GuardianSetIndex, Signatures[]), prove which event it refers to (EmitterChain, EmitterAddress, Sequence) and convey the integrator’s latency vs. finality preference (ConsistencyLevel). Everything else like routing, asset identifiers, custom logic lives inside an opaque Payload []byte (≤ 750 bytes).// signed portion ↓Timestamp \| Nonce \| EmitterChain \| EmitterAddressSequence \| ConsistencyLevel \| Payload[≤750]// signed portion ↑
How it works	1. postMessageAny contract calls postMessage(payload, confirmations) on its local Wormhole Core contract.The Core contract:checks len(payload) ≤ 750,bumps a per-emitter Sequence,emits a log containing (EmitterChain, EmitterAddress, Sequence, ConsistencyLevel, Payload).2. Guardian observation & consistency gateEvery guardian node watches that chain.It waits until the block reaches the requested ConsistencyLevel EVM: 200 = publish now, 201 = wait for safe, default = finalized Solana: 0 = Confirmed, 32 = Finalized Once satisfied, it constructs the unsigned body and signs doubleKeccak256(body).3. Quorum & gossipWhen 13 / 19 signatures are collected, the guardian network broadcasts the fully-signed VAA over the Wormhole P2P mesh.4. Delivery (outside the core)Any relayer, wallet, or end-user can fetch the VAA from a guardian or “spy” node (GET /vaa/:chain/:emitter/:seq) and submit it to the destination chain’s Core contract. verifyVAA checks the sigs and dispatches the opaque Payload to the xApp that cares about it.

Problem

Early-stage Wormhole was coupled to a single application: token-bridging between Solana and Ethereum. The envelope that left one chain and appeared on another already contained fields such as Asset, Amount, TargetChain, and TargetAddress. Every time the community wanted to add NFTs, stream oracle data to many chains, or build “slow-path / fast-path” insured transfers. The core protocol itself had to be patched. That tight coupling slowed shipping, complicated audits, and forced every new idea to inherit the same custody semantics even if it only needed a lightweight attestation.

Solution

Wormhole v2 introduces a generic, application-agnostic envelope called a Verifiable Action Approval (VAA). The VAA header has only three jobs that is to prove who signed it (GuardianSetIndex, Signatures[]), prove which event it refers to (EmitterChain, EmitterAddress, Sequence) and convey the integrator’s latency vs. finality preference (ConsistencyLevel). Everything else like routing, asset identifiers, custom logic lives inside an opaque Payload []byte (≤ 750 bytes).// signed portion ↓Timestamp | Nonce | EmitterChain | EmitterAddressSequence | ConsistencyLevel | Payload[≤750]// signed portion ↑

How it works

1. postMessageAny contract calls postMessage(payload, confirmations) on its local Wormhole Core contract.The Core contract:checks len(payload) ≤ 750,bumps a per-emitter Sequence,emits a log containing (EmitterChain, EmitterAddress, Sequence, ConsistencyLevel, Payload).2. Guardian observation & consistency gateEvery guardian node watches that chain.It waits until the block reaches the requested ConsistencyLevel EVM: 200 = publish now, 201 = wait for safe, default = finalized Solana: 0 = Confirmed, 32 = Finalized Once satisfied, it constructs the unsigned body and signs doubleKeccak256(body).3. Quorum & gossipWhen 13 / 19 signatures are collected, the guardian network broadcasts the fully-signed VAA over the Wormhole P2P mesh.4. Delivery (outside the core)Any relayer, wallet, or end-user can fetch the VAA from a guardian or “spy” node (GET /vaa/:chain/:emitter/:seq) and submit it to the destination chain’s Core contract. verifyVAA checks the sigs and dispatches the opaque Payload to the xApp that cares about it.

Cross-Chain Queries (CCQ)

Problem	Until CCQ, Wormhole guardians could only attest to events that were first pushed on-chain by a contract calling postMessage. To prove something about Ethereum you had to deploy a helper contract on Ethereum, call it (paying gas) every time you needed fresh data and wait for block + finality, then wait for guardians to publish a VAA. That meant minutes of latency and ~$5–$20 in gas for what might be a single eth_call. The model also broke down for wallets or servers that just wanted an occasional attestation without deploying contracts everywhere.
Solution	CCQ adds a pull channel where integrators send a query request to the guardian mesh and get back an attested response without any source-chain transaction. Two P2P topics: ccq_req (requests) and ccq_resp (signed answers). Guardians join but do not subscribe to ccq_resp, so they never echo each other’s results. Requests are signed blobs with a 35-byte domain prefix (mainnet_query_request_… \|, testnet_query_request_… \|, devnet_query_request_… \|) that the guardian verifies before accepting. First release supports off-chain requests only; on-chain requests via a future “CCQ contract” are sketched but not live.
How it works	Build & sign requestOff-chain client encodes a QueryRequest {version, nonce, per-chain[]}, signs it with an allow-listed key and posts it to a CCQ REST server (or publishes directly).Guardian validationVerify prefix & ECDSA sig - check signer in ccqAllowedRequesters & peer ID in ccqAllowedPeers - sanity-check each per-chain sub-query (lengths, block-id rules, etc.).ExecutionGuardian forwards each per-chain query to its local watcher pool:EVM: supports eth_call, eth_call_by_timestamp, eth_call_with_finality.Solana: supports sol_account, sol_pda. Watchers batch RPCs to minimize node load; for …with_finality they wait until the target block is safe or finalized before returning. Publish resultIf all sub-queries succeed ≤ 1 min, guardian gossips a ccq_resp that embeds the original request plus results, signed with prefix query_response…\| Guardians ignore each other’s responses; only REST servers or power users receive them. Quorum aggregationIntegrator (or REST) collects responses until ≥ 13 matching signatures from the current set index; the bytes + sigs are now an attested proof that can be stored or shipped on-chain.

Problem

Until CCQ, Wormhole guardians could only attest to events that were first pushed on-chain by a contract calling postMessage. To prove something about Ethereum you had to deploy a helper contract on Ethereum, call it (paying gas) every time you needed fresh data and wait for block + finality, then wait for guardians to publish a VAA. That meant minutes of latency and ~$5–$20 in gas for what might be a single eth_call. The model also broke down for wallets or servers that just wanted an occasional attestation without deploying contracts everywhere.

Solution

CCQ adds a pull channel where integrators send a query request to the guardian mesh and get back an attested response without any source-chain transaction. Two P2P topics: ccq_req (requests) and ccq_resp (signed answers). Guardians join but do not subscribe to ccq_resp, so they never echo each other’s results. Requests are signed blobs with a 35-byte domain prefix (mainnet_query_request_… |, testnet_query_request_… |, devnet_query_request_… |) that the guardian verifies before accepting. First release supports off-chain requests only; on-chain requests via a future “CCQ contract” are sketched but not live.

How it works

Build & sign requestOff-chain client encodes a QueryRequest {version, nonce, per-chain[]}, signs it with an allow-listed key and posts it to a CCQ REST server (or publishes directly).Guardian validationVerify prefix & ECDSA sig - check signer in ccqAllowedRequesters & peer ID in ccqAllowedPeers - sanity-check each per-chain sub-query (lengths, block-id rules, etc.).ExecutionGuardian forwards each per-chain query to its local watcher pool:EVM: supports eth_call, eth_call_by_timestamp, eth_call_with_finality.Solana: supports sol_account, sol_pda. Watchers batch RPCs to minimize node load; for …with_finality they wait until the target block is safe or finalized before returning. Publish resultIf all sub-queries succeed ≤ 1 min, guardian gossips a ccq_resp that embeds the original request plus results, signed with prefix query_response…| Guardians ignore each other’s responses; only REST servers or power users receive them. Quorum aggregationIntegrator (or REST) collects responses until ≥ 13 matching signatures from the current set index; the bytes + sigs are now an attested proof that can be stored or shipped on-chain.

Integrity Checkers on Wormchain

Problem	In a purely distributed xApp such as Portal Token-Bridge, every chain is a peer: each contract mints / burns and sends messages directly to every other chain. That removes hub latency but destroys global visibility; no contract can see balances or invariants outside its own chain. One exploited side-chain can therefore mint un-backed wrappers and drain native assets from honest chains . Hub-and-spoke designs can enforce global rules (because all transfers route through the hub) but add cost, latency, and a single-chain trust anchor. Wormhole needed hub-level coherence without bringing back a hub.
Solution	Integrity Checkers are CosmWasm smart-contracts on Wormchain that act as stateless judges:Guardians must send a pre-observation (signed blob with its own prefix) for any emitter that is registered with a checker.The checker holds a synchronized, cross-chain state (e.g., locked-vs-minted balances) and decides Commit or Error.It can only block; it cannot mint, modify, or inject messages. Guardians still create the final VAA after approval .Because the logic lives on Wormchain, every guardian sees the same verdict in one Tendermint block—restoring hub-like invariants while keeping xApp latency near the distributed ideal.
How it works	1. Observation: guardian sees a Token-Bridge log on chain X.2. Pre-observation: guardian wraps the log in a pre-obs packet (distinct signature prefix) and batches it with others for the next Wormchain tx, saving gas and CPU.3. Checker execution (on Wormchain):looks up global state,if invariant holds ➜ emits Committed event (or Error).4. Guardian picks event: if event matches its own pre-obs, it adds a normal VAA signature and continues consensus.5. Persistence & retry: guardian records status locally; a watcher re-submits any pre-obs that failed or were missed.

Problem

In a purely distributed xApp such as Portal Token-Bridge, every chain is a peer: each contract mints / burns and sends messages directly to every other chain. That removes hub latency but destroys global visibility; no contract can see balances or invariants outside its own chain. One exploited side-chain can therefore mint un-backed wrappers and drain native assets from honest chains . Hub-and-spoke designs can enforce global rules (because all transfers route through the hub) but add cost, latency, and a single-chain trust anchor. Wormhole needed hub-level coherence without bringing back a hub.

Solution

Integrity Checkers are CosmWasm smart-contracts on Wormchain that act as stateless judges:Guardians must send a pre-observation (signed blob with its own prefix) for any emitter that is registered with a checker.The checker holds a synchronized, cross-chain state (e.g., locked-vs-minted balances) and decides Commit or Error.It can only block; it cannot mint, modify, or inject messages. Guardians still create the final VAA after approval .Because the logic lives on Wormchain, every guardian sees the same verdict in one Tendermint block—restoring hub-like invariants while keeping xApp latency near the distributed ideal.

How it works

1. Observation: guardian sees a Token-Bridge log on chain X.2. Pre-observation: guardian wraps the log in a pre-obs packet (distinct signature prefix) and batches it with others for the next Wormchain tx, saving gas and CPU.3. Checker execution (on Wormchain):looks up global state,if invariant holds ➜ emits Committed event (or Error).4. Guardian picks event: if event matches its own pre-obs, it adds a normal VAA signature and continues consensus.5. Persistence & retry: guardian records status locally; a watcher re-submits any pre-obs that failed or were missed.

Questions

[1] Has anyone prototyped a ZK-verified VAA to make target chains trust-less with fewer guardian signs, or does that break the social-layer recovery model

[2] Would you consider chain-specific enums instead of the generic 0/200/201? For example, an L2 with single-slot finality might need finer granularity than Ethereum.

[3] What’s the most common misconception you hear about cross-chain security?

[4] $W staking is cool, but I would like to know the purpose of the staking program. Is it related to selling pressure?

References

[1] https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0001_generic_message_passing.md

[2] https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0013_ccq.md

[3] https://web3forall.xyz?id=wormhole

[4] https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0010_integrity_checkers.md

[5] https://arena.wormhole.com/

[6] https://wormhole.com/products/native-token-transfers

Cheat Sheet

What is Wormhole?

Which Blockchains Does Wormhole Support?

More than 35 blockchains, but no Bitcoin Mainnet :(

https://wormhole.com/platform/blockchains

Wormhole Use Case

Many major projects and DApps rely on Wormhole for multichain interactions:

DeFi Platforms

Uniswap – Uses Wormhole to expand its DEX liquidity across chains.

Raydium – A Solana-based DEX that connects with Ethereum assets via Wormhole.

Saber – Uses Wormhole for multichain stablecoin swaps.

NFT Marketplaces & Gaming

Magic Eden – Allows multichain NFT trading.

Star Atlas – A blockchain game leveraging multichain NFTs and assets.

Stablecoins & Payments

USDC (Circle’s stablecoin) – Wormhole enables native USDC transfers between chains via CCTP (Cross-Chain Transfer Protocol).

Portal Bridge – A key Wormhole-powered bridge for moving assets securely across networks.

How Wormhole works?

Wormhole operates using four main components, each playing a vital role in verifying and relaying multichain messages.

These components are:

Core Contract – The Foundation
Guardians – The Security Layer
VAAs (Verified Action Approvals) – The Multichain Ticket
Relayers – The Messenger Service

Feature of the components

Core Contract – The Foundation

Think of the Core Contract as the heart of Wormhole on each blockchain.

Receives messages from dApps on its blockchain.
Generates a unique transaction hash that gets validated by Guardians.
Verifies incoming messages from other chains before executing them.

Why It Matters: Without the Core Contract, there’s no way to send or receive multichain data securely.

Guardians – The Security Layer

Guardians are a decentralized network of validators responsible for securing multichain messages.

Observe transactions happening on one chain.
Sign messages using a cryptographic system to confirm their validity.
Form a quorum (majority agreement) to prevent fraud.

Why It Matters: Instead of relying on a single validator (which would be a security risk), Wormhole uses a distributed set of Guardians, ensuring transactions are trust-minimized and resistant to attacks.

VAAs (Verified Action Approvals) – The Multichain Ticket

Once Guardians approve a multichain transaction, they create a VAA (Verified Action Approval). This is like a cryptographically signed message that ensures:

The transaction was observed and approved by the majority of Guardians.
The message can’t be tampered with after approval.
The receiving blockchain can trust the message and execute it accordingly.

Why It Matters: VAAs eliminate the need for a central authority—instead, they let blockchains communicate securely through verified cryptographic messages.

Relayers – The Messenger Service

Relayers deliver VAAs to their destination blockchain so that transactions can be executed.

Pick up approved VAAs from the Guardians.
Deliver them to the Core Contract of the target blockchain.
Ensure multichain transactions are completed successfully.

Why It Matters: While VAAs prove that a transaction is valid, relayers actually deliver them across chains, making them the final piece of the puzzle.

How It All Comes Together?

Let’s summarize the entire multichain messaging process:

A dApp sends a message to the Core Contract on Chain A.
Guardians validate the transaction and create a VAA.
Relayers deliver the VAA to the Core Contract on Chain B.
The Core Contract executes the transaction on Chain B.

A user bridges an NFT from Ethereum to Solana:

Ethereum’s Core Contract registers the request.
Guardians approve the transfer and generate a VAA.
A relayer delivers the VAA to Solana.
Solana mints the NFT on its network, completing the transfer.

What is the Wormhole Token Bridge?

The Wormhole Token Bridge allows users to move assets across different blockchains without using centralized exchanges. Instead of swapping tokens directly, it locks assets on the source chain and mints equivalent wrapped tokens on the destination chain.

🔗 Example Use Case

Suppose a user wants to move USDC from Ethereum to Solana:

USDC is locked in a smart contract on Ethereum.
A VAA (Verified Action Approval) is generated and verified by Guardians.
Wrapped USDC is minted on Solana, representing the original asset.

📌 Why It Matters:

Removes reliance on centralized exchanges – No need to trust a third party.
Improves liquidity flow – DeFi users can access assets across multiple chains.
Enables multichain interactions – Assets can be used across different ecosystems.

How Does It Work?

Step 1: Locking Tokens on the Source Chain

Users deposit tokens (e.g., ETH, USDC, SOL) into the Token Bridge smart contract.
These tokens are held in escrow, ensuring they cannot be used on the source chain while their wrapped version exists elsewhere.

Step 2: VAA Generation & Guardian Validation

The Guardians (Wormhole validators) observe the transaction.
A VAA (Verified Action Approval) is created once a majority of Guardians sign off.

Step 3: Minting Tokens on the Destination Chain

The VAA is submitted to the Token Bridge contract on the destination chain.
Equivalent wrapped tokens are minted, representing the locked tokens.

Step 4: Redeeming Tokens (Optional)

Users can burn their wrapped tokens to unlock the original assets back on the source chain.
The burning process removes the wrapped tokens, ensuring that the supply remains 1:1 with the locked assets.

📌 Example Transaction:

Suppose a trader wants to move ETH from Ethereum to Solana for lower gas fees:

ETH is locked on Ethereum’s Token Bridge contract.
Wrapped ETH (WETH) is minted on Solana.
The trader uses WETH for DeFi trading on Solana-based DEXs like Raydium.
WETH can be redeemed back to ETH on Ethereum at any time.

💰 What is CCTP?

CCTP (Cross-Chain Transfer Protocol) is a secure and efficient way to move USDC across blockchains without relying on wrapped tokens. Unlike traditional bridges that use a lock-and-mint mechanism, CCTP burns USDC on the source chain and mints an equivalent amount on the destination chain.

🔗 Example Use Case:

Suppose a DeFi trader wants to move USDC from Ethereum to Avalanche:

USDC is burned on Ethereum.
A VAA (Verified Action Approval) is generated and validated by Wormhole Guardians.
Circle, the issuer of USDC, mints an equal amount of native USDC on Avalanche.

📌 Why It Matters:

No Wrapped USDC – The transferred USDC remains native on the new chain.
More secure – Eliminates risks associated with token wrapping, reducing potential vulnerabilities.
Improves DeFi liquidity – Avoids fragmented versions of USDC, making transactions smoother and liquidity deeper.

🔄 How Does It Work?

Step 1: Burning USDC on the Source Chain

A user initiates a transfer by burning USDC in a Circle-controlled contract on the source chain.
This burn reduces the circulating supply on the original blockchain, ensuring accurate balances.

Step 2: VAA Generation & Guardian Validation

Wormhole Guardians observe and confirm the burn event, generating a VAA (Verified Action Approval).
The VAA provides proof of the burn event and prevents double-spending.

Step 3: Minting USDC on the Destination Chain

The VAA is submitted to Circle on the destination chain.
Circle mints an equivalent amount of native USDC from its reserves directly onto the destination chain.

📌 Why This Is Different from Token Bridges:

No locking, no wrapping – Traditional bridges lock the original token and mint a wrapped version.
USDC remains fully redeemable – CCTP ensures that only native USDC exists on all supported chains.

🔍 CCTP vs. Traditional Token Bridges

📌 Takeaway:If you're transferring USDC, CCTP is the preferred method since it guarantees native USDC instead of wrapped versions. However, if you’re moving other assets, you’ll still need the Token Bridge.

🔄 What is NTT?

NTT (Native Token Transfers) is a trust-minimized framework that allows native tokens to move across different blockchains without being wrapped. Unlike traditional lock-and-mint bridges, NTT preserves the original token and ensures that it maintains its fungibility and utility across multiple networks.

🔗 Example Use Case:

A DeFi protocol wants its governance token to move seamlessly between Ethereum and Solana, maintaining identical contract logic on both chains.

📌 Why It Matters:

No Wrapped Tokens – Token remains native on every blockchain.
Reduced Bridging Risks – Eliminates dependency on wrapped assets, minimizing security vulnerabilities.
Simplifies Liquidity Management – Users don’t have to manage multiple versions of the same token.

🔬 How Does NTT Work?

Step 1: Token Locking & Minting

A token issuer establishes liquidity pools or vaults on each blockchain where the token will be available.
When a transfer occurs, tokens are burned on the source chain and minted natively on the destination chain, preserving a fixed total supply.

Step 2: VAA Generation & Validation

Guardians validate the token transfer request.
A VAA (Verified Action Approval) is generated to authorize minting on the destination chain.

Step 3: Native Minting on the Destination Chain

The token is minted natively on the destination blockchain instead of a wrapped version.
The token retains its original functionality and doesn’t require an intermediary contract.

📌 Key Difference from Token Bridge:

Traditional Token Bridge locks assets and mints wrapped tokens, which may not always be fungible across chains.
NTT ensures tokens remain consistent, native, and fungible across chains.

🔍 NTT vs. Traditional Token Bridges

If you're transferring a natively issued token, NTT is the best choice as it avoids wrapping and ensures liquidity remains unified.

Start building here: https://wormhole.com/products/native-token-transfers

🔍 What is the Wormhole Explorer?

The Wormhole Blockchain Explorer is a tool that allows users and developers to track multichain transactions in real time. Whether you’re moving tokens, sending messages, or interacting with smart contracts, the Explorer provides clear visibility at every step of the transaction process.

📌 Why It’s Important:

Verify Multichain Transactions – Confirm whether your token or message successfully reached the destination chain.
Monitor VAAs (Verified Action Approvals) – Check if Wormhole Guardians have approved your transaction.
Debug Smart Contracts – Developers can troubleshoot failed transactions and optimize integrations.

🔗 Try it here: https://wormholescan.io/

🛠 How to Use the Wormhole Explorer

1️⃣ Tracking a Transaction

To track a multichain transfer, follow these steps:

Go to the Explorer → https://wormholescan.io
Enter your transaction ID or wallet address in the search bar.
View details like:
Source & destination chains (e.g., Ethereum → Solana)
Token amount & type
Transaction status (Pending, Confirmed, Failed)
Guardian Signatures

📌 Pro Tip: If a transaction is stuck, check whether the VAA has been generated and relayed.

2️⃣ Understanding the VAA (Verified Action Approval)

Each multichain transaction in Wormhole generates a VAA, which is cryptographic proof that the transfer is valid.Key VAA Details in the Explorer:

Emitter Address – The contract that initiated the transfer.
Sequence Number – A unique identifier for the transaction.
Signatures – Verification from Wormhole Guardians.
Status – Whether the VAA has been processed or pending on the target chain.

📌 Why This Matters:

Developers use VAAs to debug smart contract execution.
Users can confirm their assets have been safely transferred to the destination chain.

3️⃣ Debugging Failed Transactions

If a multichain transfer fails, the Wormhole Explorer helps diagnose the issue:📌 Troubleshooting Tip: Developers can manually submit VAAs via Wormhole’s SDK if a transaction isn't relayed automatically.

✅ Summary: Why Use the Wormhole Explorer?

By using the Explorer, both developers and users can efficiently manage multichain transactions and swiftly address issues.

What is Wormhole Connect?

Wormhole Connect is a powerful integration component that enables seamless asset transfers across blockchain networks within web applications. It provides users with an intuitive and user-friendly interface to easily move assets across different blockchain networks via the Wormhole protocol.

Features of Wormhole Connect ✨

Simple Integration 🔌: As a React component, it can be integrated into Web applications with just a few lines of code.
Highly Customizable 🎨: Customize appearance and functionality, including supported chains, tokens, and theme styles.
Multiple Bridging Options 🌐: Supports various cross-chain transfer methods, offering flexible choices.
Seamless User Experience 👥: Users can complete all transactions through a single, unified interface, greatly simplifying cross-chain interactions.

Core Functions of Wormhole Connect 🛠️

Token Bridge 🔄

Locks assets on the source chain and mints Wormhole-wrapped "IOU" tokens on the destination chain. When assets are transferred back, wrapped tokens are burned and original tokens are unlocked.

Token Bridge Relayer (Automatic Routing) ⚡

Through relayers, users only need to execute one transaction on the source chain for tokens to automatically arrive at the destination chain.

Circle CCTP 💲

For USDC transfers, Circle enables native token transfers between CCTP-supported chains without needing wrapped tokens..

ETH Bridge 💎

Leverages Uniswap liquidity pools to transfer native ETH or wstETH between specific EVM chains.

Gas Drop Off ⛽

Relayers can automatically convert part of the transferred assets into gas tokens on the destination chain, resolving the issue of users lacking gas for transactions.

Multi-Chain Support 🔗

Wormhole Connect supports multiple blockchain networks, including Ethereum, Solana, Polygon, Avalanche, BSC, and more. Different chains support different features, see the official multi-chain support matrix for details.In the upcoming lessons, we'll build a cross-chain reimbursement application using Wormhole Connect, exploring how to leverage these features for a smooth cross-chain experience. 🚀

Start building here: https://wormhole.com/products/connect

Token bridging forms the foundation for value transfer between blockchains. While there are various cross-chain solutions, their core processes typically follow similar patterns.. Let's explore these common steps.

Token Bridging Process 🔄

Taking the most common lock-and-mint model as an example, here's the basic token bridging flow:

Cross-Chain Steps from a User’s Perspective 👤

From a user's perspective, the cross-chain process typically includes:

Connect Wallet 👛
Select Source and Destination Chains 🌐
Choose Token and Amount 💰
Approve Token Spending ✓
Confirm Cross-Chain Transaction ✅
Pay Source Chain Gas Fee ⛽
Wait for Cross-Chain Confirmation ⏱️
Receive Assets on Destination Chain 📥

Discussion

Wormhole Key Innovation (3)

1. Multi-Modal Cross-Chain Solutions

Wormhole offers a suite of cross-chain products, not just a single bridge. These include:

Connect: A plug-and-play UI for easy token bridging.
Native Token Transfers (NTT): Enables true native token movement across chains, not just wrapped assets.
Token Bridge: Uses a lock-and-mint mechanism for wrapped assets.
Settlement: An intent-based protocol for fast, optimized, and non-custodial multichain transfers, moving beyond traditional bridging models. This modular approach allows projects to choose the best tool for their needs, from simple UI integration to advanced liquidity optimization and governance across chains. Wormhole Docs: Product Comparison

2. Decentralized Guardian Network

Unlike some competitors that rely on a single relayer or a small set of validators, Wormhole uses a decentralized set of “Guardians” (operated by reputable entities) to observe and attest to cross-chain events. This distributed trust model increases security and resilience, making it harder to compromise the protocol as a whole. Wormhole for Developers: Architecture

3. Generic Messaging Layer

Wormhole is not limited to token transfers. Its messaging protocol allows arbitrary data, smart contract calls, and governance actions to be sent between chains. This enables complex cross-chain applications, such as multichain DAOs, NFT transfers, and real-time data queries, which many competitors do not support as flexibly.

Wormhole features

Multichain asset transfers aren’t one-size-fits-all. Different projects have different needs—some want simple bridging, while others need deeper integration for smart contract interactions.That’s why Wormhole offers various transfer solutions, each designed for specific use cases. Let’s take a high-level look before diving into each one.

1. Wormhole Connect – Pre-Built Bridging UI

Best for: Projects looking for a plug-and-play UI for token transfers, without modifying smart contracts.

✅ Key Features

Minimal setup – No contract deployment required.
Easy integration – A simple front-end solution for users.
Supports native & wrapped assets – Flexible token support.

📌 Use Case Example:

A DeFi app wants to offer multichain bridging without requiring custom contract development.

2. Native Token Transfers (NTT) – Transfer Multichain Native Tokens

Best for: Projects that need to preserve native token functionality across multiple blockchains.

✅ Key Features

No wrapped assets – Tokens remain native on all chains.
Event-based actions – Can trigger smart contract execution on the receiving chain.
Requires contract integration – Developers must modify smart contracts for full functionality.

📌 Use Case Example:

A lending protocol wants users to move native tokens between chains without converting them to wrapped versions.

3. Token Bridge – Lock-and-Mint Asset Transfers

Best for: Projects needing multichain liquidity using wrapped assets and the ability to send messages along with transfers.

✅ Key Features

Supports wrapped assets – Locks tokens on one chain, mints them on another.
Enables multichain smart contract interactions – Can send instructions alongside token transfers.
Does not support native tokens – Requires token wrapping.

📌 Use Case Example:

A multichain DEX allows users to transfer tokens between blockchains while sending additional transaction data for liquidity routing.

Interesting Design Choices

Design Choice	Trade off & Benefit
Opaque Payload	Core no longer “knows” about tokens or NFTs. Anything from an oracle price to a DAO vote bitmap fits inside one envelope. Future apps don’t require protocol forks.
Sequence per (EmitterChain, EmitterAddress)	Guarantees total ordering for a single emitter without forcing a global counter that could become a bottleneck.
ConsistencyLevel flag	Lets latency-sensitive apps (e.g., cross-chain DEX quotes) publish instantly on optimistic rollups while letting treasury-size transfers demand finality on Ethereum one byte of optionality saves whole seconds or minutes.
Double-hash + guardian multisig	A 32-byte digest is trivial for any chain to verify, regardless of its native crypto. Length-extension attacks are impossible because the body is hashed twice before signing.
Decoupled delivery	Core never pushes a message; that responsibility moves to relayers or user wallets. This keeps the on-chain footprint tiny and means any transport (IBC, REST, email even QR codes) can carry a VAA.

Stable Draft

The WhitePaper Reading Club KL [03]	10 May 2025
Wormhole 101	[Shuen Rui, Yudhishthra, Wei Hup, OTHERS]
https://github.com/wormhole-foundation/wormhole/tree/main/whitepapers \| https://arena.wormhole.com/home

source: https://web3forall.xyz?id=wormhole

Summary

Why This Is Important

Wormhole solves interoperability issues between different blockchains by:

Facilitating multichain smart contract execution – enabling dApps to interact across different blockchains
Bridging assets & data – allowing seamless movement of tokens, NFTs, and messages.
Providing a decentralized verification system – ensuring security through a network of independent validators called Guardians.

Key Innovation

Overview

Team

Key Components

Generic Message-Passing Core (VAA):

Problem	Early-stage Wormhole was coupled to a single application: token-bridging between Solana and Ethereum. The envelope that left one chain and appeared on another already contained fields such as Asset, Amount, TargetChain, and TargetAddress. Every time the community wanted to add NFTs, stream oracle data to many chains, or build “slow-path / fast-path” insured transfers. The core protocol itself had to be patched. That tight coupling slowed shipping, complicated audits, and forced every new idea to inherit the same custody semantics even if it only needed a lightweight attestation.
Solution	Wormhole v2 introduces a generic, application-agnostic envelope called a Verifiable Action Approval (VAA). The VAA header has only three jobs that is to prove who signed it (GuardianSetIndex, Signatures[]), prove which event it refers to (EmitterChain, EmitterAddress, Sequence) and convey the integrator’s latency vs. finality preference (ConsistencyLevel). Everything else like routing, asset identifiers, custom logic lives inside an opaque Payload []byte (≤ 750 bytes).// signed portion ↓Timestamp \| Nonce \| EmitterChain \| EmitterAddressSequence \| ConsistencyLevel \| Payload[≤750]// signed portion ↑
How it works	1. postMessageAny contract calls postMessage(payload, confirmations) on its local Wormhole Core contract.The Core contract:checks len(payload) ≤ 750,bumps a per-emitter Sequence,emits a log containing (EmitterChain, EmitterAddress, Sequence, ConsistencyLevel, Payload).2. Guardian observation & consistency gateEvery guardian node watches that chain.It waits until the block reaches the requested ConsistencyLevel EVM: 200 = publish now, 201 = wait for safe, default = finalized Solana: 0 = Confirmed, 32 = Finalized Once satisfied, it constructs the unsigned body and signs doubleKeccak256(body).3. Quorum & gossipWhen 13 / 19 signatures are collected, the guardian network broadcasts the fully-signed VAA over the Wormhole P2P mesh.4. Delivery (outside the core)Any relayer, wallet, or end-user can fetch the VAA from a guardian or “spy” node (GET /vaa/:chain/:emitter/:seq) and submit it to the destination chain’s Core contract. verifyVAA checks the sigs and dispatches the opaque Payload to the xApp that cares about it.

Problem

Solution

How it works

Cross-Chain Queries (CCQ)

Problem	Until CCQ, Wormhole guardians could only attest to events that were first pushed on-chain by a contract calling postMessage. To prove something about Ethereum you had to deploy a helper contract on Ethereum, call it (paying gas) every time you needed fresh data and wait for block + finality, then wait for guardians to publish a VAA. That meant minutes of latency and ~$5–$20 in gas for what might be a single eth_call. The model also broke down for wallets or servers that just wanted an occasional attestation without deploying contracts everywhere.
Solution	CCQ adds a pull channel where integrators send a query request to the guardian mesh and get back an attested response without any source-chain transaction. Two P2P topics: ccq_req (requests) and ccq_resp (signed answers). Guardians join but do not subscribe to ccq_resp, so they never echo each other’s results. Requests are signed blobs with a 35-byte domain prefix (mainnet_query_request_… \|, testnet_query_request_… \|, devnet_query_request_… \|) that the guardian verifies before accepting. First release supports off-chain requests only; on-chain requests via a future “CCQ contract” are sketched but not live.
How it works	Build & sign requestOff-chain client encodes a QueryRequest {version, nonce, per-chain[]}, signs it with an allow-listed key and posts it to a CCQ REST server (or publishes directly).Guardian validationVerify prefix & ECDSA sig - check signer in ccqAllowedRequesters & peer ID in ccqAllowedPeers - sanity-check each per-chain sub-query (lengths, block-id rules, etc.).ExecutionGuardian forwards each per-chain query to its local watcher pool:EVM: supports eth_call, eth_call_by_timestamp, eth_call_with_finality.Solana: supports sol_account, sol_pda. Watchers batch RPCs to minimize node load; for …with_finality they wait until the target block is safe or finalized before returning. Publish resultIf all sub-queries succeed ≤ 1 min, guardian gossips a ccq_resp that embeds the original request plus results, signed with prefix query_response…\| Guardians ignore each other’s responses; only REST servers or power users receive them. Quorum aggregationIntegrator (or REST) collects responses until ≥ 13 matching signatures from the current set index; the bytes + sigs are now an attested proof that can be stored or shipped on-chain.

Problem

Solution

How it works

Integrity Checkers on Wormchain

Problem	In a purely distributed xApp such as Portal Token-Bridge, every chain is a peer: each contract mints / burns and sends messages directly to every other chain. That removes hub latency but destroys global visibility; no contract can see balances or invariants outside its own chain. One exploited side-chain can therefore mint un-backed wrappers and drain native assets from honest chains . Hub-and-spoke designs can enforce global rules (because all transfers route through the hub) but add cost, latency, and a single-chain trust anchor. Wormhole needed hub-level coherence without bringing back a hub.
Solution	Integrity Checkers are CosmWasm smart-contracts on Wormchain that act as stateless judges:Guardians must send a pre-observation (signed blob with its own prefix) for any emitter that is registered with a checker.The checker holds a synchronized, cross-chain state (e.g., locked-vs-minted balances) and decides Commit or Error.It can only block; it cannot mint, modify, or inject messages. Guardians still create the final VAA after approval .Because the logic lives on Wormchain, every guardian sees the same verdict in one Tendermint block—restoring hub-like invariants while keeping xApp latency near the distributed ideal.
How it works	1. Observation: guardian sees a Token-Bridge log on chain X.2. Pre-observation: guardian wraps the log in a pre-obs packet (distinct signature prefix) and batches it with others for the next Wormchain tx, saving gas and CPU.3. Checker execution (on Wormchain):looks up global state,if invariant holds ➜ emits Committed event (or Error).4. Guardian picks event: if event matches its own pre-obs, it adds a normal VAA signature and continues consensus.5. Persistence & retry: guardian records status locally; a watcher re-submits any pre-obs that failed or were missed.

Problem

Solution

How it works

Questions

[1] Has anyone prototyped a ZK-verified VAA to make target chains trust-less with fewer guardian signs, or does that break the social-layer recovery model

[2] Would you consider chain-specific enums instead of the generic 0/200/201? For example, an L2 with single-slot finality might need finer granularity than Ethereum.

[3] What’s the most common misconception you hear about cross-chain security?

[4] $W staking is cool, but I would like to know the purpose of the staking program. Is it related to selling pressure?

References

[1] https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0001_generic_message_passing.md

[2] https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0013_ccq.md

[3] https://web3forall.xyz?id=wormhole

[4] https://github.com/wormhole-foundation/wormhole/blob/main/whitepapers/0010_integrity_checkers.md

[5] https://arena.wormhole.com/

[6] https://wormhole.com/products/native-token-transfers

Cheat Sheet

What is Wormhole?

Which Blockchains Does Wormhole Support?

More than 35 blockchains, but no Bitcoin Mainnet :(

https://wormhole.com/platform/blockchains

Wormhole Use Case

Many major projects and DApps rely on Wormhole for multichain interactions:

DeFi Platforms

Uniswap – Uses Wormhole to expand its DEX liquidity across chains.

Raydium – A Solana-based DEX that connects with Ethereum assets via Wormhole.

Saber – Uses Wormhole for multichain stablecoin swaps.

NFT Marketplaces & Gaming

Magic Eden – Allows multichain NFT trading.

Star Atlas – A blockchain game leveraging multichain NFTs and assets.

Stablecoins & Payments

USDC (Circle’s stablecoin) – Wormhole enables native USDC transfers between chains via CCTP (Cross-Chain Transfer Protocol).

Portal Bridge – A key Wormhole-powered bridge for moving assets securely across networks.

How Wormhole works?

Wormhole operates using four main components, each playing a vital role in verifying and relaying multichain messages.

These components are:

Core Contract – The Foundation
Guardians – The Security Layer
VAAs (Verified Action Approvals) – The Multichain Ticket
Relayers – The Messenger Service

Feature of the components

Core Contract – The Foundation

Think of the Core Contract as the heart of Wormhole on each blockchain.

Receives messages from dApps on its blockchain.
Generates a unique transaction hash that gets validated by Guardians.
Verifies incoming messages from other chains before executing them.

Why It Matters: Without the Core Contract, there’s no way to send or receive multichain data securely.

Guardians – The Security Layer

Guardians are a decentralized network of validators responsible for securing multichain messages.

Observe transactions happening on one chain.
Sign messages using a cryptographic system to confirm their validity.
Form a quorum (majority agreement) to prevent fraud.

VAAs (Verified Action Approvals) – The Multichain Ticket

Once Guardians approve a multichain transaction, they create a VAA (Verified Action Approval). This is like a cryptographically signed message that ensures:

The transaction was observed and approved by the majority of Guardians.
The message can’t be tampered with after approval.
The receiving blockchain can trust the message and execute it accordingly.

Why It Matters: VAAs eliminate the need for a central authority—instead, they let blockchains communicate securely through verified cryptographic messages.

Relayers – The Messenger Service

Relayers deliver VAAs to their destination blockchain so that transactions can be executed.

Pick up approved VAAs from the Guardians.
Deliver them to the Core Contract of the target blockchain.
Ensure multichain transactions are completed successfully.

Why It Matters: While VAAs prove that a transaction is valid, relayers actually deliver them across chains, making them the final piece of the puzzle.

How It All Comes Together?

Let’s summarize the entire multichain messaging process:

A dApp sends a message to the Core Contract on Chain A.
Guardians validate the transaction and create a VAA.
Relayers deliver the VAA to the Core Contract on Chain B.
The Core Contract executes the transaction on Chain B.

A user bridges an NFT from Ethereum to Solana:

Ethereum’s Core Contract registers the request.
Guardians approve the transfer and generate a VAA.
A relayer delivers the VAA to Solana.
Solana mints the NFT on its network, completing the transfer.

What is the Wormhole Token Bridge?

🔗 Example Use Case

Suppose a user wants to move USDC from Ethereum to Solana:

USDC is locked in a smart contract on Ethereum.
A VAA (Verified Action Approval) is generated and verified by Guardians.
Wrapped USDC is minted on Solana, representing the original asset.

📌 Why It Matters:

Removes reliance on centralized exchanges – No need to trust a third party.
Improves liquidity flow – DeFi users can access assets across multiple chains.
Enables multichain interactions – Assets can be used across different ecosystems.

How Does It Work?

Step 1: Locking Tokens on the Source Chain

Users deposit tokens (e.g., ETH, USDC, SOL) into the Token Bridge smart contract.
These tokens are held in escrow, ensuring they cannot be used on the source chain while their wrapped version exists elsewhere.

Step 2: VAA Generation & Guardian Validation

The Guardians (Wormhole validators) observe the transaction.
A VAA (Verified Action Approval) is created once a majority of Guardians sign off.

Step 3: Minting Tokens on the Destination Chain

The VAA is submitted to the Token Bridge contract on the destination chain.
Equivalent wrapped tokens are minted, representing the locked tokens.

Step 4: Redeeming Tokens (Optional)

Users can burn their wrapped tokens to unlock the original assets back on the source chain.
The burning process removes the wrapped tokens, ensuring that the supply remains 1:1 with the locked assets.

📌 Example Transaction:

Suppose a trader wants to move ETH from Ethereum to Solana for lower gas fees:

ETH is locked on Ethereum’s Token Bridge contract.
Wrapped ETH (WETH) is minted on Solana.
The trader uses WETH for DeFi trading on Solana-based DEXs like Raydium.
WETH can be redeemed back to ETH on Ethereum at any time.

💰 What is CCTP?

🔗 Example Use Case:

Suppose a DeFi trader wants to move USDC from Ethereum to Avalanche:

USDC is burned on Ethereum.
A VAA (Verified Action Approval) is generated and validated by Wormhole Guardians.
Circle, the issuer of USDC, mints an equal amount of native USDC on Avalanche.

📌 Why It Matters:

No Wrapped USDC – The transferred USDC remains native on the new chain.
More secure – Eliminates risks associated with token wrapping, reducing potential vulnerabilities.
Improves DeFi liquidity – Avoids fragmented versions of USDC, making transactions smoother and liquidity deeper.

🔄 How Does It Work?

Step 1: Burning USDC on the Source Chain

A user initiates a transfer by burning USDC in a Circle-controlled contract on the source chain.
This burn reduces the circulating supply on the original blockchain, ensuring accurate balances.

Step 2: VAA Generation & Guardian Validation

Wormhole Guardians observe and confirm the burn event, generating a VAA (Verified Action Approval).
The VAA provides proof of the burn event and prevents double-spending.

Step 3: Minting USDC on the Destination Chain

The VAA is submitted to Circle on the destination chain.
Circle mints an equivalent amount of native USDC from its reserves directly onto the destination chain.

📌 Why This Is Different from Token Bridges:

No locking, no wrapping – Traditional bridges lock the original token and mint a wrapped version.
USDC remains fully redeemable – CCTP ensures that only native USDC exists on all supported chains.

🔍 CCTP vs. Traditional Token Bridges

🔄 What is NTT?

🔗 Example Use Case:

A DeFi protocol wants its governance token to move seamlessly between Ethereum and Solana, maintaining identical contract logic on both chains.

📌 Why It Matters:

No Wrapped Tokens – Token remains native on every blockchain.
Reduced Bridging Risks – Eliminates dependency on wrapped assets, minimizing security vulnerabilities.
Simplifies Liquidity Management – Users don’t have to manage multiple versions of the same token.

🔬 How Does NTT Work?

Step 1: Token Locking & Minting

A token issuer establishes liquidity pools or vaults on each blockchain where the token will be available.
When a transfer occurs, tokens are burned on the source chain and minted natively on the destination chain, preserving a fixed total supply.

Step 2: VAA Generation & Validation

Guardians validate the token transfer request.
A VAA (Verified Action Approval) is generated to authorize minting on the destination chain.

Step 3: Native Minting on the Destination Chain

The token is minted natively on the destination blockchain instead of a wrapped version.
The token retains its original functionality and doesn’t require an intermediary contract.

📌 Key Difference from Token Bridge:

Traditional Token Bridge locks assets and mints wrapped tokens, which may not always be fungible across chains.
NTT ensures tokens remain consistent, native, and fungible across chains.

🔍 NTT vs. Traditional Token Bridges

If you're transferring a natively issued token, NTT is the best choice as it avoids wrapping and ensures liquidity remains unified.

Start building here: https://wormhole.com/products/native-token-transfers

🔍 What is the Wormhole Explorer?

📌 Why It’s Important:

Verify Multichain Transactions – Confirm whether your token or message successfully reached the destination chain.
Monitor VAAs (Verified Action Approvals) – Check if Wormhole Guardians have approved your transaction.
Debug Smart Contracts – Developers can troubleshoot failed transactions and optimize integrations.

🔗 Try it here: https://wormholescan.io/

🛠 How to Use the Wormhole Explorer

1️⃣ Tracking a Transaction

To track a multichain transfer, follow these steps:

Go to the Explorer → https://wormholescan.io
Enter your transaction ID or wallet address in the search bar.
View details like:
Source & destination chains (e.g., Ethereum → Solana)
Token amount & type
Transaction status (Pending, Confirmed, Failed)
Guardian Signatures

📌 Pro Tip: If a transaction is stuck, check whether the VAA has been generated and relayed.

2️⃣ Understanding the VAA (Verified Action Approval)

Each multichain transaction in Wormhole generates a VAA, which is cryptographic proof that the transfer is valid.Key VAA Details in the Explorer:

Emitter Address – The contract that initiated the transfer.
Sequence Number – A unique identifier for the transaction.
Signatures – Verification from Wormhole Guardians.
Status – Whether the VAA has been processed or pending on the target chain.

📌 Why This Matters:

Developers use VAAs to debug smart contract execution.
Users can confirm their assets have been safely transferred to the destination chain.

3️⃣ Debugging Failed Transactions

✅ Summary: Why Use the Wormhole Explorer?

By using the Explorer, both developers and users can efficiently manage multichain transactions and swiftly address issues.

What is Wormhole Connect?

Features of Wormhole Connect ✨

Simple Integration 🔌: As a React component, it can be integrated into Web applications with just a few lines of code.
Highly Customizable 🎨: Customize appearance and functionality, including supported chains, tokens, and theme styles.
Multiple Bridging Options 🌐: Supports various cross-chain transfer methods, offering flexible choices.
Seamless User Experience 👥: Users can complete all transactions through a single, unified interface, greatly simplifying cross-chain interactions.

Core Functions of Wormhole Connect 🛠️

Token Bridge 🔄

Locks assets on the source chain and mints Wormhole-wrapped "IOU" tokens on the destination chain. When assets are transferred back, wrapped tokens are burned and original tokens are unlocked.

Token Bridge Relayer (Automatic Routing) ⚡

Through relayers, users only need to execute one transaction on the source chain for tokens to automatically arrive at the destination chain.

Circle CCTP 💲

For USDC transfers, Circle enables native token transfers between CCTP-supported chains without needing wrapped tokens..

ETH Bridge 💎

Leverages Uniswap liquidity pools to transfer native ETH or wstETH between specific EVM chains.

Gas Drop Off ⛽

Relayers can automatically convert part of the transferred assets into gas tokens on the destination chain, resolving the issue of users lacking gas for transactions.

Multi-Chain Support 🔗

Start building here: https://wormhole.com/products/connect

Token Bridging Process 🔄

Taking the most common lock-and-mint model as an example, here's the basic token bridging flow:

Cross-Chain Steps from a User’s Perspective 👤

From a user's perspective, the cross-chain process typically includes:

Connect Wallet 👛
Select Source and Destination Chains 🌐
Choose Token and Amount 💰
Approve Token Spending ✓
Confirm Cross-Chain Transaction ✅
Pay Source Chain Gas Fee ⛽
Wait for Cross-Chain Confirmation ⏱️
Receive Assets on Destination Chain 📥

Discussion

Wormhole Key Innovation (3)

1. Multi-Modal Cross-Chain Solutions

Wormhole offers a suite of cross-chain products, not just a single bridge. These include:

Connect: A plug-and-play UI for easy token bridging.
Native Token Transfers (NTT): Enables true native token movement across chains, not just wrapped assets.
Token Bridge: Uses a lock-and-mint mechanism for wrapped assets.
Settlement: An intent-based protocol for fast, optimized, and non-custodial multichain transfers, moving beyond traditional bridging models. This modular approach allows projects to choose the best tool for their needs, from simple UI integration to advanced liquidity optimization and governance across chains. Wormhole Docs: Product Comparison

2. Decentralized Guardian Network

3. Generic Messaging Layer

Wormhole features

1. Wormhole Connect – Pre-Built Bridging UI

Best for: Projects looking for a plug-and-play UI for token transfers, without modifying smart contracts.

✅ Key Features

Minimal setup – No contract deployment required.
Easy integration – A simple front-end solution for users.
Supports native & wrapped assets – Flexible token support.

📌 Use Case Example:

A DeFi app wants to offer multichain bridging without requiring custom contract development.

2. Native Token Transfers (NTT) – Transfer Multichain Native Tokens

Best for: Projects that need to preserve native token functionality across multiple blockchains.

✅ Key Features

No wrapped assets – Tokens remain native on all chains.
Event-based actions – Can trigger smart contract execution on the receiving chain.
Requires contract integration – Developers must modify smart contracts for full functionality.

📌 Use Case Example:

A lending protocol wants users to move native tokens between chains without converting them to wrapped versions.

3. Token Bridge – Lock-and-Mint Asset Transfers

Best for: Projects needing multichain liquidity using wrapped assets and the ability to send messages along with transfers.

✅ Key Features

Supports wrapped assets – Locks tokens on one chain, mints them on another.
Enables multichain smart contract interactions – Can send instructions alongside token transfers.
Does not support native tokens – Requires token wrapping.

📌 Use Case Example:

A multichain DEX allows users to transfer tokens between blockchains while sending additional transaction data for liquidity routing.

Interesting Design Choices

Design Choice	Trade off & Benefit
Opaque Payload	Core no longer “knows” about tokens or NFTs. Anything from an oracle price to a DAO vote bitmap fits inside one envelope. Future apps don’t require protocol forks.
Sequence per (EmitterChain, EmitterAddress)	Guarantees total ordering for a single emitter without forcing a global counter that could become a bottleneck.
ConsistencyLevel flag	Lets latency-sensitive apps (e.g., cross-chain DEX quotes) publish instantly on optimistic rollups while letting treasury-size transfers demand finality on Ethereum one byte of optionality saves whole seconds or minutes.
Double-hash + guardian multisig	A 32-byte digest is trivial for any chain to verify, regardless of its native crypto. Length-extension attacks are impossible because the body is hashed twice before signing.
Decoupled delivery	Core never pushes a message; that responsibility moves to relayers or user wallets. This keeps the on-chain footprint tiny and means any transport (IBC, REST, email even QR codes) can carry a VAA.