relayer

A relayer is the off-chain worker that physically carries messages, proofs, and data from one chain to another. Chains cannot reach out and read each other; someone has to watch chain A, pick up an outgoing message or proof, and submit it as a transaction on chain B. The relayer is that courier. It is a permanent fixture of nearly every bridge and cross-chain messaging system, because the cross-chain 'pipe' is, at bottom, a process polling one chain and posting to another.

The crucial question is how much a relayer is trusted. In a well-designed trust-minimized system — IBC, a light-client bridge, a zk bridge — the relayer is completely untrusted: it delivers a message plus a cryptographic proof, and the destination contract verifies that proof against the source chain's own consensus. A malicious relayer there can delay or refuse to deliver (a liveness/censorship nuisance) but can never forge or alter a message, because the destination re-checks the math. Multiple competing relayers make even censorship hard, since any one of them can deliver.

In weaker designs the relayer is part of the trusted set and its honesty is a security assumption — if it can submit messages that the destination accepts without independent verification, a compromised relayer is a compromised bridge. So when evaluating any interoperability protocol, the sharpest question is: if the relayer is malicious, what is the worst it can do — merely stall messages, or actually steal funds? Trust-minimized protocols force the answer to be 'only stall'; many production bridges, unfortunately, do not.