Skip to content
Mainnet Live. All executions, addresses and hashes are live.
WORMHOOK

Cross-chain execution protocol

WORMHOOK

Cross-chain execution for hooks.

Bring hooks to Solana. Powered by IMD.

Solana applications invoke registered EVM and IMD hooks through Wormhole and get an execution receipt back on Solana. Every call has an ID, and every stage has evidence.

Live trace · demoopen execution →
  1. SOLANA8Qs…a91
  2. HookCall #18291
  3. WORMHOLEmessage verified
  4. executor delivery
  5. ETHEREUMimd.research.v1
  6. IMDAdapter
  7. EXECUTEDtx 0x9f3c…a61b
  8. receipt · return path
  9. RECEIPT RETURNED ✓status success · 41.2s
Network · last 24htest data
Executions53
Success rate91.8%success + partial
Median latency39.1scall → receipt
In flight4
Active hooks8
Apps5

Recent executions

newest first
All executions

Routes

24h
Status
  • Solana→Ethereumdegraded
    p50 41.3sok 90%33 calls
  • Solana→Baseoperational
    p50 26.4sok 94%19 calls
  • Solana→Arbitrumoperational
    p50 22.6sok 100%1 calls
  • Ethereum→Solanaplanned

    EVM-initiated calls into Solana. Not in v1 scope.

Registry

Registered hooks

Every hook has a namespaced ID, a version, an adapter, declared actions, permissions and a spend policy. Breaking changes ship as a new ID.

Browse registry

SDK

Three calls from Solana to a receipt.

Prepare a HookCall, send it, wait for the receipt. In the skeleton, simulate() runs the full ten-stage lifecycle locally, so you can build against the final API today.

  1. 01
    prepareCall()

    Builds the HookCall, hashes the payload, and derives the call ID and expiry.

  2. 02
    simulate()

    Plays every stage: source tx, VAA, delivery, verification, execution and receipt.

  3. 03
    waitForReceipt()

    Resolves with success, partial or failed. Every outcome is a receipt.

research.ts
import { WormHookClient } from "@wormhook/sdk";

const client = new WormHookClient({ network: "devnet", appId: IMDHOOKS_APP_ID });

const call = await client.prepareCall({
  hookId: "imd.research.v1",
  action: "START_RESEARCH",
  payload: { query: "Validator client diversity, Q3 2026", depth: "standard", budget: "40" },
  maxSpend: "40",
});

const execution = await client.simulate(call);   // local simulation in the skeleton
const receipt = await execution.waitForReceipt();  // { status: "success", outputHash, ... }

Architecture

Wormhole carries the message. WORMHOOK defines what happens at each end.

A router on Solana validates the caller and posts a message. Guardians sign it, an executor delivers it, and a gateway on EVM verifies it and runs the registered hook through its adapter. The receipt goes home on the same rails.

Architecture docs
SOLANAsource
  1. HookCaller
    your program / client
  2. WormHookRouter
    validates caller · posts message
    planned
WORMHOLEtransport
  1. Wormhole Core
    message posted
  2. Guardians
    13/19 signatures → VAA
  3. Executor
    delivery to destination
EVMdestination
  1. WormHookGateway
    verify · replay · expiry · caps
    planned
  2. HookRegistry
    hookId → adapter, permissions
    planned
  3. Adapter
    IMD · POOL4 · Custom
    planned
  4. Hook
    executes action
Return pathHook output → HookReceipt → Wormhole → Router records receipt on Solana

Powered by IMD

IMD is the first set of hooks.

IMD runs research, build and swarm jobs and operates POOL4. WORMHOOK makes those capabilities callable from Solana: IMDHOOKS is the Solana app, and the imd.* hooks are the destination.

The protocol is hook-agnostic. Anyone can register a custom adapter, and IMD gets no special path through the gateway.

  • imd.research.v1

    Starts an IMD research job from a Solana app.

    START_RESEARCH · CANCEL_RESEARCH

  • imd.build.v1

    Submits a build job (spec → artifact) to IMD.

    START_BUILD

  • imd.swarm.v1

    Dispatches a task to a swarm of IMD workers.

    DISPATCH_SWARM

  • imd.pool4.v1

    Routes contributions into POOL4 with CappedBurn semantics.

    CONTRIBUTE · CAPPED_BURN

Security preview

What the gateway will enforce, and what isn't real yet.

These are design commitments for phase 2, not shipped guarantees. Nothing here is audited.

Security model
Replay protectionplanned

Call IDs are derived from source app, nonce and payload hash. The gateway rejects a consumed ID (WH-302).

Expiryplanned

Every HookCall carries an expiry. Late deliveries are refused, never executed late (WH-201).

Spend capsplanned

maxSpend is bounded by both the hook's per-call cap and the app's daily cap (WH-306).

Receipts always closeplanned

Reverts are caught at the gateway and returned as failed receipts, so Solana state never hangs.

Contracts: not deployed · Audit: not started · Data on this site: simulatedThreat model →