Debugging on Solana

This page collects the diagnostics for failed Solana intent transactions. It assumes you know the program surface — see Solana programs — and focuses on turning a raw error back into a cause.

Fill errors

A failed Solana fill usually surfaces as a numeric error with no message. The table below maps the common codes for the current deployment (Anchor 0.31.1). Treat each row as a likely cause, not a definitive diagnosis. Before interpreting a code, identify which program and instruction actually failed: errors from inner CPIs — the System Program, SPL Token, or intents_protocol — are reported through the same channel.

Error	Rendered in raw logs	Often means
`InvalidOutputSettler` (6009)	`0x1779`	`output.settler` in the signed order is not the settler state PDA — see the identity matrix
`AccountOwnedByWrongProgram` (3007)	`0xbbf`	An account in the wrong slot — either a program id passed where a state PDA belongs, or the whole account list shifted by one because a stale IDL omitted an account
`AccountNotInitialized` (3012), `ConstraintTokenOwner` (2015), `ConstraintAssociatedTokenTokenProgram` (2023)	`0xbc4`, `0x7df`, `0x7e7`	Token-account construction problems: an ATA derived under the wrong token program (Token-2022 vs classic), a wrong owner, or a wrong token program in the constraint slot
`ConstraintSeeds` (2006)	`0x7d6`	A PDA you derived does not match what the program derives — `fill_record`, `local_attestation`, or the settler singleton
System Program `0x0` with an `already in use` log	`custom program error: 0x0`	The `fill_record` PDA already exists: the output is already filled. Without the `already in use` log, `0x0` is some other account-creation collision
`InvalidTimestamp` (6022)	`0x1786`	The cluster clock could not be converted to a `u32` timestamp

Settlement and refund errors

These come from input_settler_escrow, or from intents_protocol when the escrow consumes an attestation through CPI.

Error	Rendered in raw logs	Often means
`WrongAttestationCount` (6304)	`0x18a0`	Wrong number of `remaining_accounts`. `finalise` needs one attestation and one rent-refund slot per output; `refund_on_non_fill` needs exactly `[attestation, rent_refund]`. Its message still reads “Exactly one attestation account is required”
`FilledTooLate` (6201)	`0x1839`	A `SolveParams.timestamp` is after `fill_deadline`
`ExecutableRentRefundAccount` (6311)	`0x18a7`	The sponsor is executable, and so is the settlement signer that receives the rent instead
`InvalidRentRefundAccount` (6107)	`0x17db`	The rent-refund slot for a consumed attestation is not the attestation’s stored `rent_refund`
`LocalAttestationAlreadyConsumed` (6108)	`0x17dc`	The attestation was already consumed and is no longer a valid proof
`InvalidLocalAttestationAccount` (6103), `InvalidLocalAttestationTimestamp` (6101)	`0x17d7`, `0x17d5`	The `LocalAttestation` is not at the derived address, has the wrong size, or its stored timestamp differs from `SolveParams.timestamp`

Input-first settlement errors

An input-first settlement fails as one transaction. These six errors come from input_settler_escrow.

Error	Rendered in raw logs	Often means
`NotTopLevel` (6305)	`0x18a1`	`finalise_with_prefill` was called by a program. It must be a top-level instruction, and so must the compact fill
`MissingSamechainFillInstruction` (6306)	`0x18a2`	No matching compact fill appears later in the same transaction. Check the instruction order, `order_id`, and signer
`AmbiguousSamechainFillInstruction` (6307)	`0x18a3`	Two or more matching compact fills in the same transaction. Keep exactly one
`InvalidSamechainFillInstruction` (6308)	`0x18a4`	The fill accounts do not match the derived accounts. Check the settler, canonical token accounts, `fill_record`, program IDs, and account count (10 for `fill_samechain`, 5 for `native_fill_samechain`) — an IDL from before the compact fills dropped their attestation accounts produces too many
`InvalidSamechainOrder` (6309)	`0x18a5`	The reconstructed order does not hash to `order_id`. Check the compact fields, recipient, mint, identities (all three must be the output-settler state PDA), context, callback, and output count
`InvalidSamechainOrderContext` (6310)	`0x18a6`	The `user` or `mint` account passed to `finalise_with_prefill` is not the one recorded in the order’s escrow context

output_settler_simple has its own NotTopLevel (6507, 0x196b) for a compact fill invoked by a program.

Proof, non-fill, and rent errors

Error	Program	Rendered in raw logs	Often means
`FillDeadlineNotPassed` (6402)	`output_settler_simple`	`0x1902`	`attest_not_filled` was called at or before `fill_deadline`
`NotFilledWindowElapsed` (6404)	`output_settler_simple`	`0x1904`	`attest_not_filled` was called more than 48 hours after `fill_deadline`. Refund through `refund` at expiry instead
`FillRecordNotClosable` (6508)	`output_settler_simple`	`0x196c`	`close_fill_record` was called at or before `close_after` (`fill_deadline` + 48 hours)
`InvalidRentRefund` (6509)	`output_settler_simple`	`0x196d`	The `rent_refund` passed to `close_fill_record` is not the filler recorded in the `FillRecord`
`UnauthorizedFillSubmitter` (6722)	`polymer`	`0x1a42`	`submit_consume` was signed by someone other than the recorded filler of a fill payload
`AttestationContextLengthMismatch` (6600), `EmptyPayloads` (6601)	`polymer`, `wormhole`	`0x19c8`, `0x19c9`	Wrong `remaining_accounts` count for the payloads (pairs for `submit_consume` and Wormhole `submit`, singles for Polymer `submit`), or no payloads
`UnauthorizedLocalAttestationConsumer` (6106)	`intents_protocol`	`0x17da`	The consume was signed by neither the committed consumer nor that program’s `local_consumer` PDA. A wrong `output.oracle` shows up earlier, as a PDA mismatch (`ConstraintSeeds` or `InvalidLocalAttestationAccount`)
`LocalAttestationNotConsumed` (6110)	`intents_protocol`	`0x17de`	`reclaim_local_attestation_rent` on an attestation that has not been consumed
`ExecutableRentRefundAccount` (6109)	`intents_protocol`	`0x17dd`	`reclaim_local_attestation_rent` destination is still executable

Each program now has its own error range: CommonErrors 6000–6022 (shared), intents_protocol 61xx, input settler 62xx–63xx, output settler 64xx–65xx, oracles 66xx–68xx. A shared CommonErrors code can still come from any of the programs, and SPL Token, the System Program, and Anchor itself use their own numbers. Read the failing program id from the logs before reading the code, then look it up in errors.json — see Events and errors.

Reading raw errors

Anchor error numbers are decimal, while raw logs use hex (3007 = 0xbbf). Map “Instruction N” against the complete transaction. Wallets and builders may prepend ComputeBudget instructions and shift the index.

Preflight and RPC behavior

When a transaction fails in preflight, there is no on-chain transaction and getTransaction/getLogs have nothing to show. Read the simulation logs from the error object itself (error.logs in web3.js), or re-simulate the signed transaction. Two more RPC realities:

TransactionExpiredBlockheightExceededError is a client-side timeout, never a verdict — the transaction may still have landed. Check the signature status before rebuilding and retrying, or you may pay twice.
A confirmed transaction can still be rolled back in rare cases; use finalized where finality matters.

Getting Started

Intents API

Solver API

MCP Server

Architecture

Knowledge Base

Debugging on Solana

Fill errors

Settlement and refund errors

Input-first settlement errors

Proof, non-fill, and rent errors

Reading raw errors

Preflight and RPC behavior

Next steps

Solana fills

Solana programs

​Fill errors

​Settlement and refund errors

​Input-first settlement errors

​Proof, non-fill, and rent errors

​Reading raw errors

​Preflight and RPC behavior

​Next steps

Solana fills

Solana programs

Fill errors

Settlement and refund errors

Input-first settlement errors

Proof, non-fill, and rent errors

Reading raw errors

Preflight and RPC behavior

Next steps