Beyond moving assets, protocols exist to send arbitrary messages between chains, and the same fundamental question applies to all of them.
The core problem
A contract on one chain cannot observe another chain.
Which means something must attest that an event occurred elsewhere.
Everything else is a variation on who attests and what happens if they lie.
External verification
A set of validators observes the source chain and signs attestations.
Which is simple and places trust in that set.
Security equals the cost of compromising a threshold of those signers, which is frequently far less than the value secured.
Native verification
The destination chain verifies the source chain's consensus proofs directly.
Which inherits the source chain's security rather than adding a new assumption.
It is computationally expensive and must be implemented per chain pair, which limits deployment.
Optimistic verification
Messages are accepted after a delay unless challenged.
Which requires watchers with incentive to challenge.
The delay is the security parameter, and shorter delays mean less time to detect fraud.
Configurable security
Some protocols let applications choose their verification configuration.
Which allows matching security to value at risk.
It also means two applications on the same protocol can have very different actual security, which is invisible to users.
Failure handling
What happens when a message is delivered but execution fails on the destination.
Which requires retry logic or manual recovery, and designs differ.
Messages stuck in an unrecoverable state have caused real user losses.
Ordering guarantees
Whether messages arrive in the order sent.
Which matters for applications where sequence affects outcomes.
Not all protocols guarantee it, and applications must handle out-of-order delivery where they do not.
Assessing one
Who attests, how many, what it costs to compromise them, what happens on failure, and whether the application has configured anything unusual.
These questions apply to every design regardless of how it is marketed.
This category has produced very large losses, which is reason for specific rather than general caution.
Light client challenges
Verifying another chain's consensus requires implementing its rules on the destination chain.
Which must be maintained as the source chain upgrades.
An outdated implementation can fail to verify valid proofs or, worse, accept invalid ones.
Zero-knowledge approaches
Proving source chain state transitions succinctly.
Which reduces verification cost substantially and is an active area of development.
Proving cost and latency are the current practical constraints.
Economic security
Some designs bond attesters so that provable misbehaviour is penalised.
Which converts the security question into an economic one that can at least be measured.
Bonds smaller than the value secured provide limited deterrence, and this is checkable.
Application-level checks
Applications can add their own validation regardless of the protocol used.
Which includes rate limits, value caps and delays on large transfers.
These have limited losses in several incidents and are straightforward to implement.
The recurring lesson
The weakest link is generally the attestation mechanism rather than the contracts on either side.
Composability across chains
Applications calling contracts on other chains atomically is substantially harder than transferring value.
Which is because a call can succeed on one side and fail on the other.
Designs handle this with callbacks, retries or explicit failure states, and none is fully atomic.
Chain reorganisation risk
A message attesting to an event on a chain that subsequently reorganises.
Which is why protocols wait for finality on the source chain before attesting.
Waiting periods differ by source chain according to its finality guarantees.
Governance of the protocol itself
Who can change the attester set, the verification logic or the supported chains.
Which is a control point equivalent in importance to the attestation mechanism.
Timelocks and multisignature arrangements apply here as elsewhere.
Standardisation efforts
Work on common interfaces so applications are not locked to one protocol.
Which is progressing and has not converged.
Applications supporting multiple messaging protocols hedge against any one failing.
Summary
Identify who attests, what it costs to compromise them, and what the application does on failure.
Insurance and coverage
Some protocols provide backstops or insurance for message failures.
Which has defined limits and trigger conditions.
Reading the conditions is more useful than noting that cover exists.
Closing
This is the highest-risk category in common use, and specific caution is warranted rather than general reassurance.
Operational monitoring
Protocols publishing real-time status of relayers and attesters allow users to see when something is degraded.
Which is genuinely useful during incidents and is not universal.
Transparency about failures is itself a signal about how an operation is run.
For applications
Value caps, rate limits and delays on large transfers are cheap and have limited losses repeatedly.
The pattern across incidents in this category is consistent enough to be predictive: the attestation layer fails, not the contracts on either side, and that is where scrutiny belongs.
One last point
The safest cross-chain operation remains the one you do not need to perform, which argues for consolidating activity where practical.