Handle a version mismatch in a Solana transaction decoder

An indexer can know the correct signature and still receive an unsupported-version error. The request declares the newest transaction format the client knows how to decode.

Declare the decoder’s actual limit

For a decoder that supports legacy and v0 messages, replace the signature below and submit this request. Record the RPC error separately from a successful null result. The latter means the transaction was unavailable at the requested commitment.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTransaction",
  "params": [
    "TRANSACTION_SIGNATURE",
    {
      "encoding": "json",
      "commitment": "finalized",
      "maxSupportedTransactionVersion": 0
    }
  ]
}

Resolve instruction account indices for v0

With JSON encoding, construct the account key list from message.accountKeys followed by meta.loadedAddresses.writable and then meta.loadedAddresses.readonly when present. For static keys A and B, loaded writable C and loaded readonly D, instruction account index 2 refers to C. A legacy-only decoder that uses only the two static keys will misread that instruction.

If a newer format exceeds the declared limit, preserve the signature for reprocessing and add support for that format before raising the request limit. Test decoding against a transaction with lookup-table accounts as well as an ordinary legacy transaction.

Documentation