Platform

Farbeam is one Node process with one SQLite file. It polls seven chains, stores large transfers for 7 days, answers lookups over a public REST API, and matches new transfers against alert rules. This page explains how those parts connect and where each one stops.

The numbers on this page come from the source code and from calls to the running API at 2026-11-04T19:20:48Z. Check the current state on the status page.

#Data flow

Two kinds of data use this flow. Index data, such as transfers, comes from the store and was collected earlier. Lookup data, such as a wallet balance or a token report, is read from public sources when you ask for it.

#Chain pollers

Each chain has its own loop, so a failure on one chain does not stop another. After a failed poll the next poll waits for twice the normal interval, capped at 60 seconds. EVM chains use free public endpoints from dRPC, 1RPC, Nodies, BlockRazor, Arbitrum and PublicNode, tried in order. Solana uses Helius when it is configured, with PublicNode as the other endpoint. Background polling on Solana prefers the public endpoint, and the keyed endpoint has a daily credit budget.

#EVM log scan

An EVM poll asks for ERC-20 Transfer logs of the curated tokens from the last scanned block to the head. One poll reads at most 200 blocks. If the chain moved further, the next poll continues from the cursor, so no block is skipped unless the reader falls more than 2,000 blocks behind. Native ETH transfers are read from the latest block of each poll, and Farbeam checks the receipt, so a reverted call is not stored.

The scan position lives in memory. After a process restart the scan starts again at the head. Transfers that happened during the restart are not backfilled.

#Native ETH

Native ETH is read from the head block body on Ethereum only. It covers the top-level value of each transaction. It does not cover internal transfers from contracts, and it does not read receipts, so a reverted transaction with a large value can appear. When two blocks pass between polls, the block that was not the head is not read for native ETH.

#Solana sampling

Solana is too busy to read in full with this design. It has two partial readers, and every Solana event has sampled: true from either one.

• Sampled blocks. Each poll reads one finalized block. In the sample there were 148 slots between reads, or about 32 seconds.
• Wallet watch list. About every 2 minutes, the service reads recent transactions of the Solana exchange wallets in the label set, 7 addresses at this time. It reads up to 20 signatures and at most 6 transactions per wallet in each pass, on the public endpoint. A busy wallet can do more than that between passes, so this reader also misses transfers. GET /status reports the list and its counters under watch_list.

For each successful transaction, the poller sums balance changes per owner and mint. The largest decrease becomes from, the largest increase becomes to, and the amount is the smaller of the two. SOL uses the same method on lamport balances. This finds large balance changes. It is not a decoded transfer list, and it misses most of Solana by design. Do not sum Solana rows and call the result a volume. See sampling.

#Valuation and timestamps

usd is the amount times the CoinGecko price at the moment of indexing. The value does not change later. On EVM log events, ts is estimated from the head block time and a configured block time, so it can be off by some seconds. Exact times come from transaction lookup.

#Chain health

GET /status reports one state per chain. These rules come directly from the poller.

#Store

The store is one SQLite file in WAL mode. This design is simple to run and has limits: one process, one writer, no replicas and no archive.

The transfer uid is unique, so a repeated poll cannot store the same event twice. See indexing for the row format.

#API

The Data API has about 40 documented endpoints. It costs nothing to read, and reading needs no sign-up. Limits use fixed one-minute windows, plus a daily limit per key. See rate limits.

Lookups go through one upstream client with timeouts, an in-memory cache and single-flight, so equal requests share one outbound call. The cache times are short enough that you should expect different numbers between calls.

When a source fails, the service does not fill the gap with a guess. A token check reads unknown, and a wallet chain reads ok: false. If every source fails for a wallet, token report, stablecoin or DEX call, the API returns the last saved copy with stale: true and its as_of time. With no saved copy it returns 502 upstream_unavailable with the source name. The full list is on data sources.

#Tools

The browser tools are thin clients over the same API. They hold no extra data, so anything you see in a tool is also available as JSON.

Market pages show aggregator data with the source named: stablecoins and DEX volume from DefiLlama, trending pools from GeckoTerminal.

#Alert engine

The engine subscribes to new transfer events. Each enabled rule is a compiled Beamline expression, and it runs once per new event. After a rule fires, it waits for its cooldown, 300 seconds by default, and matches in that time are dropped. A match writes a delivery row to SQLite. A worker runs every 3 seconds and sends up to 20 due deliveries per pass, so pending deliveries survive a restart.

A rule that names liquidity_usd or change_pct watches liquidity samples instead of transfers. While such a rule exists, the engine samples DexScreener liquidity of curated tokens every 5 minutes, skipping stablecoins and wrapped native assets.

The engine sees only what the index stores. A rule cannot match a transfer below $100,000, or a token outside the curated list. See Alerts for the delivery guarantees.

#Accounts

Reading data needs no account. An API key, a rule and the console need sign-in with a Solana wallet. The wallet signs a text message, which sends no transaction and costs nothing. The server then sets a session cookie for 7 days. See Security for how sessions and key hashes are stored.

#Status

Status shows measured state from this service: chain head, lag, RPC latency and the result of each outbound source. The service does not publish an uptime percentage. It stores samples and shows them.

#Not built yet

These items do not exist today. The list is here so you do not plan around them.

The roadmap gives more detail. Items on it have no dates.