Skip to content
Ashen Docs

Bridge Integrations

Overview

Section titled “Overview”

Ashen does not ship a canonical bridge. Instead, it provides reference contracts for verifying messages from major bridge networks and leaves the application wiring to you. This guide outlines the common architecture, provider-specific notes, and a practical checklist for integration.

Reference contracts live in contracts/:

  • axelar_gmp_v1 for Axelar GMP
  • wormhole_core_v1 for Wormhole VAAs
  • hyperlane_ism_v1 for Hyperlane ISM verification

See /contracts/examples/ for a summary of each.

Architecture

Section titled “Architecture”

Every integration has the same core components:

  1. Source chain sender: emits or queues the outbound message.
  2. Bridge network: signs, attests, or otherwise proves the message.
  3. Relayer: submits the proof payload to Ashen.
  4. Verifier contract: validates signatures and replay protection.
  5. Destination handler: your app contract that consumes the message.

Message Flow (Generic)

Section titled “Message Flow (Generic)”
  1. The source chain sender emits a message with destination and payload.
  2. The bridge network signs or validates the message and produces a proof.
  3. A relayer submits the proof to the verifier contract on Ashen.
  4. The verifier checks:
    • chain or domain identifiers
    • signer/validator/operator threshold
    • message structure and hashes
    • replay protection and ordering
  5. The verifier calls your destination handler with the decoded payload.

Provider Notes

Section titled “Provider Notes”

Axelar GMP

Section titled “Axelar GMP”

Axelar uses operator sets to sign command batches. Typical integration steps:

  • Deploy axelar_gmp_v1 and initialize it with the current operator set.
  • Accept execute calls from relayers and validate command approvals.
  • Record command IDs to prevent replays.
  • Hand off decoded payloads to your app contract.

Wormhole

Section titled “Wormhole”

Wormhole uses guardian signatures over a VAA (Verified Action Approval).

  • Deploy wormhole_core_v1 and configure the guardian set and threshold.
  • Validate emitter address, sequence, and chain ID in each VAA.
  • Persist consumed VAAs to block replays.
  • Route verified payloads to your handler contract.

Hyperlane

Section titled “Hyperlane”

Hyperlane relies on an ISM (Interchain Security Module) to verify messages.

  • Deploy hyperlane_ism_v1 with validator sets per origin domain.
  • Check the message origin domain and nonce ordering.
  • Validate the ISM proof and only then dispatch to your handler.

Integration Checklist

Section titled “Integration Checklist”

Use this list before going live:

  • Map external chain IDs or domains to Ashen IDs consistently.
  • Enforce replay protection in the verifier.
  • Restrict dispatch to a dedicated handler contract.
  • Validate payload schemas and lengths before decoding.
  • Configure operator/guardian/validator sets with rotation procedures.
  • Test with local harnesses and provider testnets.

Testing Tips

Section titled “Testing Tips”
  • Use /guides/contract-testing/ to unit test verifier contracts in isolation.
  • Build a small handler contract that records payloads for assertions.
  • Keep test payloads deterministic and include invalid cases.
Section titled “Related”
  • /contracts/examples/ for reference contract summaries
  • /guides/contract-testing/ for harness-based tests
  • /concepts/private-mempool/ for sealed transaction behavior