Data & Reliability

Market data is read from the public GeckoTerminal API (pool lists, single pools, OHLCV candles, search and token prices). No API key is used and nothing is written back. Portfolio balances are read directly from public JSON-RPC nodes on Robinhood Chain, Ethereum, Base and Arbitrum.

Robinhood Chain (primary), Ethereum, Base, Arbitrum and Solana for market intelligence. Robinhood Chain is Robinhood's Arbitrum-based L2 (chain id 4663), where markets are mostly quoted in USDG and include tokenized stocks; it is listed first everywhere and spotlighted on the dashboard. Portfolio intelligence covers the EVM chains; Solana wallets are not supported yet.

Each chain is fetched and cached independently, so one failing network never blanks the others. Every chain reports a health state: LIVE (fresh fetch succeeded), DEGRADED (serving the last successful fetch because the latest attempt failed) or UNAVAILABLE (no usable data at all). The global freshness badge in the top bar combines them and shows the age of the observation, for example 'Live · GeckoTerminal · Updated 42s ago'. Data older than ten minutes is shown as 'Data delayed' with the time of the last successful update; stale data is never labelled live.

• Upstream calls are spaced, retried with backoff and time-limited (12 seconds).
• A failed refresh keeps the previous snapshot for up to six hours and marks it cached.
• Every external response is validated at runtime before it is normalised; malformed pools are dropped.
• If no chain returns data the interface shows an explicit unavailable state with per-chain errors; no demo or estimated figures are substituted.

Pools enter the tracked set only when they show at least $1M liquidity, 500 swaps and 200 unique traders in 24 hours, and 24h volume no more than 25 times liquidity. Any pool on a supported network can still be opened directly by id.

Data Confidence measures the completeness and freshness of the observations used to calculate Cerin Signal. It does not measure investment certainty. It is a 0-100 score built from four factors: input coverage (0-40, share of the five Cerin components with usable inputs), observation age (0-30: 30 within 10 minutes, 20 within 30, 10 within 60), transaction sample (0-20: 20 at 1,000+ swaps in 24h, 10 at 200+) and price history (0-10 when at least 24 hourly candles are available). HIGH is 75 and above, MEDIUM 50 to 74, LOW below 50.

The insights block on a market page is generated by fixed, documented rules over the same observations (for example, a liquidity-to-volume relationship, buy/sell count balance or trader breadth compared with the tracked universe). Every insight names the rule that produced it. Insights describe the present; they are never predictions or recommendations.

Figures copied from the source are observed; figures computed by CerinFI are derived and documented.

• Observed: price, liquidity (reserves), volume windows, buy/sell counts, buyers/sellers, price change windows, candles, token balances.
• Derived: Cerin Signal and its components, Signal Confidence, condition and depth labels, turnover ratio, volume trend (second half of the range versus the first), buy/sell flow (count-based), market insights, portfolio weights and concentration.
• Not calculated: liquidity change over time (no liquidity history is available from the source; it is never inferred from volume), unavailable window buckets, and any missing value, which renders as '—'.

CerinFI records its own history: on a 5-minute schedule an ingestion run writes each tracked market's observation (price, liquidity, volume, transactions, raw turnover) and the Cerin Signal computed from it into PostgreSQL, tagged with the data quality of the fetch and the signal formula version (cerin-signal-v1). History begins when production collection started for a market. Nothing is backfilled, interpolated or estimated: until enough observations exist a market page shows 'Collecting historical data', and a deployment without a historical store attached says so explicitly.

• GeckoTerminal's public rate limit means a cold snapshot takes about a minute to build; the first visitor sees a labelled warming state.
• OHLCV history is limited to what the source exposes per range; very new pools may have few candles.
• Alert rules run only while the Alerts page is open; there is no background notification service yet.
• Search, watchlist, alerts and recent searches are stored in the browser, not in an account.