Light clients versus federated attestation
The most rigorous approach to cross-chain verification is running an actual light client of the source chain on the destination chain. A light client doesn't replay every transaction, but it does verify block headers and consensus signatures according to the source chain's real rules, meaning the destination chain can cryptographically confirm an event happened without trusting any single reporting party. This is powerful because it pushes the verification logic on-chain and inherits the source chain's own security guarantees, but it's also expensive: encoding another chain's consensus rules into a smart contract and verifying signatures or validator sets on every message is computationally costly, and it has to be maintained as the source chain's own validator set or consensus rules evolve.
The far more common approach in practice is federated or multisig attestation. A fixed set of validators, sometimes run by the bridge project itself, sometimes a broader external network, watches the source chain, and once a supermajority of them sign off that an event occurred, the destination chain accepts that signed attestation as sufficient proof and acts on it. This is cheap, fast, and works for any chain pair without custom light-client engineering. The tradeoff is that it reintroduces exactly the kind of trust blockchains are designed to avoid: users are no longer trusting the source chain's own consensus, they are trusting that this particular set of signers is honest, uncompromised, and not colluding, which is a materially weaker guarantee.