PRAI (Privasea AI) — the network, measured

Generated 2026-09-03T23:08:47Z from live ClickHouse queries against this estate's ledger. Held inventory: 8,031 observations · 29 distinct series · 3 upstream sources · first row 2026-08-09 17:15:20 · newest row 2026-09-03 22:47:01 · 8,031/8,031 rows carry a verify_url. 29 series refreshed in the last 24h (608 fresh rows). Nothing on this page is cached, estimated, or remembered.

Provenance — where every number comes from

3 source families feed this network's ledger. Every row they wrote carries its own source, as_of and verify_url; this table is the live rollup of that.

30-day history — headline series (daily last-value, live)

One row per series: latest value, a 30-day sparkline of daily last-known values (scaled to the series' own min→max), day count, and window change. Series absent from the 30-day window are omitted from this table, not zero-filled. A flat sparkline is a real flat series — for the CoinGecko circulating rows it is also the freeze.

Market reference — CoinGecko coin page, as held

Market-data reference rows: price, supply, capitalisation, diluted valuation, and the published change columns including ATH/ATL. These are the coin-page reference's own numbers — the estate does not model, smooth, or forward-fill them. The change columns / rank / ATH-ATL / high-low series start later in the archive than the price rows (each metric's caveat in the full inventory states its own first-held row) and are shown from their first held row. The circulating row is the FROZEN reference documented below and is a different quantity from every chain-side read on this page — never netted against them. The token trades far below one cent (near $0.00052); the sub-cent cells are rendered to full precision so no published value rounds onto a different one.

First-party chain state — BSC RPC, as held

Read THIS collector's run straight off BNB Smart Chain nodes via eth_call against the token contract 0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73 (the catalog's own token_address field, verbatim — catalog chains field: binance-smart-chain). No aggregator between us and the chain; a reverting or empty call is skipped, never zero-filled. At generation: first-party total supply 1,000,000,000. The burn read is the 0x...dEaD sink only — an effective-supply input, not "total burned".

Deep supply — BSC deep-stats collector, as held

A second, independent collector polls the same contract hourly via BSC JSON-RPC and writes three series: bsc_total_supply (eth_call totalSupply(), 1,000,000,000 at generation) and bsc_burn_address_balance (eth_call balanceOf(0x...dEaD)), plus bsc_circulating_supply which is COMPUTED as the two (999,999,849.5333). Metric names are deliberately distinct from the bsc_rpc family so exactly one writer per (symbol, metric) pair and the two collectors' freshness identities stay untouched. The deep-stats series agree with the first-party reads by construction — they read the same contract through the same selectors. The computed circulating figure is the chain-side effective supply: the tokens that exist minus the dEaD-sink balance, before any other lockup, vesting, or sink — not an independent circulating-supply measurement.

Frozen circulation — the two supply references side by side

This network serves two mutually exclusive circulating-supply records, and one of them is frozen. The table below is the live pin census from this ledger at generation: pin count, distinct values, and span. CoinGecko's circulating_supply has answered with one byte-identical value on every pin of the series' life, while the chain-side deep-stats read answers bsc_circulating_supply from eth_call arithmetic on the same contract. We cannot adjudicate which is "true" from this estate alone (the aggregator may exclude locked or vested tokens; we cannot verify that from here). Both are published exactly as their endpoints serve them, side by side, never reconciled, never merged, no ratio derived. Disclosed in the estate's findings ledger 2026-09-03 (batch119) with a live chain re-verification.

Full metric inventory — 29 measured series, each with provenance

Every series held for PRAI with rows in the last 30 days: latest value, when it was observed, which source observed it, how many rows we hold, how many of the last 30 days it reported, its comparability grade, and the origin link. "days/30" counts distinct dates with at least one row in the window.

Revision ledger — 0 backward revision(s) recorded for PRAI

Backward revisions are values upstream later replaced for a date we had already archived. The before-value is retained — that retention is the only reason a rewrite is detectable, and it is the part every overwriting vendor discards.

The ledger query ran during generation and returned 0 rows for PRAI. Zero here is the live query result, not a gap — the ledger itself is at /v1/revisions.

Estate grades for PRAI (graded 2026-08-20 13:54:15.000)

Served by /v1/network/PRAI — the same grades a paying agent receives. Scores are the engines' own 0–100 outputs, not ours to smooth. They are published exactly as the engines emitted them, unflattering parts included: the revenue F reflects that the estate holds no fees/revenue series for this network (the absence is shown in the sections above, not papered over), the data-coverage F reflects a thin measured-series set relative to first-party-telemetry networks, and the ELEVATED dilution grade is the engines' own call on the supply record. The node-quality and dev-velocity A grades are the engines' outputs on the series the estate holds. The grade stamp is dated; the engines re-grade on their own schedule.

Verify any cell yourself — the exact commands

No account, no key, no trust required. Commands 1–1c hit the same public BSC node our first-party collector does (eth_call against the token contract — the exact selector bytes the collector sends); command 2 hits the CoinGecko programmatic markets endpoint (the coingecko.com browser coin page 403s plain curl, so the programmatic endpoint is given); command 3 hits this estate's public API, where every row carries the same source / as_of / verify_url fields. One polite call per endpoint, no hammering.

# 1) FIRST-PARTY chain state (the collector's own method — eth_call against
#    the PRAI token contract on a public BSC node), as of 2026-09-03T23:08:47Z:
curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73","data":"0x18160ddd"},"latest"]}' "https://bsc-dataseed.binance.org" | python3 -c "import json,sys; d=json.load(sys.stdin); print('raw_totalSupply_hex', d.get('result'))"
# (decimals() selector 0x313ce567 returns 18 for this contract; the raw
#  hex above divides by 10**18 to give the decimal-adjusted supply)
# 1b) The dEaD-sink balance the same way (balanceOf(0x000...dEaD)):
curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{"to":"0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73","data":"0x70a08231000000000000000000000000000000000000000000000000000000000000dead".lower()},"latest"]}' "https://bsc-dataseed.binance.org" | python3 -c "import json,sys; d=json.load(sys.stdin); print('raw_dead_balance_hex', d.get('result'))"
# 1c) The token pages our verify_urls point at (human view):
curl -s -o /dev/null -w "%{http_code}\n" "https://bscscan.com/token/0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73"
curl -s -o /dev/null -w "%{http_code}\n" "https://bscscan.com/token/0x899357e54c2c4b014ea50a9a7bf140ba6df2ec73?a=0x000000000000000000000000000000000000dead"
# 2) Market reference (CoinGecko public API):
# CoinGecko public markets API (the endpoint family our collector
# reads for the price/supply/cap rows) — the coingecko.com browser
# coin page 403s plain curl, so the programmatic endpoint is given:
curl -s "https://api.coingecko.com/api/v3/coins/markets?vs_currency=usd&ids=privasea-ai" | python3 -m json.tool
# 3) This estate's public API row for PRAI:
curl -s "https://kairossignal.com/v1/network/PRAI" | python3 -m json.tool | head -60
#    (This estate endpoint is keyed: anonymous IPs share a 1,000/day pool that
#    resets at 00:00 UTC. If you see a quota-exceeded JSON, self-register
#    free credits at https://kairossignal.com/v1/credits/register and add
#    -H "Authorization: Bearer *** key>".)

Method & honesty notes. All counts are queries against the live ledger at generation time, not restamped copy — this page is regenerated by gen_deep_dive_prai.py and the hourly claim_drift_check.py run grades its claims against the live API like every other published surface. Comparability grades come from the served canonical-metric system via its own resolver: total_supply maps to token_supply_total (question-verified). The remaining series are PRAI-native market/on-chain metrics with no cross-network concept; grading them would be fabrication, so they are labelled "prai-native (unmapped)". THREE supply references are shown side by side as held, never summed, merged, or reconciled: CoinGecko's circulating, total and max supply (total and max equal the 1,000,000,000 cap), the first-party chain-side onchain_total_supply, and the deep-stats bsc_total_supply. The two chain-side families read the same contract (1,000,000,000 at generation) through the same selectors from separate collectors — they agree by construction, are published as separate rows so each keeps its own freshness identity, and no ratio is derived between any of them. The CoinGecko circulating row is FROZEN — it has served one byte-identical value on every pin since 2026-08-09 while the chain-side computed read answers ~999.9998M on the same contract; one of the two circulating numbers is wrong by ~4.85x and this estate cannot tell which from its own data. The discrepancy is documented in the estate's findings ledger (batch119, 2026-09-03, with a live BSC RPC re-verification) and is disclosed here rather than reconciled away. The bsc_circulating_supply series is COMPUTED (totalSupply minus the dEaD-sink balance) — an effective-supply read, not an independent circulating measurement; other lockups/vesting make true circulating supply differ. The dEaD-sink balances (onchain_burn_address_balance, bsc_burn_address_balance) are balanceOf(0x000...dEaD) on the token contract only — an ownership-supply INPUT, never relabelled as "total burned" (projects burn via other sinks or supply reduction), never presented as investment advice, and a genuinely-zero reading is a measured "nothing burned to this sink", not a gap. The deep-stats family also contains an unflagged 6-day collection hole (2026-08-25T22:47Z → 2026-08-31T23:24Z, through which ~150 tokens moved to the dEaD sink) — disclosed, not back-filled; the series is shown as held. The estate holds no GitHub, no DefiLlama slice, no Blockscout v2 rows (BSC has no public no-key instance), and no first-party node telemetry beyond the chain reads for PRAI — those sections are absent rather than zero-filled, and the queries rerun at every regeneration. Where a section has no data, it is absent — we do not publish zeros for gaps. Upstream probes ran serially by this generator immediately before rendering: CoinGecko markets API (privasea-ai) HTTP 200; BscScan token page (PRAI contract) HTTP 403; BSC RPC node (bsc-dataseed) HTTP 200; estate /v1/network/PRAI HTTP 200.