conceptualv0.1 · skeleton docs

Returning receipts

How a result gets from the destination chain back into Solana state.

The return path

conceptual

EVM   gateway builds HookReceipt → posts via Wormhole Core (gateway emitter)
      → guardians sign at the destination's consistency level → receipt VAA
      → executor delivers to Solana (paid from the original quote)
SOL   WormHookRouter: verify VAA, check emitter = registered gateway for the
      call's destination, check pending call exists → write receipt account,
      close pending call

The explorer shows this as stages 9 (Receipt emitted) and 10 (Receipt returned / recorded).

Guarantees the router will enforce

One receipt per call. A second receipt for the same call ID is ignored.
Right sender. Receipts from any emitter other than the registered gateway on the call's destination chain are rejected.
No receipt without a call. The router only accepts receipts for pending calls it created.

Consuming receipts in your program

Two patterns:

Pattern	How	Good for
Poll	Read the receipt account `["receipt", call_id]` in a later instruction.	Simple flows, user-triggered settlement
Callback	Router CPIs into a callback instruction your app registered.	Automated settlement. Planned, design open (see `CORE_TECH_PLAN.md`).

When the return path fails

The hook has already run. The fix is to redeliver the receipt VAA, which is safe because recording is idempotent. The hook never runs again. Receipt rejection on Solana surfaces as WH-502; in-transit receipts as WH-501.

Latency

Return latency depends on the destination's consistency setting. Waiting for full Ethereum finality takes on the order of 15 minutes; faster settings trade safety for speed. The demo assumes a faster setting, and the real choice is part of phase 2.