An approval for a cross-chain payout needs to identify the complete transfer the approver reviewed. If the recipient or destination token can change while the approval still applies, the execution system has lost the connection between the reviewed action and the paid action.
Passage Bridge's current V2 message includes both chain IDs and bridge addresses, the asset type and token pair, the sender and recipient, plus amount, fee and nonce. Its contract hashes the complete structure with a protocol domain. The following review follows those concrete fields and the consumption checks in the local implementation.
Bind the destination as well as the source
The destination chain ID and bridge address tell the receiving contract where the message is intended to execute. The destination validation checks the current chain and configured pool. It also checks the source chain and the configured remote bridge, so the source address is interpreted within a particular route.
For non-native assets, the contract checks the configured token mapping. The asset type controls which validation branch applies. The recipient must be nonzero and must differ from the receiving pool, and the amount and nonce must be nonzero. These checks give the full message a meaning in the destination deployment.
A hash commits to supplied fields. It does not establish that an actual source-chain deposit happened. Passage uses independent message review and approval rather than an embedded source-chain light client. An approver's source-evidence checks remain part of the operated bridge's responsibilities.
| Message group | Fields bound into the message | Mutation to review |
|---|---|---|
| Route | Source and destination chain IDs | Replace destination chain |
| Deployment | Source and destination bridge addresses | Substitute a different pool |
| Asset | Asset type and both token addresses | Change destination token only |
| Parties | Sender and recipient | Change recipient after approval |
| Economics | Net amount and fee | Alter either raw integer |
| Source identity | Nonce with source chain and bridge | Reuse source identity in a new message |
Track a source message beyond one hash
The message manager maintains a full-message approval and a separate nonce identity. The nonce key is computed from source chain ID, source bridge and nonce. That second identity matters when someone changes a field and therefore produces a different full-message hash for the same source event.
Approval records associate a nonce key with a specific message hash. A conflicting hash for that key is rejected while the approval remains associated. At claim time, the contract checks both the consumed nonce identity and the claimed message hash, then requires the matching approval.
Once a payout succeeds, the nonce is consumed and the hash is marked claimed. Altering the destination asset after that point cannot create a new unused source nonce. This is a precise replay boundary to test. It is not a claim that every possible bridge attack has been covered.
The EIP-712 specification is useful background because it separates structured hashing and domain separation from replay protection. It explicitly leaves replay protection to the application. Passage's inspected message hash uses its own domain and ABI-encoded structure; this article does not characterize that function as an EIP-712 signature implementation.
Include approval changes in the review
An independent approver can revoke an unconsumed approval. The revocation removes the exact approved hash and its nonce association. It does not refund a source payment. A later approval requires the normal review again, and a consumed message remains consumed.
The destination claim also consumes payout budget before the transfer completes. The contract comments and call structure place the budget and message-state changes in the transaction that performs the payout, so a later reverting payment failure rolls them back with that transaction. This behavior needs deployment-specific evidence, including unchanged balances and consumption state after a forced failure.
Use the worksheet to modify one field at a time while retaining the original approval. Record the expected rejection and verify that no destination amount was paid. Then repeat the original successful message and try a modified message with its source nonce identity. These cases examine distinct protections and should have separate evidence rows.
Preserve the reviewed message in operations
An approval export should carry the exact message and deployment context. Operators need to compare the exported fields with source evidence and the destination's configured route. A friendly token symbol or shortened address can assist reading, but the review record should retain the complete addresses and raw amounts that execution will consume.
The download contains original field and rejection matrices. All exercises are marked Not run. Source inspection and historical local materials informed them; no new contract tests or independent security assessment were performed for this article.
Download the message binding and rejection matrix.
Passage Bridge is a local Anvil demonstration of an operated liquidity bridge. Production automatic broadcast remains disabled. Approval roles, production keys and external security review must be scoped before deployment.
