Skip to content
Mainnet Live. All executions, addresses and hashes are live.
WORMHOOK
conceptualv0.1 · skeleton docs

Architecture

How a call travels from a Solana program to an EVM hook and back.

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

The path, end to end

conceptual
SOLANA
  HookCaller (your program)
    │  CPI: call(hook_id, action, payload, max_spend, ttl)
    ▼
  WormHookRouter
    │  checks caller is a registered app, assigns nonce, derives call ID,
    │  posts the HookCall to Wormhole Core, records pending call state
    ▼
WORMHOLE
  Core message  →  guardians observe at source finality  →  VAA (13/19)
    │
  Executor        picks up the request and delivers the VAA to the destination
    ▼
EVM
  WormHookGateway
    │  verifies VAA + emitter, checks expiry, consumes call ID (replay),
    │  enforces spend caps, looks up the hook
    ▼
  HookRegistry   →   Adapter (IMD | POOL4 | Custom)   →   Hook
    │
  receipt  ← output hash, amount spent, status (try/catch: reverts become failed receipts)
    ▼
WORMHOLE  (return message)
    ▼
SOLANA
  WormHookRouter records the receipt and closes the pending call

Components

ComponentChainResponsibilitySkeleton status
HookCallerSolanaYour program. Builds the call and CPIs into the router.Mock
WormHookRouterSolanaCaller auth, nonce, call ID, message posting, receipt state.Planned
Wormhole CoreBothMessage emission and VAA verification.External, integration pending
ExecutorOff-chainDelivers the signed message to the destination; paid at the source.External, integration pending
WormHookGatewayEVMVerification, replay, expiry, caps, dispatch, receipt emission.Planned
HookRegistryEVMHook ID → adapter, status, permissions, spend policy.Planned
AdaptersEVMTranslate a call into a hook's native interface.Planned
IndexerOff-chainJoins source, Wormhole, destination and receipt data into executions.Mock service

Design choices

  • Receipts always come home. The gateway wraps adapter execution in try/catch. A revert produces a failed receipt instead of a stuck call, so Solana-side state always reaches a terminal status.
  • The call carries its own safety. Nonce, expiry and maxSpend are inside the signed message, so the gateway can enforce them without trusting the executor.
  • The executor is untrusted. It can delay or decline delivery but cannot forge, alter or replay a call. See Executor model.
  • Adapters are the blast-radius boundary. The gateway never calls hook contracts directly.

Services in the app

The UI only talks to typed service interfaces (ExecutionService, RegistryService, AppService, WormholeService, ReceiptService, SearchService). The skeleton binds them to mock implementations; phase 2 binds indexer- and RPC-backed implementations in one place without changing components.