Welcome. This module shifts from a single-chain Solana program to the reality that many applications must react to state established elsewhere. A cross-chain transfer is not one atomic transaction spanning two networks: it is a sequence of independently confirmed actions connected by a cryptographically verified message.
In this lesson, Wormhole provides a concrete interoperability example. You will trace both the general message path and an Ethereum-to-Solana token transfer using Native Token Transfers (NTT): source-chain state change, Guardian attestation, off-chain delivery, and destination-chain execution. The security design of the receiving Solana program will be the focus of the next lesson.
A cross-chain transfer has three trust boundaries
It is useful to separate what happened from how another chain learns it happened.
-
Source-chain transaction. A user submits an Ethereum transaction to an application contract. The contract changes Ethereum state: for example, it burns tokens or locks them in custody. It also emits a message for the interoperability protocol.
-
Verification and attestation. An independent verification network observes the source-chain event only after the required finality condition. It signs an attestation representing that event.
-
Destination-chain execution. Someone submits the attestation to Solana. Solana-side programs verify it and, if the application-level rules are satisfied, perform the destination action: mint tokens, release tokens, or update program state.
The crucial implication is that a successful Ethereum transaction does not directly invoke a Solana program. There is no shared runtime, shared transaction, or automatic rollback across the two chains. Each step has its own transaction status and potential delay.
Wormhole calls its signed attestation a VAA. A VAA establishes a specific claim of the form: a particular emitter contract, on a particular chain, published this particular message. It does not by itself mean that every Solana program should act on the message. The receiving application still decides whether that emitter, payload, and intended destination are acceptable.
Before continuing, establish the protocol-level vocabulary and the data produced on the source chain.
Core Contracts | Wormhole Docs
Read Wormhole’s concise account of how a source-chain event becomes a verified message usable on another chain. It distinguishes publication, Guardian attestation, and destination verification—the three layers used throughout this lesson.
In “How the Core Contract Works,” read the three-stage model. Then, in “Message Submission,” read the source metadata and finality discussion; focus on why emitterAddress, sequenceNumber, and consistencyLevel identify and protect a message. Finally, in “Message Reception,” read VAA reception. Note the distinction between Guardian operations off-chain and signature verification by a destination-chain contract.
Source message identity and finality
The source Core Contract publishes information that lets the verification network and destination identify the message unambiguously:
| Field | What it identifies | Why it matters |
|---|---|---|
| Source chain | Which network made the claim | An address alone is not globally unique. |
| Emitter address | The source contract that published the message | The destination must trust a specific emitter, not merely any contract. |
| Sequence number | A monotonically increasing value for that emitter | It distinguishes one message from the next and supports replay tracking. |
| Payload | Application-defined bytes | This can encode a recipient, amount, token details, command, or state update. |
| Consistency level | Required source-chain finality before observation | It reduces the chance that an attested event is later removed by a source-chain reorganization. |
The Guardian Network independently observes the source-chain publication. The Wormhole documentation describes a supermajority of 13 out of 19 Guardians producing a VAA. A production application should rely on the deployed protocol configuration rather than hard-coding assumptions in its own logic, but the architectural idea is stable: a destination contract verifies a threshold of signatures rather than trusting the relayer who carried the bytes.
A relayer is therefore best understood as a delivery mechanism, not as the ultimate trust anchor. A relayer can be unavailable, slow, or submit a VAA more than once; it cannot make an invalid VAA pass on-chain verification.
Trace: 100 ALICE from Ethereum to Solana
Consider an illustrative NTT deployment with an ALICE token on Ethereum and a corresponding Solana configuration. Alice wants to move 100 ALICE from Ethereum to her Solana token account. We will use burning mode, the cleanest accounting example:
- On Ethereum, 100 ALICE are burned.
- Once the message is accepted on Solana, the destination NTT system mints the corresponding amount to Alice’s Solana recipient account.
The global economic idea is conservation: the amount that becomes usable on Solana is backed by the amount removed from circulation on Ethereum. In a locking design, tokens are held in a manager on one side and may be released when returning to their native chain. The exact mint or unlock behavior depends on the configured mode and where the token is native.
1. Alice initiates the Ethereum transaction
Alice’s wallet submits a transaction to the Ethereum-side NTT Manager. In a real UI, the wallet may first need to authorize the manager to move ALICE, depending on the token and transfer method. The transfer call supplies at least:
- amount: 100 ALICE;
- destination chain: Solana;
- destination recipient: Alice’s Solana address in the required cross-chain representation;
- a choice about whether the transfer may be queued if it exceeds a rate limit.
The NTT Manager first applies its business rules. In burning mode it burns the source tokens, and it checks its outbound rate limit. A rate limit is not a verification failure; it is a protocol-level safety and liquidity-control policy. If capacity is available, processing can continue. If queueing is enabled but capacity is insufficient, the transfer becomes an outbound queued item until its release time. If queueing is disabled, the source transaction fails rather than partially proceeding.
Once release is permitted, the NTT Manager creates a transfer message and gives it to each configured transceiver. A transceiver is a transport and verification adapter. Wormhole’s transceiver publishes through Wormhole; an NTT design may support more than one transceiver and require an application-configured threshold among them.
2. The Wormhole message becomes a VAA
The Wormhole transceiver publishes the outbound message through the source-chain Wormhole infrastructure. Guardians wait for the requested Ethereum finality, observe the publication, and sign it. Their combined signatures and the message metadata form the VAA.
At this point, the VAA is portable evidence. It can be delivered to Solana manually by a user or dApp, or automatically by a relayer service. Importantly, the VAA is normally multicast: it attests to what a source contract said, rather than being inherently restricted to a single destination. The NTT payload and destination-side program rules supply the application-specific meaning of “this transfer is intended for Solana.”
The following diagram is for a manual Wrapped Token Transfer (WTT) rather than NTT, so do not treat its WTT contracts as NTT implementation details. It clearly illustrates the general handoff: a source on-chain message, Guardian-produced VAA, an off-chain party fetching it, and a destination-chain submission for verification.
3. A Solana transaction verifies and records the message
On Solana, the relayer, user, or dApp submits a transaction calling the Wormhole NTT transceiver’s receive_message instruction. This is destination execution step one, not merely a database update in an off-chain service.
The instruction verifies the Wormhole VAA and stores the accepted message in a Solana account named VerifiedTransceiverMessage. This account is significant from a Solana-programming perspective: verified cross-chain evidence becomes explicit on-chain state, available as an account that later instructions can inspect.
The NTT Manager then receives an attestation from the transceiver. If the NTT deployment is configured with several transceivers, it waits until its own configured threshold is met.
Do not conflate these two thresholds:
| Threshold | What it answers |
|---|---|
| Guardian signature threshold | “Did Wormhole’s verification network attest to this source message?” |
| NTT transceiver threshold | “Has this NTT Manager received sufficient attestations from its configured transport backends to execute the transfer?” |
A single-transceiver NTT system may have an NTT threshold of one while still relying on Wormhole’s Guardian threshold underneath. A multi-transceiver NTT configuration can require independent delivery attestations from more than one backend.
4. Solana redeems and completes the token transfer
After receiving enough transceiver attestations, the Solana NTT Manager processes the message through redeem. It applies its inbound rate limit. If the transfer fits within inbound capacity, it may proceed. Otherwise, it is placed in an Inbox to wait until the configured release time.
For our 100-ALICE example, assume the inbound limit allows immediate completion. In burning mode, an authorized NTT instruction named release_inbound_mint mints the destination amount to Alice’s Solana token account. The transfer is now complete from the user’s perspective: Ethereum’s 100 ALICE were burned and the corresponding Solana balance has been minted.
The NTT documentation gives the end-to-end flow and then maps it to the relevant EVM and Solana operations.
Flow of a NTT Transfer | Wormhole Docs
Read this as the implementation-oriented counterpart to the generic Core Contract flow. It shows where NTT adds token accounting, rate limits, transceivers, and Solana-specific instructions.
Start with the “Transfer Flow” section and read the eight-step overview. Keep a distinction between source token movement, cross-chain attestation, and destination token movement. Next, in “EVM Transfer Flow Details,” read the subsections “Transfer,” “Rate Limiting,” “Sending the Message,” “Receiving the Message,” and “Minting or Unlocking.” Follow the EVM detail sequence, paying particular attention to queues, relayer delivery, and the two replay-protection behaviors. Finally, in “Solana Transfer Flow Details,” go directly to “Receiving the Message” and read the verified-message step. Continue with “Mint or Unlock,” including the final release rules. Notice that Solana completion can involve distinct instructions for verification, redemption, and release.
The same trace as a developer’s operational record
When debugging or designing the front end for this transfer, do not search for one universal “transaction hash.” You need a chain of evidence across two networks and an off-chain attestation layer.
| Stage | Useful evidence | What a successful result means |
|---|---|---|
| Ethereum initiation | Ethereum transaction hash; NTT events such as TransferSent and transceiver send events | Source token action occurred and the outbound transfer was accepted or queued. |
| Finality and attestation | VAA identified by source chain, emitter address, and sequence number | Guardians attested to a final source message. |
| Solana reception | Solana transaction signature and ReceiveMessage program log | The Wormhole transceiver verified the VAA and recorded its message. |
| Solana redemption | Redeem log and Inbox state if rate-limited | The NTT Manager accepted the attested transfer for inbound processing. |
| Completion | ReleaseInboundMint or ReleaseInboundUnlock log; recipient token-account balance | Destination token accounting was performed. |
A robust dApp should model these as distinct user-visible states. “Source transaction confirmed” is not yet “tokens available on Solana.” A practical status sequence might distinguish:
- source transaction awaiting confirmation;
- source transfer queued by an outbound limit;
- waiting for source finality and VAA;
- VAA available, awaiting Solana submission;
- Solana message verified;
- inbound transfer queued by a destination rate limit;
- destination mint or unlock complete.
This is also why retry behavior must be deliberate. Delivery may be retried when a relayer fails, but a correctly designed destination protocol must not mint twice. The NTT flow documents two related protections: a transceiver cannot attest to the same message twice, and an already executed message ends early rather than being executed again. The latter behavior is particularly important when several transceivers race to deliver a message after the configured threshold has already been reached.
Message transfer versus token transfer
The token transfer above is a specialized message transfer. Its payload represents an instruction such as “credit this recipient with this normalized token amount,” and the NTT Manager enforces token-specific accounting.
A general EVM-to-Solana message follows the same skeleton but replaces token settlement with an application instruction:
- An Ethereum contract updates its own state and publishes a payload, perhaps authorizing a Solana game item, recording a governance outcome, or requesting a state update.
- Guardians attest to the publication after the requested finality.
- A relayer or user submits the VAA to Solana.
- A Solana program verifies the attestation and interprets the payload.
- The program writes the resulting Solana state once, provided the message is from an expected source and has not previously been consumed.
For example, an Ethereum game contract could publish a message declaring that a player has redeemed an achievement. The Solana program should not treat “valid Guardian signatures” as sufficient authorization to grant arbitrary achievements. It must recognize the expected Ethereum chain and emitter, parse a supported payload format, ensure the message is intended for this Solana application, and record that the unique message has been consumed. The next lesson develops these checks systematically.
Key takeaways
A cross-chain operation is a verified, multi-stage workflow, not a direct remote procedure call:
- The source transaction performs the original state transition and emits a uniquely identifiable message.
- Guardians wait for the selected finality condition and produce a VAA attesting to that source event.
- A relayer or dApp transports the VAA, but destination-chain signature verification supplies the trust boundary.
- On Solana, NTT can verify the VAA, store a verified-message account, satisfy a transceiver threshold, apply inbound rate limits, and finally mint or unlock tokens.
- Guardian quorum, NTT transceiver threshold, rate limiting, and replay protection solve different problems and should be reasoned about separately.
Next, you will turn this trace into a receiving-program security design: validating the source domain and sender, constraining payloads and finality, and preventing replay on Solana.
Can't find a good explanation? Sign up and we'll make it for you
Sign up