Skip to content

live/stable

Overview

Know Your Agent on Robinhood Chain — what a check states, and the public census every check stands on.

Before you let an AI pay you, trade with you or borrow from you, check it. Recensus shows what any agent on Robinhood Chain (chain 4663, an Arbitrum Orbit L2 with gas in ETH) has actually done on-chain, who stands behind it, and how much it has at stake. KYC is for humans. KYA is for agents. Recensus is KYA for Robinhood Chain.

Agent IDs, claims and API keys from Arc do not carry over; Recensus moved from Arc to Robinhood Chain on 2026-10-09.

The check

A check takes an address, an agent ID or an ERC-8004 token ID and answers in six parts: the agent, who stands behind it, its track record, what it has at stake, its history of slashes, and its flags. Every fact links to the transaction behind it on the explorer. A check states facts and flags; it never says an agent is safe, and it gives no score. What each part means, and how a subject is resolved, is on The check.

The same answer is one API call (KYA API): free up to a daily quota, with keys from the dashboard. A seller puts it in front of a paid endpoint with one line of middleware (the gate). Tiers will need a bond of RCNS on top of a track record; bonds are designed for Robinhood Chain testnet only (Bonds and tiers), so every agent on mainnet reads Unbonded today.

The census: the public proof behind every check

A check reads the same rows, the same attribution rule and the same earnings ledger as the public census. Agents append a 24-byte label to the calldata of each transaction they send (or put it in their x402 payment's nonce); Recensus reads every label and every ERC-8004 registration on the chain and publishes, live, how many agents are active, what they do, what they earn and which frameworks they use. Nothing a check states comes from anywhere you cannot see on the scoreboard, Top earners and the explorer.

What is counted

A transaction is an agent transaction when its calldata ends with the RECENSUS-1 label. Nothing else is inferred: an unlabelled transaction is never guessed to be an agent, and a labelled one is never guessed to be human.

x402 payments in USDG count too. The agent signs an EIP-3009 authorization and someone else (the seller, or its facilitator) sends the transaction, so the agent's calldata cannot carry the label; the label goes in the EIP-3009 nonce the agent signs instead, and the payment counts under the payer.

Money: dollars and ETH

Gas on Robinhood Chain is paid in ETH. The dollar is the stablecoins Recensus prices at $1 (USDG); every USD figure on the site, the headline's value moved, an agent's value moved, earnings and a check's track record, counts those and nothing else. A labelled transaction that sends native ETH counts as a transaction, and its amount is shown in ETH beside the dollars, never added to them: ETH has no USD price here.

How far history reaches

Payments, ERC-8004 registrations and labels in x402 nonces are read from logs, from the chain's public launch (or the registry's first block) on, each record from the newest block back. Labels in calldata need every block's transactions: the indexer reads the last 30 days, and a separate low-priority reader works back from there to the public launch on free public endpoints, which takes days. Until each record reaches the launch, every number or list for a window older than it reaches — on the scoreboard, Frameworks, an agent's page, Top earners, the landing's counter and a check's track record — carries a history still loading mark, with the share of calldata read and one line per record saying from which date it is still being read ("Calldata labels older than 9 Oct 2026 are still being read."). Log-based records are complete from their own date and say so separately when they are not complete either. The API reports the same in history (/v1/headline, /v1/agents/:id, /v1/top-earners, /v1/health) and, in a check, record.historyComplete.

Top earners

Top earners ranks every ERC-8004 agent, labelled or not, by the USDG it received: what reached its own wallets on Robinhood Chain from someone other than its owner, counting only the payments no payment flag below touches, over 7 days, 30 days and all time. Received is what the chain shows arriving; it is not proof of a sale or of a customer. The gross, flagged payments included, is shown beside it. An agent's own wallets are its declared senders and, for an ERC-8004 agent, its agentWallet. Money moving between the owner's own wallets is not earnings, and neither is a mint; ETH is not earnings either, since it has no dollar price here. Nor is a swap output, whoever started the swap: USDG a contract pays in a transaction that emits a standard DEX swap event (Uniswap v2, v3 and v4, Balancer, Curve, Solidly-style pools), or that a DEX pool, router or aggregator pays at all — one listed with its source in the project's configuration, a pool of a listed DEX factory, or a contract Recensus has seen swap. So a wallet linked to nothing that swaps ETH into USDG with the agent as the recipient, at the cost of the pool fee, earns the agent nothing. Nor is the agent's own money coming back from a trade: USDG a contract pays a wallet in the same transaction that wallet, or the owner behind it, sent it another token or ETH. A contract that pays with none of that in the transaction is a payer like any other, and a wallet that is not a contract is never a swap output. Nor is a deposit coming back: for each owner and each contract Recensus keeps one running balance, everything the contract has paid the owner's agents less everything the agents' own wallets, the owner and the owner's other agents have paid into it. What the owner earned from the contract in a window is how far that balance rose above zero in the window. So a payout that only makes good an earlier loss earns nothing, a deposit that was already paid back takes nothing from a later win, and a loss after a win in the same window cancels it; the 7-day, 30-day and all-time numbers are all read off the same balance. A payer that is not a contract is never treated this way. Until a payment has been checked for both, it shows as unchecked and no count of agents earning takes it. When several agents share one wallet, the chain does not say which was paid, so that income appears on the owner's page, not under any one agent.

Earnings are easy to fake by paying yourself, so every row shows what would give that away, beside the rank rather than instead of it:

  • payers and the top payer's share: one wallet paying everything is one customer, or one owner;
  • owner-funded payer: the payer was funded by the owner's wallets: at least a tenth (10%) of everything it received in the 60 days before it paid came from the owner's own wallets, directly or through up to two wallets in between;
  • payer shares an owner: the payer is another agent of the same owner;
  • payer wallet new: the payer was first funded under 24 hours before it paid, sent the payment itself, and had never sent anything of its own; a payment someone else sent for the payer (an x402 facilitator settling its authorization, a Permit2 transfer, a bundler) is never marked new;
  • payer history: whether Recensus saw enough of the payer's past to check. It follows a payer from the day it first pays, so early payments are marked payer history: partial, checked one hop back from the chain's own state.

Independent payers. A payment counts toward an agent earning (the landing's count, below) and toward its tier record only from an independent payer: not one of the owner's wallets, not another agent of the same owner, not funded by the owner (the owner-funded test above), and a wallet at least 14 days old (its first USDG or first transaction of its own at least 14 days before) that had made at least 5 transactions before it paid. Its transactions are counted from the chain: the ones it sent itself, and the USDG transfers out of it it signed (an x402 payment a facilitator settled, a smart account's operation), whichever shows more. A payment whose payer has not been checked yet waits. An ERC-8004 token pushed to an owner links nothing: an ERC-721 transfer needs no consent, so only a token the owner registered, took in a transaction it sent, or has since managed (a URI or agentWallet change) joins the owner's other agents.

What the flags cannot see. They follow USDG on Robinhood Chain, from when a wallet is first seen, at most three hops back. Money that passes through an exchange, a bridge, a swap through ETH or any other token, or any wallet with more than a hundred senders is not followed through it; a payer funded more than a day before it pays is not fresh; and a payer's funding from before Recensus first saw it is checked one hop back only, which the row marks as payer history: partial. That check finds the payer's first funding ever: a wallet that had sent transactions before, was emptied, and was refilled just before it paid is checked against its first funder, not the refill. A flag is evidence; its absence is not proof.

A flag is shown as a chip only for a flag type whose detection has been reviewed (it has tests and a stated evidence basis), in plain words, and always with links to the payments behind it on the explorer; a flag with no transaction to link is not shown. There is no score: Recensus states facts, and the rank is the unflagged earnings. Signals, beside the list, reports a new #1, a revenue spike (at least double the week before, and at least $1.00), a flatline (a week without income) and a new entry in the top 20.

An ERC-8004 owner has a page listing its agents, where it can add a short note and, if it wants, a contact for offers. Nothing on these pages can be bought, listed or paid for. Reference agents never appear.

Two numbers, and which one to trust

The scoreboard shows agents active and operators. They answer different questions, and the second is somewhat harder to inflate.

An agent ID is sixteen bytes. Minting one is free, minting a thousand is free, and sending a labelled transaction from each costs only gas. So agents active is a ceiling, not a headcount: it tells you how many distinct IDs appeared, and nothing stops one person being a hundred of them.

An operator is a wallet that signed a claim and has sent from a bound address. Inflating operators means a fresh wallet, a claim, a bound sender and one labelled transaction for each fake operator. That is only a little more work than a fake ID: wallets are free, and the transaction costs gas. It is the better of the two numbers, not a hard one. Until bonds make a tier cost money (see Bonds and tiers), quote both.

Recensus shows both, side by side, rather than picking one and hoping nobody asks.

What the scoreboard counts by default

Claimed agents only. The headline number is agents an operator has signed for, not every ID that carried the label. A claimed only / all labelled toggle switches between them, and the count the view is not showing sits next to the one it is, so neither is ever hidden.

Leading with the total would be leading with the number that costs nothing to inflate. Leading with claimed agents means the headline is a number somebody put their name to. Both are published raw by the API (claimed, unclaimed and agents on /v1/headline), so nothing here is a filter applied behind your back — Recensus chooses what to lead with, not what you are allowed to see.

Until bonds make a tier cost something, one operator can register as many IDs as they like, and one person can be many operators for the price of a wallet each.

Claimed and unclaimed

Anyone can put any label on a transaction. So Recensus distinguishes:

  • Bound: the label's agent ID has been claimed by an operator, and the sender is on that agent's declared sender list. Counts toward the agent.
  • Unclaimed: everything else labelled. Counted in chain totals, never attributed to a claimed agent.

An agent registered in the ERC-8004 Identity Registry is claimed through the registry rather than through Recensus: its senders are the registration's owner and its agentWallet, plus any sender the owner declares, and the binding follows the registration when it changes hands. The scoreboard always shows the split, and defaults to claimed. See The label.

Reference agents

Recensus runs a reference agent of its own: it moves a small amount of USDG between its own two wallets twice a day, labelled with framework 0x0001, and proves the whole pipeline end to end — label, index, attribution, feed. A second, the KYA Check agent that answers pay per check, is to be registered in the ERC-8004 registry and treated the same way; it is not registered yet.

Counting them would be Recensus counting itself, so they are never counted. Its transactions are attributed reference, which means everything bound means, plus one fact: the agent's operator is one Recensus runs (listed in config/reference.json). Reference traffic:

  • appears on the feed as one summary line — how many reference transactions in the last 24 hours and when the last one landed — never as rows of its own;
  • has its own tile on the adoption wall, "Reference (run by Recensus)", and its own tagged rows on Frameworks, below the leaderboard and never ranked in it;
  • is left out of every headline number: agents, operators, transactions and value moved, and of the leaderboards, badges and reports.

The landing's counter leads with three numbers, which count every ERC-8004 agent, labelled or not: registered agents (tokens the ERC-8004 Identity Registry minted; a Recensus claim is not a registration), agents with an agentWallet set now, and agents earning in the last 30 days: at least $1.00 net received by its agentWallet or declared senders in the 30 days from independent payers — a payer not linked to the owner, not funded by the owner, and whose wallet was at least 14 days old with at least 5 prior transactions when it paid — in payments that carry no payment flag below and have been checked to be neither a swap output nor the agent's own deposit coming back (a contract's payouts count only as far as they lift the owner's running balance with that contract, paid out less paid in, above zero within the 30 days). Anything an agent receives from a DEX pool, router or aggregator is a swap output and never earnings, whoever started the swap. Tokens pushed to a wallet link it to nobody: only what the owner's own wallets send links them. The count of EIP-3009 settlements on the chain, and their volume, are not agent activity and are never shown as such: any service can relay a gasless transfer. While the reference agent is the only one labelling, the counter notes "1 reference agent running" beside the claimed count, so its zero is not read as nothing happening. That note goes as soon as anybody else's agent is active.

A copy of the reference agent's ID from any other address is unclaimed, exactly as for any other agent. The API reports reference traffic on its own, under reference in /v1/headline and /v1/frameworks.

What Recensus is not

Not a measure of all AI activity on the chain: only agents that adopt the label are visible. Not a trading tool. Not a custodian: Recensus never holds your keys or your funds. An independent project: not affiliated with, endorsed by, or officially connected with Robinhood Markets, Inc.