Sampling

Solana rows carry sampled: true. It means Farbeam read only part of the chain: one finalized block out of many, plus a short list of exchange wallets. Anything else is absent. The Solana index is not complete, and it is not close to complete.

#How the sample is taken

Once per poll, the service does this:

1. Calls getSlot with finalized commitment.
2. Calls getBlock for that slot. If the RPC returns an error, it tries up to three older slots.
3. Scans the transactions in that one block for large balance changes in the curated Solana tokens and SOL.
4. Waits 30 seconds and repeats.

There is no attempt to pick interesting blocks. The slot read is the one that was latest when the poll ran.

#The exchange watch list

A second loop reads 7 public exchange wallets, listed in watch_list.wallets from Status.

A busy exchange wallet has more than 6 transactions in 2 minutes, so this list is partial as well. Its rows have sampled: true, and nothing separates them from block sample rows. watch_list also reports last_run, last_ok, transactions_read and failures.

#Measured block sample rate

On 2026-11-04 UTC, the last 25 sampled slots read as follows.

Solana row counts stay low because of this. In the first 27 minutes of data held on 2026-11-04 UTC, the service stored 2 Solana rows, both from one transaction, against 689 Ethereum rows. This count is from before the watch list was added. The gap reflects the method and not the activity of the chains.

#Why it works this way

A Solana block holds hundreds of transactions and arrives many times a minute. On that capture, one block held 513 transactions. Reading each block needs a dedicated data pipeline with far more RPC capacity than a poll loop has. The service reads one block per poll so that the sample is real data at a known cost, and it marks every row.

A complete Solana index is not built. It would need another design, such as a Geyser feed or a dedicated indexer. It is not on the planned list, so do not assume it will arrive.

#What you can use sampled rows for

#How to treat them in code

Filter them out of totals. All of these work.

curl -s "https://farbeamlabs.com/api/v1/transfers?limit=100" | jq '[.data[] | select(.sampled | not)] | map(.usd) | add'

const res = await fetch("https://farbeamlabs.com/api/v1/transfers?limit=100");
const { data } = await res.json();
const total = data.filter((row) => !row.sampled).reduce((sum, row) => sum + row.usd, 0);
console.log(total);

import requests

rows = requests.get("https://farbeamlabs.com/api/v1/transfers?limit=100", timeout=30).json()["data"]
print(sum(r["usd"] for r in rows if not r["sampled"]))

In a Beamline rule, add not sampled to exclude Solana rows.

usd >= 1m and not sampled

#Sampling and the EVM chains

sampled marks a method: partial reading on Solana. Arbitrum rows carry sampled: false, because the poller reads a continuous range of blocks. When you need a list of chains you can treat as near complete for curated tokens, use Ethereum, Base, BNB Chain and Arbitrum. Those have their own limits, which indexing lists.

#Double rows on Solana

The native SOL scan and the wSOL scan run separately. A transaction that wraps or unwraps SOL can give both a SOL row and a wSOL row for the same value. The two rows captured on 2026-11-04 UTC are an example: transaction CthHnYm1pCm1…espRaCx produced both, at $679,207 each. When you count value, group by tx first.

#What is not sampled on Solana

Direct lookups read the chain and do not depend on the sample. Wallet overview, Wallet activity, Token report and Transaction lookup work for any Solana address or signature the RPC can serve.