What is cross-chain messaging?
- Author
- CRYPTO PORT Editorial
- Published
- Updated
- Reading time
- 6 min
In short
Cross-chain messaging lets a contract on one chain learn about something that happened on another. It carries more than asset transfers — governance outcomes and remote function calls too. The core design question is who attests that the event really occurred, because if that breaks, the receiving side acts on forged data.
Key points
- Delivers events from one chain to contracts on another
- Carries arbitrary instructions, not only asset transfers
- Trust assumptions hinge on who attests to the event
- If the attesters are compromised, forged messages get accepted
Definition
A mechanism that delivers events or data from one chain in a form that contracts on another chain can receive and act upon. Asset transfers are one application of it.
Chains cannot read each other's internal state. So an event on the source chain has to be proved somehow, and a contract on the destination has to verify that proof before acting. 'Tokens were locked on chain A, so mint on chain B' is just one instance of this general pattern.
Attestation methods fall into two broad families. In one, a contract on the destination directly verifies the source chain's block headers or signatures, resting on the source chain's own consensus. In the other, an external validator set or oracle signs a statement that the event occurred.
The second approach makes it easier to support many chains, but if a majority of that set colludes or its keys are stolen, unbacked messages are accepted as genuine. Many of the largest bridge losses trace back to weaknesses in exactly this verification layer or its key management.
Watch out for
- · Designs that rely on an external signer set fail outright if a majority of it is compromised
- · A message is not done when it is sent — it can stall before execution on the receiving side
- · Supporting many chains says nothing about safety; check each design's verification method