Decoding Solana program activity declaratively, including the calls that failed

1. One query, no IDL, no deploy

The request filters the instructions table by a programId and a discriminator over a slot window. This reads Jupiter's sharedAccountsRoute instructions, the program's main swap-routing call:

No schema, no IDL registration, no deployed indexer. The matching instructions stream straight back. One thing to size correctly: Solana programs like Jupiter are extremely high volume, so a wide window trips the response-size cap. Keep the slot window small and widen only as needed, the same discipline described in the Portal MCP guide.

Run it and the numbers tell a story most pipelines hide. Over these six slots the query returns 48 sharedAccountsRoute instructions, and only 10 committed. Thirty-eight did not, fifteen of those carrying the slippage error shown later. A pipeline that keeps only the successes silently discards four out of five attempts.

2. The discriminator picks the instruction

A Solana program exposes many instructions, and the first bytes of an instruction's data identify which one it is. Anchor programs use an 8-byte tag, the discriminator, which you match with d8. The Portal also exposes the leading 1, 2, and 4 bytes as d1, d2, and d4, so you can filter at whatever width you need. The same real instruction matches all four, each a prefix of the next:

For an Anchor program you almost always want d8, which pins one exact instruction. The narrower prefixes are useful for non-Anchor programs, or for grouping a family of instructions that share a leading byte. The mechanics of discriminators and the SVM data model are covered in what is a Solana indexer; here they are just the filter.

3. Tree position, accounts, compute

Each returned instruction is more than its data. It carries an instructionAddress that places it in the transaction's instruction tree, the full ordered accounts list it touched, and the compute it used. A real successful match has instructionAddress: [3], meaning it is the fourth top-level instruction, and an account list that starts with the Token program and includes the mints in the route, USDC (EPjF…Dt1v) and wrapped SOL (So11…1112) among them:

The ordered account list is what makes an instruction interpretable without a per-program decoder: the positions map to the program's account schema, so you can read the mints, the pools, and the authorities directly. The instructionAddress lets you reconstruct the call tree, the Solana analogue of EVM internal calls.

4. The failure path most tools drop

On Solana, a transaction can be included in a block and still fail. Many data pipelines keep only the successful instructions, which quietly biases anything you count: attempted swaps, slippage failures, and contention all disappear. The Portal record keeps the failure path. The same query above returns successful and failed instructions side by side, tagged by error and isCommitted, two independent signals:

The two fields are not the same signal. Across this one query, 38 of the 48 matching instructions are uncommitted, and 22 of those carry no instruction-level error at all (error: null with isCommitted: false), having still burned compute. Solana transactions are atomic, so an instruction that did not itself fault is rolled back when its transaction fails elsewhere. Read isCommitted for what landed and error for what faulted; they answer different questions.

For accurate analytics that distinction is the whole game. A swap-success rate, a measure of slippage pressure, or a count of contention during a volatile minute all depend on seeing the attempts, not just the wins. The data set keeps them, so an agent can answer "what was tried" as well as "what landed".

5. The boundary on balances

Solana datasets include balances and token_balances tables, and it is worth being precise about what they are. They are per-block change records: how a balance changed in a given block, not the standing balance of an account at a point in time. They are excellent for tracking flows and deltas. They are not a balance-at-slot lookup, and summing them into a point-in-time holding is a reconstruction you would do yourself. Treat them as movement data, in the same spirit as the rest of the Portal.

6. Why this is harder elsewhere

For the data model and finality background, read what is a Solana indexer. For the cross-machine query model, one query shape, every VM. To drive these queries from an agent, see AI agents and onchain data.