Research desks

A team that needs raw inputs for its own analysis can pull large transfers and market data from one API, and keep its own copy. Farbeam stores transfers for 7 days only, and it has no export. It does not produce conclusions, and a desk has to build its own dataset to study anything longer than a week.

#Workflow

Decide the scope, and write it down: chains, tokens and threshold. Check them against chain coverage and curated tokens.
Page through GET /transfers with min_usd, and use meta.next_cursor as before. Store rows in your own database, with uid as the unique key.
Repeat at least once a day, or the 7-day limit will remove rows you have not saved.
Record the GET /status values with each pull: measuring_since and the state of each chain. Gaps in coverage are part of your dataset.
Add market context from the stablecoin, DEX and pool endpoints. Save each response with its time, because these endpoints return only the current values or the source's own series.
Add rules for events that you want to read at once. Sign in to the console with a Solana wallet to save them.

#Grouping rows

Group rows in your own code. This is real output from a run at 2026-11-04T19:48:37Z, over 4,315 rows of $100,000 or more. The full table and the method are on Where large transfers land.

`to_type`	Rows	USD
No label	4,216	$3,365,777,357
`infrastructure`	41	$91,279,429
`exchange`	43	$39,845,404
`dex`	14	$5,018,809
`staking`	1	$608,587

#Rules

Each rule was tested with POST /rules/validate at 2026-11-04T19:49:01Z against the newest 2,000 stored rows, from 19:27:23Z to 19:48:31Z.

Rule	Purpose	Matches
`sampled == false and token in ["USDC","USDT","DAI"] and usd >= 10m`	Large stablecoin moves on fully read chains	16
`token in ["WBTC","cbBTC","BTCB"] and usd >= 1m`	Large wrapped BTC moves	2
`usd >= 5m and not from_type == "dex" and not to_type == "dex"`	Large moves with no labeled DEX on either side	28
`to_type == "exchange" and usd >= 1m`	Large moves to labeled exchanges	2
`chain == "solana"`	Any Solana row in the stored data	1

The counts come from about 21 minutes of data on one evening, so they do not show a typical rate. A rule with many matches also loses events to its cooldown, so use the transfer list as your record and use rules as a prompt to look.

#Fields to record

Field	Why you need it
`uid`	Unique per row, so repeated pulls do not duplicate data
`tx`	Groups the rows of one transaction
`ts`, `block`	The time and block of the transfer
`usd`	Value at the price held when the row was stored. It is not a settled price
`sampled`	True on Solana rows, which come from partial readers
`from_label`, `to_label`, `from_type`, `to_type`	Labels at the time of the pull. Save them, because the label set can change

#What it will not do

It will not give you history beyond 7 days. An archive and data exports are Planned, with no dates.
It will not give a complete view of any chain. The index has a threshold and a token list, Arbitrum scans part of its blocks, and Solana is read only in part.
It will not attribute unlabeled addresses. There is no clustering and no attribution graph. Planned
It will not give a verified volume figure. Rows can repeat the same money, as the warning above shows.
It will not make a claim about price. It gives data only and is not financial advice.
It has no SLA, so a desk must handle gaps and restarts in its own process.