By dataset and dimension
| Dataset | completeness | uniqueness | validity | consistency | referential | freshness | volume |
|---|---|---|---|---|---|---|---|
partner_cursors | – | – | – | – | – | ✓ pass | – |
series_steps | – | – | – | ✓ pass | – | – | – |
money_events | ✓ pass | i note | ✓ pass | ✓ pass | ✓ pass | ✓ pass | ✓ pass |
snapshots | – | – | ✓ pass | i note | – | – | – |
registrations | – | – | ✓ pass | ✓ pass | – | – | – |
actors | – | – | ✓ pass | ✓ pass | – | – | – |
bindings | – | i note | ✓ pass | ✓ pass | ✓ pass | – | – |
series | ✓ pass | – | – | – | – | – | – |
acp_jobs | – | – | ✓ pass | ✓ pass | – | – | – |
bankr_launches | – | – | ✓ pass | ✓ pass | – | – | – |
partner_identities | – | – | – | ✓ pass | – | – | – |
x402_recipients | – | – | ✓ pass | – | – | – | – |
waitlist | – | – | ✓ pass | – | – | – | – |
Every check
| Check, and what it guards against | Dataset | Dimension · severity | State | Rows |
|---|---|---|---|---|
chain_lagAn other-chain registry watcher (Ethereum, Arbitrum, OP Mainnet, Polygon) is more than an hour of blocks behind the chain head, or has blocks it skipped and never scanned. Its mint and owner figures are partial until both are zero. Added 12 Oct 2026, when Arbitrum was about 113,000 blocks behind with a 1.2 million-block gap while health read 1.00. | partner_cursors | timeliness · warn | ✓ pass | 0 |
unexplained_stepOne of our own archived series stepped in the last 14 days (a material move concentrated in one day that persisted) and neither a dated change of ours in /api/changepoints nor a checked note explains it. Either we changed something without registering it, or the world moved and the move needs a dated note. Found by afg-steps: PELT (Killick, Fearnhead & Eckley 2012) over each daily series, confirmed by a one-day jump test; the list is at /api/steps. Added 12 Oct 2026. | series_steps | consistency · warn | ✓ pass | 0 |
me_required_fieldsA payment row is missing a field every downstream figure needs. | money_events | completeness · block | ✓ pass | 0 |
me_duplicate_logThe same on-chain log (transaction + log position) is stored twice, which double-counts it. | money_events | uniqueness · block | ✓ pass | 0 |
me_identical_in_one_txIdentical transfers inside one transaction. Usually a batch payment, not a duplicate: on 2026-09-24 all four counted groups were checked against their on-chain receipts and every one matched. Rows without a log position cannot be told apart from a double insert, which is why me_duplicate_log exists. | money_events | uniqueness · info | i note | 7,233 |
me_counted_without_log_indexCounted payments stored before log positions were recorded. me_duplicate_log cannot see them, so a double insert among them would reach the headline. Added 9 Oct 2026 (charter audit); the backfill re-reads their receipts. | money_events | uniqueness · warn | ✓ pass | 0 |
registry_count_vs_dailyThe cited all-chain registration total (agenteconomy.to) did not move while the same source's all-chain daily series reported new mints: one of the two is stale. Seen 30 Sep to 3 Oct 2026; added 9 Oct (charter audit) so a registration rate is never published from a stale total. Until 9 Oct 2026 15:30 UTC this compared the Base-only total with the all-chain daily series and fired falsely. | snapshots | consistency · warn | ✓ pass | 0 |
base_registrations_two_waysBase registrations measured two ways: our dated registrations table counted at the exact end of a UTC day differs from The Graph's Agent0 subgraph total for that day. Added 12 Oct 2026, when 9, 10 and 11 Oct agreed to the registration; a gap means one of the two indexers missed or double-counted a mint. | registrations | consistency · warn | ✓ pass | 0 |
base_registrations_cited_vs_ownThe Base registration total cited from agenteconomy.to and our own count from the Identity Registry contract differ by more than 1%. Informational: the cited figure is labelled as cited and the headline uses our own count (registrations_minted_total). On 9 Oct 2026 the cited total was 100,119 while the chain's newest agent id at 11:00 UTC was 99,013 (99,014 registrations), read both from public RPC and from our live mint feed. Added 9 Oct 2026. | snapshots | consistency · info | i note | 1 |
me_missing_log_indexPayments stored before log positions were recorded. They fill in as the payment scan re-reads each wallet; until then me_duplicate_log cannot see them. | money_events | completeness · info | ✓ pass | 0 |
me_amount_rangeA payment amount is negative or implausibly large for a single agent transfer. | money_events | validity · block | ✓ pass | 0 |
me_known_valuesA kind, rail, asset or confidence value appeared that no downstream code knows how to treat. Since 27 Sep 2026: PAY and EARN (income), four stablecoins. | money_events | validity · block | ✓ pass | 0 |
me_address_formatA sender or recipient is not a lowercase CAIP-10 address, so joins against it silently miss. | money_events | validity · block | ✓ pass | 0 |
me_counted_self_paymentA wallet paying itself is counted as spending. Moving your own money is not paying anybody. | money_events | consistency · block | ✓ pass | 0 |
me_pre_registration_leakA payment from BEFORE the agent was registered is counted. This exact leak once overstated the headline by 46%. | money_events | consistency · block | ✓ pass | 0 |
me_orphan_actorA payment points at an actor that does not exist. | money_events | referential · block | ✓ pass | 0 |
me_sender_never_boundA payment is attributed to an agent whose wallet was never bound to it, so the attribution has no basis. | money_events | referential · warn | ✓ pass | 0 |
me_pass_through_backlogCounted payments older than the backlog window have not been checked for pass-through routing yet. Pre-registration payments are excluded from every total already, so they never need checking (the first run flagged 3,313 of them by mistake). | money_events | freshness · warn | ✓ pass | 0 |
me_freshnessThe newest observed payment is older than the scan's own cadence allows: the payment scan may have stalled. | money_events | freshness · warn | ✓ pass | 0 |
me_volume_swingYesterday's number of newly recorded payments is far from the trailing 7-day median. Needs a week of history. | money_events | volume · info | ✓ pass | 0 |
actor_liveness_rangeA liveness level outside the L0–L9 ladder. | actors | validity · block | ✓ pass | 0 |
actor_rank_without_evidenceAn agent is ranked L7 or above with no countable payment behind it. The rank is the product; this is the check that protects it. | actors | consistency · block | ✓ pass | 0 |
actor_evidence_without_rankAn agent has a payment that qualifies for L7 under ladder v2 (counted, not inferred, left its control) but is still ranked below L7: a promotion is pending until the next rank run (afg-payer, every 3 h). | actors | consistency · warn | ✓ pass | 0 |
actor_rank_evidence_withdrawnAn agent ranked L7+ no longer has a payment that left its control (a position, own-address or bridged-back finding arrived after the last rank run). The next rank run (afg-payer, every 3 h) takes it down; a warning, so the gate does not stall publishing for up to three hours. | actors | consistency · warn | ✓ pass | 0 |
actor_unmeasured_l6An agent shows L6 without a probe that measured L6. Ladder v1 parked withdrawn ranks at L6; v2 never does. | actors | consistency · block | ✓ pass | 0 |
actor_l9_counterpartiesAn L9 agent does not have even three distinct counterparties in 30 days, measured as of the last rank computation (afg-payer, every 3 h). Ladder v2 (13 Oct 2026) asks more (three independent ones among payments that left its control), so this is a necessary condition that a correct rank always passes. Until 9 Oct 2026 the window ended now, so a counterparty ageing out between two rank runs failed the check until the next run demoted the agent. | actors | consistency · block | ✓ pass | 0 |
binding_orphan_actorA binding points at an actor that does not exist. | bindings | referential · block | ✓ pass | 0 |
binding_wallet_formatA bound wallet is not a lowercase CAIP-10 address. | bindings | validity · block | ✓ pass | 0 |
binding_intervalA binding closes before it opens. | bindings | consistency · block | ✓ pass | 0 |
binding_shared_walletOne wallet is currently bound to several identities: an operator wallet, not an agent wallet. | bindings | uniqueness · info | i note | 2,369 |
snapshot_not_finiteA published value is null, NaN or infinite. | snapshots | validity · block | ✓ pass | 0 |
snapshot_from_futureA published value claims a timestamp in the future. | snapshots | validity · block | ✓ pass | 0 |
snapshot_rate_out_of_rangeA published rate or share is below 0 or above 1. A negative share was once published live. | snapshots | validity · block | ✓ pass | 0 |
series_missing_definitionA metric was written in the last day without a definition id, so /def cannot explain it. | series | completeness · warn | ✓ pass | 0 |
acp_negative_amountAn ACP job has a negative amount. | acp_jobs | validity · block | ✓ pass | 0 |
acp_paid_exceeds_fundedAn ACP job paid out more than it was funded with (outside rounding). | acp_jobs | consistency · warn | ✓ pass | 0 |
bankr_address_formatA Bankr token, deployer or fee recipient is not a lowercase address. | bankr_launches | validity · block | ✓ pass | 0 |
bankr_fee_splitBankr's platform plus creator fee exceeds the total fee it reported for the same token. | bankr_launches | consistency · warn | ✓ pass | 0 |
bankr_negative_feeA cited Bankr fee is negative. | bankr_launches | validity · block | ✓ pass | 0 |
partner_shared_flagA wallet declared by several partner identities is not flagged as shared, so it could count as an agent wallet. | partner_identities | consistency · block | ✓ pass | 0 |
x402_address_formatA named x402 seller is not a lowercase address, so payments to it are never attributed. | x402_recipients | validity · block | ✓ pass | 0 |
cursor_stalledA worker that pages through a source has not saved a new position for several of its own cycles, so whatever it feeds has quietly stopped updating. | partner_cursors | freshness · warn | ✓ pass | 0 |
catalogue_full_passThe x402 harvest has not completed a full pass of the catalogue within the window. This is the page-one freeze of September 2026, caught by the machine instead of by a reader. | partner_cursors | freshness · warn | ✓ pass | 0 |
registration_from_futureA registration claims to have been minted in the future. | registrations | validity · block | ✓ pass | 0 |
waitlist_email_formatA waitlist entry does not look like an email address. Only a hash is returned: this table holds personal data. | waitlist | validity · warn | ✓ pass | 0 |
How the health score is computed
A weighted pass rate over the block and warn checks. Each check weighs its dataset's importance (the tables the public rank is built from count 3, published snapshots and paging workers 2, partner and catalogue tables 1) times its severity (block 2, warn 1). Informational checks never move the score. A score of 1 means every check that could make a public number wrong passed on the latest run.
Why this page exists
Every serious correction this project has published was a data-shape error that a person noticed by eye: a share that went negative, routing hops counted as spending, a wallet's history from before its agent existed counted as the agent's spending, and a seller list that stayed frozen at page one for eleven days while every run reported success. Each of those is now a named check on this page, so the next one is found by a machine, not by a reader.
Questions people actually ask
How often are Agentic Finance Graph's data checks run?
Every three hours, on a timer on our own server. Each run stores its results and publishes them at /api/dq, and this page re-reads that document every time it is opened.
What happens when a data check fails?
A block-severity failure means a published number would be wrong, so that number should be withheld until the check passes. A warn failure means data is late or drifting. Info notes never change a public number.
Can I see the rows that failed?
Yes. /api/dq lists every check with up to five sample failing keys. For the one table that holds personal data, the waitlist, it shows only a hash, never an email address.