Wormhole Transfers Can Survive a Guardian Set Change

When a Wormhole token transfer is waiting for redemption, a Guardian set change does not automatically cancel it: the transfer can still settle if its VAA passes verification on the destination chain. Wormhole’s token-bridge white paper says each set is guaranteed to remain valid for at least 24 hours after replacement.

The practical dividing line is whether the destination Core contract can verify the VAA against an unexpired set or a current quorum.

A transfer emits a message on the source chain; Guardians attest to its body, and the resulting VAA carries a guardian-set index and indexed signatures. The body identifies the emitter, sequence and payload, while the header records which set signed it. For a fuller account of how Wormhole bridge transfers move through the protocol, see the separate transfer guide; here, the key issue is what the destination contract accepts when redemption is attempted.

What changes when the Guardian set rotates?

The destination contract checks the VAA against the set identified in its header. Wormhole’s EVM Core Contract reference and implementation describe checks for a known set, an unexpired set unless it is current, a quorum of signatures, and valid signatures from that set’s keys. The body’s hash is checked as well. A rotation therefore changes which keys and set index may validate a VAA; it does not rewrite the source-chain message.

During the outgoing set’s validity period, a VAA signed by that set can still be accepted under the contract’s expiration rule. After the old set expires, a VAA carrying only that set’s index and signatures will fail verification. The white paper advises completing a transfer within 24 hours, but that is a timing recommendation tied to the guaranteed validity window, not a claim that the underlying transfer disappears at the deadline.

Can an expired VAA be repaired?

Often, if enough current Guardians signed the same message. Wormhole’s white paper describes changing the VAA’s set index to the current set and removing signatures from Guardians absent from it, provided the remaining signatures meet the current quorum. This preserves the original message body; it does not authorize a different transfer.

If the overlap is insufficient, additional current-set observations may be needed. The white paper describes obtaining signatures from other sources or requesting Guardians to re-observe the source message, with re-observation dependent on enough Guardians retaining the relevant transaction in archive nodes. Wormhole’s current signature-replacement tutorial also describes fetching observations and replacing outdated signatures, then seeking Guardian approval before redemption. Repair is therefore conditional on available observations and quorum, not a guaranteed recovery route.

What should a user check before retrying?

First distinguish a verification failure from a source-chain failure. Confirm that the source transaction emitted the expected message and note its emitter, sequence and VAA set index. Then check the destination chain’s active set and whether the VAA’s original set has expired. The useful checks are:

• Confirm the VAA body matches the intended source transaction and token transfer.
• Check whether its guardian-set index remains valid on the destination chain.
• If expired, determine whether current-set observations can supply quorum.
• After repair, submit the VAA and confirm the destination contract completed redemption.

The answer is conditional: a Guardian rotation can interrupt redemption without erasing the source message or making the assets irrecoverable. Prompt redemption avoids the expiry issue; after expiry, settlement depends on whether a valid current-set quorum can be assembled and accepted by the destination contract.