A previously accepted message must not unlock the same claim again.
LET’S PICTURE IT
A delivery receipt cannot be redeemed twice merely because a second copy arrives.
SEE IT FOR YOURSELF
Receive, check and share across independent nodesStep 1 / 4
A node receives a proposed transaction or block-related message. Receipt is not the same as accepting its claims.
A node receives a proposed transaction or block-related message. Receipt is not the same as accepting its claims.The node checks the relevant authorization and protocol rules. Popularity does not make an invalid state transition valid.Valid candidate data can propagate to peers. Connections and timing differ, so there is no perfect simultaneous worldwide view.Peers validate under the same protocol rules. This illustration is about verification and propagation, not a complete proof-of-stake consensus algorithm.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Identify the message uniquely
The replay identifier must be bound to the authenticated message and the correct source/destination scope. A caller-chosen free identifier is not sufficient.
Consume within the state transition
Record processing consistently with minting or unlocking. Reentry or failure handling must not permit the same entitlement to be used twice.
Handle retries deliberately
A failed delivery may need a safe retry path. Distinguish an unexecuted authenticated message from one already applied successfully.
Test duplication and reordering
Deliver the same local message twice and vary arrival order of different messages. Assert that supply and locked assets follow the protocol invariant.
Work through the boundary
authenticated message ID
→ check unused
→ apply action consistently
→ mark processed
Review the exact ordering and rollback behavior.
A simplified local review scenario. The example establishes a question to test, not a guarantee of production safety.
QUICK CHECK · NO PRESSURE
Should a successfully processed bridge claim usually be redeemable again?
Changing the submitting relayer does not create a new entitlement.