Skip to main content
The Solana programs publish a verified IDL bundle: one Anchor IDL per program, a shared error catalog, a provenance record, and generated TypeScript types. The IDLs are standard Anchor 0.31.1 output with corrected client metadata; the programs themselves are unchanged. This page lists the files and the rules you must apply by hand, because an IDL cannot express them. For what each program does, see Solana programs.

Downloads

The TypeScript types matching each IDL are under TypeScript types below. Use the JSON files and the types together; running anchor build yourself produces raw IDLs without the corrections described here.

Accounts you must derive yourself

Ten PDA expressions in the programs hash instruction arguments or call methods, which Anchor’s automatic account resolver cannot execute. The published IDLs drop those pda hints, so Anchor will not fill these accounts in. Derive them client-side and pass them explicitly: Derive each PDA under the program named in the first column. fill_id and fill_record are the same address under two names.

Canonical order ID

Which value to use depends on where the order originated:
  • Input settler instructions (open, finalise, refund, refund_on_non_fill) and the compact same-chain fills (fill_samechain, native_fill_samechain) use keccak256(Borsh(StandardOrder)) — the order as signed for the input settler, and the fully expanded order for the compact path. Never hash JSON, the compact order bytes, or a SHA-256 digest instead.
  • Ordinary output fills (fill, native_fill, attest_not_filled) take order_id as an argument and do not validate it. Pass the origin chain’s order identifier byte for byte, exactly as that chain’s input settler computed it. Only for an order opened on the Solana escrow is that the Borsh hash above; for an EVM or other origin, use that chain’s own order ID. A fill recorded under any other value cannot settle the order.

Canonical output hash

The output hash is keccak-256 over this packed encoding — not the Borsh encoding of MandateOutput:
chain_id and amount are their 32-byte big-endian values, and each variable-length field must fit a u16. For a compact same-chain fill, expand the output first, exactly as the program does: oracle and settler are the output-settler state PDA, chain_id comes from that state, token is the mint (32 zero bytes for native SOL), amount is output_amount, recipient is the recipient account, and callback_data is empty. context is empty for None, or 0xe0 || exclusive_for[32] || start_time[u32 big-endian] — ExclusiveForSelf uses the filler’s key as exclusive_for.

Example: deriving the escrow accounts

allOtherOpenAccounts must contain every other named account of open, because accountsStrict disables automatic resolution for the whole instruction. Use the camel-case account and argument names from the TypeScript types. Building an instruction does not check balances, ownership, hashes, or on-chain state. Enable TypeScript strict (or at least strictNullChecks) so Anchor’s account types distinguish required accounts from optional ones.

Compact same-chain fills

fill_samechain and native_fill_samechain must execute after a matching finalise_with_prefill in the same transaction. They do not create a LocalAttestation. Never submit them on their own or use them in place of ordinary fills.
Required instruction order, in one transaction:
finalise_with_prefill looks ahead for the matching compact fill and binds the supplied order ID to the expanded order before releasing the escrow. The compact fill handlers do not check for a preceding settlement instruction themselves, so a standalone compact fill pays the output but leaves the solver with nothing to claim against. The full workflow is in Input-first Solana settlement.

Remaining accounts

These accounts are appended with .remainingAccounts(...) after the named accounts; their number depends on the order, so they are not fixed IDL accounts. Below, N is the output or payload count, A is an attestation, and R is its stored rent-refund recipient. No remaining-account entry is a signer. For escrow settlement and refunds, remote attestations and local attestations committed to another consumer are not consumed. Their A accounts may be read-only, and their R slots are required but ignored — any existing read-only account, such as the system program, can fill an ignored slot. Never omit it. For a consumed attestation, pass the actual stored rent recipient. An executable recipient defers the rent reclaim but still needs its writable account meta. Duplicate addresses keep their positions; Solana merges the privileges of repeated keys when the transaction is compiled. A two-payload submit_consume, for example:

Events and errors

Each IDL lists the events its program emits. The Wormhole IDL includes OutputProvenEvent, emitted by the shared oracle code; its discriminator and field order match Polymer’s: chain ID as u128, then three 32-byte fields (remote identifier, application, payload hash). Each program IDL lists only its local errors. Shared errors — and the errors of programs it calls into — live in errors.json, keyed by enum name, with the Rust source path, numeric code, name, and message of each. Its programs map lists, per program ID, the local catalog and the shared or CPI catalogs it can return. To decode a failure, first identify the program that actually failed from the invocation logs, then look the numeric code up in that program’s local and shared catalogs. Prefer an explicit Anchor error name and message in the logs when one is present. Failures inside a CPI to intents_protocol use its catalog. Never label an unknown or external program’s error with these codes, even when the numbers overlap; Anchor framework errors and external CPI errors need their own decoders. A catalog being associated with a program does not mean every variant is reachable from every instruction. Anchor’s default error decoder does not read errors.json — load it yourself. Debugging on Solana lists the errors you are most likely to meet.

Provenance

The bundle describes the five production programs at source commit 776773a of the Solana programs repository, built with Anchor 0.31.1. provenance.json records the full commit, the source and raw-IDL fingerprints, every correction applied, and the hash of each published file. The corrections change only client metadata — removed pda hints and the added Wormhole event — never accounts, flags, arguments, or on-chain constraints. The published audit reports cover the reviewed contract revisions; the IDL tooling is a later integration change.

TypeScript types

Camel-case TypeScript types matching each IDL, for use with Anchor’s Program<T>. Save each one as types/<program>.ts next to the JSON files. Each type describes the corresponding JSON IDL exactly; if you regenerate IDLs yourself, regenerate the types from the same build.
input_settler_escrow.ts
output_settler_simple.ts
polymer.ts
intents_protocol.ts
wormhole.ts

Next steps

Solana programs

What each program does, and its account model

Debugging on Solana

Read failed transactions and error codes