auditing-cross-chain-bridge-and-message-trustlisted

# Auditing cross-chain bridge and message trust: the destination must prove the source event, not assume it A cross-chain bridge does one hard thing: it makes an action on the destination chain, minting a wrapped token, releasing locked funds, running a message, conditional on an event that happened on the source chain. The destination cannot see the source directly, so it trusts a proof or an attestation that the event occurred, and every bridge hack is a failure of that trust. If the destination accepts a mint or release on a forged proof, an unverified claim, or an attestation from a signer set an attacker can spoof or that is too small to be safe, the attacker manufactures value from nothing. If a valid message can be replayed, on the destination twice, or on another chain, one legitimate event authorizes many withdrawals. And the lock-and-mint or burn-and-release accounting that is supposed to keep supply balanced can be pushed out of balance by a message that mints without a matching lock or releases without a matching burn. The audit follows a message from source event to destination action and checks that the destination genuinely verifies the event, binds the message so it executes once, and keeps the accounting balanced. You audit this by crafting messages the destination should reject and seeing whether it mints or releases. ## When to use - A bridge or messaging layer authorizes a destination-chain action (mint, release, call) on the strength of a claimed sou