Wormhole Wormhole Guardians and the 13-of-19 Signing Quorum
ยท last updatedWormhole Guardians authenticate messages that applications publish through Wormhole Core Contracts. The canonical network uses 19 Guardians and requires at least 13 signatures over the same message body for a VAA, its signed message packet. Destination contracts verify those signatures before accepting the attestation. Depending on the chain, direct observation involves the full set or a delegated subset.
The signing threshold describes the final attestation, while observation rules describe how the network learns about the source event. A 13-signature VAA can include signatures from Guardians that relied on delegated observations.
Wormhole Guardians can stop producing attestations for a delegated chain when too few designated observers agree, even if other Guardians remain online.
Core Contracts, Guardians, and delivery
The source Core Contract exposes published messages to the observation network, while the destination Core Contract verifies the resulting attestation. These contracts give Guardians a defined publication event to monitor and applications a way to verify attestations. The emitting application chooses the payload, while publication ties that data to its emitter and source chain.
Watchers connect on-chain publication to off-chain signing by monitoring the relevant chain and applying its confirmation policy before a Guardian signs.
Guardians exchange observations and signatures through their peer-to-peer gossip network, combining signatures that authenticate the same body. The completed packet, called a Verifiable Action Approval (VAA), carries evidence that destination verification can examine. Its authenticity concerns the message that the emitter published; application-specific rules determine whether that emitter has authority to request a particular action. Wormhole Queries also uses Guardian attestations to supply on-chain data on demand through a separate query-response flow.
The Executor framework provides message delivery separately from Guardian signing by transporting the packet to a receiving contract. A delivery provider cannot change the signed body while preserving valid signatures. A completed signing quorum does not itself run the receiving application or pay its transaction costs.
How does the 13-of-19 quorum work?
The quorum requires at least 13 valid Guardian signatures over an identical message body in the canonical 19-member configuration. A verifier matches signers against the Guardian set that the VAA identifies. The verifier counts each signer once, matching its signature to the key at its index. Governance controls membership, so this configuration can change.
The EVM Core Contract calculates quorum as floor(2N/3) + 1, with N representing the Guardian-set size and floor rounding down.
| Parameter | Value | Meaning | Limit or condition |
|---|---|---|---|
| Canonical set size | 19 Guardians | Canonical signing membership | Governance can update membership. |
| Signing quorum | 13 of 19 signatures | Minimum for this set size | Signatures must authenticate the same body. |
| Guardian signature | 65 bytes | ECDSA signature in the VAA | The Guardian index occupies an additional byte. |
| VAA version | 1 | Version accepted by the EVM Core parser | Other version values fail that parser. |
Six unavailable members still leave enough members for a quorum, provided the remaining Guardians sign the same body. Seven members withholding signatures can prevent new attestations or governance actions. These availability counts apply to the 19-member configuration, while delegated-chain observation adds another requirement before signing.
The signed body and verification boundary
Each VAA separates its message body from a header that identifies the Guardian set and lists signatures with their indices. The body records the timestamp, nonce, emitter chain, emitter address, sequence, consistency level, and payload. Guardians use the Elliptic Curve Digital Signature Algorithm (ECDSA) on secp256k1 to sign the body's double-keccak256 digest. Changing a body field invalidates the existing signatures. The base VAA has no destination field, although applications can encode destination rules in the payload. Signature verification authenticates the signed body; the receiving application interprets its payload.
Direct observers and delegated observers
Direct observation gives each Guardian its own view of the source chain through a watcher and full-node infrastructure. On a chain without delegation, Guardians independently inspect the on-chain event before contributing their attestation. Chain-specific confirmation rules still determine when an event qualifies for signing.
Delegated observation assigns that monitoring work to a configured subset of the existing Guardians. Delegates broadcast signed observations through the gossip network. Other members validate the reporting Guardians against the chain's delegate configuration. Canonical Guardians wait for the required delegate quorum before signing messages from a delegated chain.
The final VAA still uses keys from the full Guardian set, with the same format and signing threshold. Destination Core Contracts do not receive a different VAA type for delegated chains. A Guardian can serve as a delegate on one chain and rely on delegates on another.
Delegation reduces the direct chain infrastructure that every member needs to maintain. It also concentrates source-event observation in the assigned subset. Thirteen signatures therefore do not establish thirteen independent full-node observations on every chain. If the configured subset cannot reach its observation quorum, other members cannot complete attestation for that chain.
What can delay Guardian attestation?
Guardian attestation can wait on source-chain confirmation, a missing quorum, or applicable token-transfer safeguards. A watcher interprets the emitter's consistency level using the source chain's finality rules. Supported faster settings allow earlier signing with greater reorganization risk. After a reorganization, different observations can produce different bodies for what appears to be the same message. The consistency level records the requested policy; it does not impose identical timing across chains.
The Governor can delay covered token-transfer messages under configured transfer-value and flow limits. Its coverage depends on the chain, emitter, message type, and tracked asset. The Global Accountant checks token-transfer messages from registered token-bridge and Native Token Transfer deployments against cross-chain balances. Guardians require accounting approval before signing when enforcement is enabled for the emitter. These checks add asset-specific conditions beyond message authenticity. Delegated and other members continue to apply the relevant safeguards within their roles, so observation quorum alone does not override these checks.
Guardian governance and contract assumptions
Guardian governance authorizes changes to the trusted signer set and supported contract implementations. Guardians sign governance messages as votes on specific actions, which Core Contracts validate before updating state. This authority also controls per-chain delegated-observer configuration. Operator membership and upgrade authority therefore form part of the trust model.
The EVM Core verifier checks the VAA body digest, the identified Guardian set, set validity, quorum, and signatures. A receiving contract must also enforce application-specific sender and replay rules. Authentic Guardian signatures do not establish that a receiving contract handles its payload safely.
Source-chain integrity remains a dependency of observation. Faulty source-chain execution or incorrect node responses can give observers an inaccurate view of events. Independent signatures do not repair incorrect source-chain information. Enforced asset accounting adds protection within registered deployments. Its cross-chain checks cannot stop every consequence of a local exploit, including actions that never traverse the bridge.
Frequently asked questions about Wormhole Guardians
Does parseVM authenticate a VAA in an EVM integration?
The EVM Core Contract's parseVM function does not authenticate a VAA. It decodes the packet and computes the body digest. Full verification must also check Guardian signatures, quorum, and whether the identified set remains acceptable. Successful parsing leaves the message's authenticity unresolved.
Can verifySignatures alone establish the full VAA quorum?
The EVM verifySignatures helper does not enforce the required quorum. It checks supplied signatures against supplied Guardian keys, while full verification also checks set validity and quorum. The helper can return success for an empty signature array, so treating its return value as complete authentication would bypass necessary acceptance rules.
Must a VAA use signatures from the first 13 Guardians?
A VAA can meet quorum with a valid subset of the Guardian set, without selecting its first 13 entries. In the EVM Core implementation, signature indices must increase strictly, and each signature must match the key at its index. Duplicate, unordered, or out-of-range indices cannot supply additional valid votes.
How can a backend listen to Guardian gossip without becoming a signer?
A backend can run a Spy to subscribe to messages from the Guardian gossip network. Its role is monitoring and message distribution. It contributes no Guardian signature or consensus vote. Receiving a packet through that stream does not replace the cryptographic verification that the consuming application needs.
Why can the same message have different VAA signature lists?
Different collections of Guardian signatures can authenticate the same VAA body. The signature list belongs to the header, which does not form part of the signed body digest. Packets with different valid signature collections can therefore share a body hash. Each packet still needs to satisfy Guardian-set and quorum checks.
Can Guardians attest to data without a Core Contract message?
Wormhole Queries lets Guardians attest to requested on-chain data without requiring the application to publish a Core Contract message. The service uses a separate query-response flow. A consuming application must check that the response matches its intended request and meets its freshness requirements, alongside verification of the Guardian signatures.