When relayers report different fields for one event, the destination must follow its verification rule, not pick the most common report; on Ethereum, waiting for finality can mean roughly 13 minutes. The difference may be a malformed payload, a stale node, or two observations from opposite sides of a source-chain reorganization. If you are tracing a specific transfer, first determine whether the bridge verifies a source-chain proof, accepts a relayer quorum, or allows a challenge period.
A source proof decides which event data is valid
In a proof-verifying design, relayers transport the event and proof, while the destination contract or light client checks that proof against authenticated source-chain state. The event fields alone are not authority: a proof must establish that the expected commitment existed at the relevant path and height. A relay bridge illustrates the distinction: relayers carry cross-chain information, while the bridge’s verification rules decide whether the destination can act on it.
For an IBC packet, for example, the source router stores a commitment to the packet. A relayer submits the packet and proof; the destination client verifies the commitment before the receiving application runs. The IBC packet lifecycle specification describes this flow, including the reverse acknowledgement proof and a timeout path based on proving that no receipt exists.
If two relayers submit different payloads for the same commitment, only the payload that hashes to the committed value can pass verification. The other transaction reverts or fails validation, so it may cost the submitter gas but should not release funds. If neither version verifies, check that the proof height is supported, the destination’s client is current, and the packet fields match the source commitment.
A quorum decides when the bridge trusts signed reports
A quorum design accepts an event after enough authorized relayer nodes sign or attest to the same message. The contract typically checks the signer set, message digest, replay-protection nonce, and threshold; a configured 2-of-3 quorum is a simple example, not a universal bridge parameter. This approach can avoid an on-chain light-client proof, but its safety depends on the threshold and who controls those signers.
Suppose two of three relayers report a deposit, but the third reports a different amount. If the first two signed the same digest and the configured threshold is two, the bridge can accept that report; it does not independently prove that the source emitted it. If reports split one-to-one, the message stalls until another signer agrees, operators recover, or the bridge’s fallback process takes over.
For an app integrating a relay bridge, inspect the source transaction’s chain ID, block hash, transaction hash, log index, emitting contract, and decoded fields before treating disagreement as an application bug. If the bridge relies on a quorum, also check the required threshold and signer membership. A majority can agree on the same stale fork or incorrect decoding, so “two reports match” is weaker evidence than a valid commitment proof.
A challenge window delays action so watchers can dispute a report
An optimistic bridge accepts a relayer’s proposed event provisionally, then delays final execution while challengers can submit evidence of fraud. A successful challenge may cancel the message and penalize the proposer; an unchallenged message becomes executable after the protocol’s configured window. That window is a protocol parameter, not a standard duration, and the user’s wait includes source finality, the challenge period, and destination execution.
This option fits systems that want cheaper or faster message submission than verifying every source proof on-chain, and it can fail when watchers are offline, lack the data to challenge, or cannot submit in time. If your reports disagree during the window, compare the proposed event with the canonical source transaction and proof while the challenge path remains open; do not assume silence means the event is correct.
Reorganizations and stale clients explain many apparent conflicts
Two honest relayers can disagree because one saw a block that was later reorganized out, or because their RPC providers returned different heads. Ethereum’s proof-of-stake documentation describes finality through checkpoints backed by at least two-thirds of staked ETH; a proof tied to a non-finalized head can therefore be more vulnerable to a reorganization than one tied to a finalized checkpoint.
For a pending app action, compare the relayers’ block hashes and heights, then check whether the event’s block is canonical and finalized on the source explorer. If the block was orphaned, discard that observation and wait for the replacement event; if it is canonical but the destination rejects the proof, investigate client freshness, proof height, and exact field encoding. Do not manually resubmit a changed payload under the original nonce unless the bridge’s retry rules explicitly permit it.