A messaging provider transports messages; your application still needs to define who may send them and what receiving them is allowed to change.
Define the application's trust boundary
Chainlink's CCIP EVM best practices describe receiver-side validation and other integration precautions. Source 1 is specific to CCIP; different transports require their own checks. The transferable review question is which combination of transport, source chain, source application, and destination permission authorizes a state change.
Example: a valid message from the wrong application
A message can arrive through the intended transport yet originate from an application your protocol did not intend to trust. Prepare tests with an unexpected source contract and with a valid contract identity on the wrong network. Receiving authenticated transport data should not automatically grant permission to mint, release escrow, or execute arbitrary calls.
Trace each asset lifecycle
For a transfer, list when assets are locked or burned, when the destination recognizes the obligation, and when assets are minted or released. Account for pending and failed transfers explicitly. Review refunds and retries against the same state machine so one transfer cannot be settled on the destination and refunded independently on the source.
Test failure recovery, not just delivery
Exercise duplicate delivery attempts, unavailable destinations, insufficient execution resources, paused receivers, and a configuration change while a message is pending. Define which actor can retry and which data must remain immutable. Where order matters, specify the ordering rule and test what happens when later work arrives before earlier work.
Treat configuration as part of the protocol
Record the permitted chains, source applications, routers, token mappings, limits, and authorities. Include the update process in the threat model. A correctly written receiver can still accept unintended instructions if an administrative update changes the trusted sender or points a token mapping at the wrong asset.
Prepare both sides for review
Send the source and destination repositories, deployment configurations, message formats, and failure-handling procedures. Identify provider assumptions and excluded operational systems. A useful cross-chain report ties findings to a complete flow; auditing only one endpoint can leave the central accounting and trust assumptions unresolved.
Review Checklist
- Reject an unintended source chain or application.
- Test duplicate, delayed, and failed transfers through recovery.
- Verify that one obligation cannot be both settled and refunded.
Sources and Further Reading
The linked sources describe the standards or research discussed above. Review scenarios are practical planning examples, not findings from an audit of a specific project.
Discuss Your Audit Scope
Start with your email and a short project description. Technical details can follow. Request a smart contract audit quote or review public CTDSEC audit examples.