A transfer can complete on its source chain yet remain unredeemable on the destination if Guardians do not reach quorum on the same message body. The deciding condition is whether at least 13 of the current 19 Guardians sign an identical body; signatures for competing versions do not combine.
What does disagreement mean for a transfer?
Guardians do not cast a general vote on whether a transfer seems legitimate. Each independently observes a source-chain event, checks it against the protocol’s rules and chosen consistency level, then may sign the resulting message body. A Verifiable Action Approval (VAA) identifies that body by its emitter chain, emitter address and sequence, among other fields.
For a typical case, suppose you burn a wrapped token on Ethereum and expect its release on Base. The source transaction can succeed and the burn can be final while the destination release waits: the target contract needs a valid VAA, and the transfer app still needs to submit it for redemption. Source-chain success alone does not prove that a message reached quorum.
“Disagreement” can mean Guardians have not observed the same event, have derived different bodies, or have not signed enough copies of one body. The most consequential edge case is a source-chain reorganization: observers on different forks can see different versions of the event. Wormhole’s VAA documentation describes how a lower consistency level can allow competing VAAs for what appears to be the same message; waiting for finality reduces that risk, but cannot make extended reorganizations impossible.
How does the quorum resolve competing observations?
Guardians sign a double-keccak hash of the serialized VAA body, not a loose description of the transfer. A signature over one body cannot be reused for another: a changed payload, sequence, emitter, or other signed field produces a different digest. The target Core Contract checks signatures against the Guardian set identified in the VAA header and accepts a quorum for that body.
With the current 19-member set, 13 signatures are required. If 12 Guardians sign one version and seven sign another, neither reaches quorum; if 13 agree on one version, the remaining six cannot block its certification. A seven-member superminority can, however, prevent a quorum by withholding signatures. Two conflicting 13-signature quorums would overlap in at least seven Guardians, so producing both requires that many to sign conflicting versions.
Some chains use delegated Guardians to gather observations. That changes who directly watches a chain and how observations reach the rest of the set; it does not lower the final 13-of-19 VAA threshold. Wormhole’s Security documentation describes the final signature threshold and the role of delegated observation. A delay caused by too few agreeing observations is therefore an availability failure, while a valid VAA still represents the required quorum’s attestation.
What should you check before retrying?
First, confirm the source transaction emitted the expected bridge message, then identify it by its emitter chain, emitter address and sequence. Check whether the message is still waiting for signatures, whether a VAA has appeared for that exact identifier, and whether its body matches the source event. For a transfer started through wormhole bridge support, those checks distinguish a missing VAA from a destination redemption that has not yet been submitted.
If the source chain is still within the selected consistency window, wait for the chain’s required commitment rather than treating the first observed VAA as definitive. If a reorganization replaced the block, the original event may no longer be canonical; a valid message must correspond to the surviving event and its final sequence. Do not submit a VAA for a different emitter or payload just because its sequence looks similar.
If a matching VAA already has quorum, the Guardians’ disagreement is no longer the likely blocker. Check that the destination transaction uses the right destination contract and VAA, and inspect its revert reason: a stale Guardian set, malformed payload, already-consumed message, or application-level restriction can prevent redemption after signature verification. On EVM chains, a read-only verification call to the Core Contract can help distinguish invalid signatures from a downstream app failure.
When should you choose a different path?
If time matters more than minimizing reorganization exposure, choose a route or app whose source-chain finality policy fits that requirement before initiating the transfer. A faster consistency setting can shorten attestation time on chains that support a choice, but it accepts more reorg risk; on chains with a fixed finality model, the user cannot tune it.
For a pending transfer, the practical choice is usually to wait for the canonical message and redeem that VAA, rather than initiate a second transfer and risk moving the asset twice. If no matching VAA appears after the source event is final, use the app’s recovery path with the exact transaction and message identifier. The answer changes if the source transaction was reverted, the event was replaced by a reorganization, or the app’s own transfer rules reject the payload: in those cases, waiting for Guardian signatures will not complete the intended redemption.
Top comments (0)