On-Chain Components

Core Contracts

The Core Contract is the foundational on-chain component of the Wormhole protocol. It is deployed on every supported blockchain and is responsible for emitting and verifying messages that enable cross-chain communication. When a dApp or token bridge interacts with Wormhole, it typically sends messages through this contract. The Core Contract acts as the first point of contact for any action that needs to be transmitted to another chain.

When a message is emitted on the source chain, the Core Contract records the event, which includes the message payload, emitter address, sequence number, and consistency level. This data is then observed by the Guardian Network. Importantly, the Core Contract is chain-specific, meaning each chain in the Wormhole ecosystem has its own version of the contract deployed and independently monitored.

The Core Contract does not execute logic beyond message emission and verification. Its role is to reliably publish events to the transaction log, which can later be read and validated by off-chain components. The simplicity of its logic is intentional—it reduces attack surfaces and improves auditability across all integrated chains.

On the destination chain, the Core Contract is also responsible for receiving VAAs and verifying their signatures. A message cannot be executed on the destination chain unless the VAA meets the required signature threshold, which is typically 13 of 19 Guardian signatures. This ensures a consistent and verifiable security model across all chains.

Emitter

An Emitter is any smart contract that calls the publishMessage function on the Core Contract to generate a cross-chain message. These can be application-specific contracts or other protocol-level integrations that want to send data to a different blockchain. Emitters assign a unique sequence number to every message they create, helping Guardians track and validate each event accurately.

Each message emitted includes three primary components: the payload (what the application wants to send), the nonce (to prevent replay), and the sequence number (to preserve order). The payload is typically encoded data that represents instructions to be carried out on the destination chain, such as minting a token, updating a state, or executing an action.

Emitters don’t process messages—they just submit them. Their responsibility ends once the message is recorded in the transaction log. After this, the message relies on the Guardian Network to validate, sign, and relay it to the destination chain where it can be executed by another smart contract.

A key advantage of this model is modularity. Any contract can be an emitter as long as it integrates the proper interface and calls the publishMessage function correctly. This allows developers to create their own messaging flows using Wormhole without needing to understand or modify core protocol internals.

Transaction Logs

Transaction logs are how Wormhole enables secure communication without requiring full chain scans. When a message is published through the Core Contract, the contract emits a log event that gets recorded in the blockchain’s event log. These logs are accessible on-chain and serve as the source of truth for message observation.

Guardians watch these logs to determine when a valid message has been emitted. They parse the logs in real time and extract the relevant data (emitter address, payload, nonce, sequence number). Logs also include a block timestamp, which can be used to enforce time-based policies or order dependencies.

Logs are an efficient mechanism for message detection because they avoid the need to analyze the entire state of the chain. Instead, the Guardian Network can monitor specific event signatures, dramatically reducing computational overhead. This is especially important when scaling to multiple chains with high transaction throughput.

Because logs are immutable and cryptographically verified by the consensus of the underlying chain, they provide a trusted source for message validation. This allows Wormhole to maintain a consistent security model across different chains, even if those chains have different virtual machines or consensus models.

Off-Chain Components

Verifiable Action Approvals (VAAs)

Verifiable Action Approvals (VAAs) are the core mechanism that enables Wormhole to connect events between blockchains securely. After a message is emitted on the source chain and picked up by the Guardians, they collectively sign a VAA to attest that the message was observed and validated. A VAA is not just a signature—it includes the full payload, metadata such as timestamps and emitter details, and a multi-signature scheme proving consensus among Guardians.

A VAA is only considered valid when it includes signatures from a supermajority of the Guardian set. As of now, Wormhole requires 13 out of 19 Guardians to sign the VAA. This threshold balances security and performance, allowing rapid message relay while ensuring resistance against collusion or compromise. If the threshold is not met, the VAA will be rejected by the receiving chain.

The VAA contains the exact message originally emitted, without any transformation or alteration. This immutability is important because it allows the destination chain to verify the message against the original on-chain event. If the signatures and payload are correct, the message is processed; otherwise, it is ignored.

Applications using Wormhole don’t need to manage the VAA creation process themselves. It is handled entirely by the Guardian Network. However, developers integrating Wormhole must build logic on the destination chain to validate the VAA and execute corresponding actions. This may involve minting tokens, updating a state, or triggering another smart contract function.

Guardians

Guardians are the decentralized validators that underpin the security of Wormhole. There are currently 19 Guardian nodes, operated by independent infrastructure providers, including well-known organizations in the blockchain space. Each Guardian monitors all supported blockchains in the Wormhole ecosystem, watching for new messages emitted by Core Contracts.

Guardians observe each chain in real time and parse transaction logs to detect when a new message is published. When this happens, each Guardian independently validates the message’s authenticity, constructs the message payload, and signs it with their private key. These signatures are then combined into a VAA when the signature threshold is reached.

The role of Guardians is strictly observational and attestational—they do not execute any business logic or handle funds. This separation of responsibilities makes the system more secure and less prone to exploitation. Guardians do not run consensus across chains; instead, they act as an external validation layer that provides cryptographic guarantees about observed events.

Spy

The Spy is a lightweight observer process that listens to messages broadcast within the Guardian Network. It doesn’t participate in validation or signing, but it provides full visibility into the message flow, including VAAs, observations, and Guardian heartbeats. Developers and applications can run their own Spy instance to track Wormhole activity without needing to be part of the Guardian set.

The Spy connects to the peer-to-peer gossip network used by Guardians and receives messages as they’re transmitted across the system. This includes both signed VAAs and raw observations—unconfirmed messages that have not yet met the signature threshold. It gives developers near real-time access to Wormhole’s internal communication.

A common use case for Spy is real-time analytics dashboards or alerting systems that notify operators when messages are delayed or Guardians are underperforming. Since Spy can see messages from all Guardians, it serves as a transparent window into the network’s health and activity levels.

Running a Spy does not require special permissions or credentials. It’s an open-source daemon that anyone can deploy. This makes it particularly useful for dApp teams who want to monitor Wormhole messages related to their app without relying on third-party relayers or infrastructure.

Relayers

Relayers are off-chain agents that deliver VAAs to destination blockchains. While anyone can technically relay a VAA (since they’re public and self-verifiable), Wormhole supports structured relayers that provide automated delivery and monitoring. These relayers ensure that once a message is signed by Guardians, it reaches the target chain promptly and reliably.

Relayers are not part of consensus and do not require trust. Their only job is to submit the signed VAA to the Core Contract on the destination chain, which will accept or reject it based on signature validation. This means that even if a relayer is faulty or malicious, it cannot alter or fake a message—the VAA is the single source of truth.

There are two main types of relayers in Wormhole. Standard relayers handle generic VAAs and submit them as-is. These are used in basic token bridging, messaging, and protocol communication. Specialized relayers, on the other hand, are designed for more complex use cases like Wormhole Connect or Native Token Transfers, where they might bundle messages, optimize gas usage, or execute post-processing logic.

Relayers improve the user experience by eliminating the need for manual VAA submission. Without them, users would need to download the VAA from a Guardian endpoint and manually relay it using a wallet. By automating this, relayers allow dApps to offer a seamless cross-chain experience.

Highlights

• Core Contracts handle message emission and validation, forming the backbone of on-chain communication between blockchains.
• Emitters publish cross-chain messages through the Core Contract, which are recorded in transaction logs and observed by Guardians.
• VAAs are cryptographic messages signed by a supermajority of Guardians, used to verify and execute cross-chain operations on target chains.
• Guardians validate and sign messages, while the Spy allows anyone to observe message flow without participating in consensus.
• Relayers deliver VAAs to destination chains, automating execution and enabling seamless integration for developers and applications.