Yesterday's post (we read every ERC-8004 "AI agent" on Base and joined it to its money) got the right question back several times: how do you know a wallet belongs to an agent?
Research Note 01 is the written answer, with the definitions, the equations and the failure cases. PDF, CC BY 4.0: The Binding Record (21 pages). This post is the short version.
Why the join matters
There are four public facts about any AI agent that has money: an identity (a token in a registry), a wallet, a payment, and the pattern payments make over time. Registries publish how many identities were minted. Payment scanners publish how many dollars moved over a rail. Nobody publishes the join between them, and every interesting claim lives in that join.
"This agent has paid for something" is not a claim about a token. It is a claim about a wallet, made on behalf of a token, and it is only as good as the evidence that the wallet spends for that token. A registration count is a count of names.
The binding record
A binding record is a versioned, evidence-ranked join from an identity a to the wallet w that spends for it:
β = (a, w, m, c, [h_from, h_to), E, σ)
m is the method that proved the join; c = κ(m) a confidence that is a function of the method, never a blend; [h_from, h_to) the block interval in which the binding is valid; E the evidence (a transaction hash, a signed message, a registration file with its content hash, each with the time it was observed); σ a pointer to the binding that superseded this one.
Two rules turn it from a snapshot into a ledger. A binding is born, closed or superseded, never edited in place. And every row that records money references a binding. So for any block height h, the wallet attributed to an identity is the binding valid at h, and attribution can be replayed at any past height. The answer does not change because a token was later sold.
Methods are ranked, never averaged
A confidence that blends a cryptographic signature with a guess is worse than no score, because it hides which of the two you are holding.
| m | Method | κ(m) | Forgeability | On Base, 27 Sep 2026 |
|---|---|---|---|---|
| 5 | The wallet signs a challenge over the agent's global id and a nonce | 0.95 | Hard: requires the key | Offered through the Desk |
| 4 | An EIP-7702 authorization or session policy whose signed payload embeds the agent id | 0.90 | Hard | Specified |
| 3 | The registration declares its wallet and that wallet is the observed spender | 0.70 | Medium: a declaration can be copied, but the spender must match | 307 open bindings |
| 2 | A wallet declared only in a URI-hosted file that can change after the fact | 0.45 | Easy | Reserved; never ranks |
| 1 | The registration's holder (ownerOf) is the observed spender |
0.55 | Medium: a holder can hold many things | 95,527 open bindings |
| 0 | Name similarity, shared funders, shared implementations | 0 | Trivial | Never a binding; a cluster hint |
Method 3 sits above method 1 on purpose. A declared wallet that is also the observed spender has passed two tests, the declaration and the behaviour; holding is one test that a factory address passes for thousands of identities at once. Method 1 is still a binding, because on this registry the holder is, overwhelmingly, the only wallet the identity has. The record says which method bound it, and so does the public rank, so a reader can discount as they see fit.
What the record refuses to say
A binding is evidence of control, not of operation. It does not say that a program rather than a person signs the transactions. It does not say who deployed or runs a wallet's controller contract. It does not say a payment was for a good or a service. Those are separate claims needing separate evidence, and a does_not_assert list travels with every figure derived from the record.
From a binding to a counted payment
Take the ERC-20 Transfer events of four stablecoins on Base (USDC, USDT, EURC, DAI). A transfer is counted when all four hold:
- it comes from a wallet with a binding valid at that block;
- it is dated at or after the identity's mint. A wallet may have had a long life before someone minted an identity into it, and that life is not the agent's;
- the recipient is not the sender;
- it is not a hop. From the transaction receipt: if stablecoin value both entered and left the sending wallet inside the same transaction, and the two amounts are within 2% of each other, that is a router doing its job, not an agent buying anything.
The two exclusions are published beside the total, so that everything that left bound wallets equals counted + pre-registration + hops, to the dollar.
What the census shows
Figures as of 27 September 2026, 11:52 UTC; every one of them is live on the site with its definition.
- 95,882 identities held by 48,822 wallets; 1,198 have been observed paying a different address after the identity existed (1 in 80).
- Excluded: $72.22M moved before the identity was minted; $18.08M of routing hops.
- Counted: $9.07M to 955 recipients. Identifying those recipients from verified contract source: 59% is agents' own cash entering lending protocols and vaults through policy adapters, 18% leaves the chain through bridges, 4.4% buys work through an escrow.
- The largest wallet alone is 27% of the counted total and the median payment is $54.41. That is why the total is never published alone.
- One of the six worked examples in the note: a wallet with $34.57M of pre-registration history that would otherwise have been reported as agent spending.
What attacks the join
- Shared wallets. 11,877 wallets hold more than one identity; one holds 8,313. Each transfer is counted once, identities are clustered by holder, and only a signed challenge (method 5) can separate them.
- Resold identities. 20.6% have changed hands. The binding is closed at the transfer block; a bought identity inherits no payment history and a stolen one does not carry its victim's rank. The closure rule applies to transfers observed after a binding exists (the census bound current holders, so earlier resales are visible only in the resale count).
- Pre-registration history. 926 identities sit in wallets that moved $72.22M before the mint. The date rule handles the past; it cannot handle a wallet that keeps a non-agent life after the mint, which is why the top-wallet share and the median always travel with the total.
- Hops and wash loops. The receipt test catches money that passes through in one transaction. It does not catch a loop over two transactions; a multi-transaction loop detector is the next check.
- Declared wallets. A registration file can declare anyone's wallet. It binds only when the declared wallet is also the observed spender.
Reproduce it
Every figure resolves to a public metric identifier and a value at the stated time: the binding record specification, the definitions, the live tape and the ranked agents. Corrections go out as new versions; the earlier PDFs stay online.
Cite as: Agentic Finance Graph (2026). The Binding Record: how we join an AI agent's identity to the money it moves. Research Note 01, v2.1, 27 September 2026.
Disclosure: the measurements are the ledger's own, read from the chain. The pipeline, the analysis code and the drafting were done with AI assistance under the author's direction, and the author verified every figure.
Top comments (0)