> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Debugging on Solana

> How to read failed LI.FI Intents transactions on Solana: error-code fingerprints for fills, decimal-vs-hex rendering, instruction indexing, and preflight and RPC behavior.

This page collects the diagnostics for failed Solana intent transactions. It assumes you know the program surface — see [Solana programs](/lifi-intents/architecture/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](/lifi-intents/architecture/solana-programs#which-identity-goes-in-which-field) |
| `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 |

> [!NOTE]
>
> 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`](https://docs.li.fi/idl/errors.json) — see [Events and errors](/lifi-intents/architecture/solana-idl#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.

## Next steps

> **[Solana fills](/lifi-intents/architecture/solana-programs#fills)**
>
> The fill instructions and their validation rules

> **[Solana programs](/lifi-intents/architecture/solana-programs)**
>
> The program reference behind these errors


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.