Concepts

Hook

A registered unit of destination-side logic, addressed by a namespaced, versioned ID such as imd.research.v1. A hook declares its actions, the input and output schema of each, who may call it, and how much value a call may move. Hooks are immutable in meaning: a breaking change is published under a new ID (.v2), never by mutating .v1.

Action

A named entry point on a hook, in UPPER_SNAKE_CASE: START_RESEARCH, CAPPED_BURN. A HookCall targets exactly one action.

HookCall

The request. It names the hook and action, commits to the payload by hash, and carries its own replay and spend protections (nonce, expiry, maxSpend). See HookCall.

HookReceipt

The result: success, partial or failed, plus the destination transaction, an output hash and the amount spent. See HookReceipt.

Hook Registry

The destination-side index from hook ID to adapter, version, status, permissions and spend policy. The gateway refuses any call whose hook is not in the registry. See Registry.

Adapter

The contract that turns a verified call into the hook's native call. Adapters isolate hook-specific logic from the gateway: the IMD adapter knows how to start IMD jobs, the POOL4 adapter knows CappedBurn, a custom adapter knows your vault. See Adapters.

Route

A (source chain, destination chain) pair with its transport path. In v1 the source is always Solana; destinations are EVM chains (the demo models Ethereum, Base and Arbitrum). Routes have their own latency profile and health, shown on Status.

Execution

One HookCall's journey through ten stages, plus all the evidence collected along the way. The explorer is a list of executions.

App (caller)

A registered Solana identity (a program, or an authority for client-originated calls) that the router accepts HookCalls from. Each app has its own Wormhole emitter, allowlisted hooks and spend limits. IMDHOOKS is the reference app.