Bridge Integration Checklist: Verify the Route, Receiver and Recovery Path

Trust model questions

A bridge integration checklist should begin at the destination contract: what evidence makes it accept a message and what authority can change that rule? The answer defines the integration's trust boundary. A bridge name, an audit count or a successful test transfer does not describe the complete path by which an instruction becomes executable.

Trace the path in order. A source application creates an event or state change. Some mechanism establishes what happened and when it is sufficiently final. A transport or execution service delivers the resulting message. The destination verifies the evidence and decides whether the message is authorized for this application. Each step has its own failure and availability conditions.

Do not merge verification with delivery. A relayer can be responsible for submitting an authenticated message without being authorized to invent its contents. In another design, a committee's signatures may be part of the evidence the destination trusts. The security review needs to identify the actual role rather than assume that every off-chain participant has the same power.

Write the application invariant separately from the bridge invariant. A valid bridge message can still ask your application to perform an invalid operation. For example, an authenticated sender may submit an amount that exceeds a product-specific limit or refer to a token unsupported by the receiver. Authentication establishes origin under the bridge model; the receiver still needs its own authorization and accounting rules.

The cross-chain bridge security guide explains the broader attack classes. For an integration review, reduce those classes to concrete assertions about the selected route. Name the source and destination chain, the deployed contracts, the message format and the token representation. "Uses a secure bridge" is not an assertion that a test can evaluate.

Our SDK census found another reason to be precise. The recorded Wormhole Mainnet registry contained 41 core-bridge chain entries but 29 token-bridge entries. The difference is not a safety ranking. It shows that a core messaging address is not evidence of a token-bridge entry for the same chain in that registry.

Validator and key questions

Identify every authority that can cause the receiver to accept evidence or change its acceptance rules. This includes the normal verification set and any administrator that can replace it. Record the current configuration, not only the architecture diagram. A threshold described in documentation is useful context, but the integration depends on the threshold and keys actually used by its deployed route.

Wormhole's security documentation describes Guardians, a Global Accountant and a Governor. The Global Accountant checks a supply invariant for covered transfers, while the Governor can delay suspicious flows. These are distinct controls with particular scopes. Their presence does not establish that your receiver validates the intended source application or handles token accounting correctly.

The documentation also discusses delegated chains and their relationship to the canonical Guardian process. That makes a simple count of operators an incomplete description. The reviewer must ask which participants observe the relevant chain, what quorum is required and how the resulting evidence reaches the canonical verification path. Preserve the route-specific answer with the deployment record.

Key rotation needs a transition rule. Determine whether messages created under an old set remain valid, whether a grace period exists and how the destination identifies the set associated with a message. A rotation that improves key custody can still disrupt message processing if pending messages and receiver configuration are not considered together.

Ask about operator independence with evidence rather than labels. Separate organizations can share infrastructure, a software release or an operational dependency. Conversely, several processes run by one organization do not automatically create independent decision makers. The useful output is a map of correlated failures and the controls that limit them, not an unsupported decentralization score.

Application keys deserve the same attention. A correctly authenticated cross-chain message from a compromised source administrator remains correctly authenticated. The receiver may need narrow permissions, operation-specific limits or governance delay to contain that authority. Connect this review to administrator key management so the bridge assessment does not stop at the transport layer.

Record unknowns explicitly. If the current verifier set or upgrade administrator cannot be confirmed, label the route configuration unverified. Do not substitute a historical audit's description for a current read of the deployment.

Rate limits and pause

A rate limit constrains how much value or activity can pass within a defined accounting model. Its effectiveness depends on the unit, direction, scope and reset behavior. A token amount, a value estimate and a message count are different limits. The configuration should explain which loss path the limit is intended to contain.

For token transfers, inspect decimals and representation. A limit expressed in local token units can behave unexpectedly if a wrapped asset uses a different precision or if the integration normalizes amounts incorrectly. The reviewer should trace the amount from source debit through message encoding to destination credit, including truncation and remainder handling where applicable.

Pause is a separate state transition. Decide whether it stops message acceptance, token release, new source deposits or only a particular receiver action. Stopping one side does not necessarily stop messages already in transit. The response procedure must identify what happens to those messages and which operation remains available to recover or reconcile them.

Wormhole's Governor description is useful as an example of flow-based intervention, while the Chainlink CCIP protocol description separates message commitment and execution components. These architectures motivate different integration questions. Do not copy a control name across products and assume identical semantics; inspect the actual lane, token pool and receiver behavior used by the application.

A hypothetical receiver might stop new credits while preserving a read-only status endpoint and a controlled recovery path. That choice should be tested against the accounting invariant. If a source debit has already occurred, the system needs an explicit outcome for the pending message rather than an indefinite state described only as "paused."

The pause and circuit-breaker design connects these controls to a wider incident response model. For a bridge integration, include the remote chain and message queue in the test setup. A local pause test cannot establish what happens after a delayed message is delivered.

Incident history

Read incident history as a set of hypotheses to test against the selected deployment. The important questions are what failed, which component was affected, what changed and whether that change is present in the route being integrated. A loss figure without this connection contributes little to an engineering acceptance decision.

Use a primary incident report where it is available. Preserve the distinction between the first public notice, the technical account and a later remediation update. Early reports can correctly identify abnormal activity while leaving the root cause unresolved. A later explanation may narrow the affected scope or change the interpretation of an earlier claim.

The primary Wormhole incident-report URL attempted during this research returned 403. It is recorded as unreachable in the research evidence. We therefore do not reproduce a loss total or a root-cause narrative from search snippets. The current security documentation and repository census support the integration questions here; they do not substitute for a retrieved historical post-mortem.

An audit performed before a relevant change may not examine the remediation. An audit performed afterward may still exclude the affected component. Read the scope and revision before using either as evidence. The post-mortem analysis guide explains how to separate the confirmed mechanism from financial accounting. It also examines response claims.

Do not treat the absence of a public incident as proof of safety. Reporting can be incomplete, and a new integration can create a failure path that the bridge's previous users did not exercise. Historical evidence is one input to the threat model. It is not a replacement for testing the receiver's current authorization, accounting and recovery behavior.

The acceptance note should identify any historical question that remains unresolved and explain whether it blocks the intended use. This is more useful than assigning an incident count without a common definition or observation period.

Integration checks

Build a route manifest before the first production transfer. It should bind the network identifiers, contract addresses, token representations, verifier configuration and application sender to one reviewable record. Use official deployment references and confirm that the code and configuration at those addresses match the intended release. A copied address in an SDK is a starting reference, not a live health check.

Test the receiver with valid and invalid application context. A valid bridge proof from an unapproved source application should not grant authority. A message for another destination should not be accepted. Repeated delivery should preserve the intended idempotency or replay rule. These are defensive integration tests on controlled deployments, not tests to perform against someone else's production funds.

1. Bind the message to the intended origin chain and application.
2. Verify the proof or signatures under the current bridge configuration.
3. Check the requested operation, token, amount and replay state.
4. Reconcile the resulting debit or credit with the application invariant.

Exercise delivery failures deliberately. Include a receiver revert, insufficient execution resources, delayed delivery and retry after an operational change. The expected result should say whether the message remains pending, can be retried or requires a controlled recovery action. A dashboard showing a source transaction succeeded cannot answer whether the destination effect occurred.

One transfer is one observation. A successful small transfer establishes that one path executed under the recorded state. Expand the review to boundary values and role changes. Then exercise failure recovery. Preserve the tool versions, test chain state and configuration with the results so another engineer can repeat the exercise. The security tools hub can help identify supporting methods, but the acceptance criteria must come from the integration's own behavior.

When commissioning external review, provide this route manifest and failure matrix rather than a generic bridge integration description. The Pharos Production member profile is one service reference for evaluating a provider's fit. Require the eventual report to identify which bridge components were reviewed, which were treated as dependencies and which application assertions were tested.

Finish with reconciliation. For every test that moves value, explain the source effect and destination effect, joined through the message state. If those records cannot be joined, the team may not be able to distinguish delayed execution from an accounting defect during an incident.

Original SDK census: core messaging versus token bridge

Method

Source and selection

Compare all literal Mainnet chain/address pairs in core.ts and tokenBridge.ts at one Wormhole SDK commit. Include their union; exclude Testnet and Devnet sections.

Retrieved

2026-09-06

Observation

Complete union of 41 Mainnet chain keys at one SDK commit; non-Mainnet sections excluded.

Results

The 12 core-only chain keys are a registry difference. They do not establish that those chains lack every possible token transfer product, and they do not establish that the other routes are operational. The integration checklist should therefore confirm the specific product and route after finding a core address.

Both files were fetched from the same recorded commit. Comparing moving branches from different dates could create an artificial mismatch. The saved rows retain each address so the count can be checked without making a new live-network claim.

Limits

• Literal address registry census, not an on-chain deployment or health verification.
• No transfers were sent and no bridge was ranked as safest.
• Chain names are SDK identifiers; support can differ across bridge products and change after the recorded commit.

The reproducible record is kept in the repository: seo/research/articles-42-51-2026-09-06/surveys.py and seo/research/articles-42-51-2026-09-06/survey-45.json. These file paths are not public downloads.