DEV Community: AFG

The Binding Record: how we join an AI agent's identity to the money it moves (Research Note 01)

AFG — Sun, 27 Sep 2026 12:02:20 +0000

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.

We read every ERC-8004 "AI agent" on Base and joined it to its money. 1.2% have ever paid anyone.

AFG — Sun, 27 Sep 2026 10:57:37 +0000

There are 95,882 AI-agent identities registered on Base under ERC-8004. Ask how many of them have ever paid anyone, from a wallet you can prove is theirs, after the identity existed, for something that was not a routing hop, and the answer is 1,198. One in eighty.

We run Agentic Finance Graph, an independent public ledger of agent money. This post is the developer version of what we found when we moved from sampling the registry to reading all of it, and how you can check any agent yourself with one request.

The join nobody publishes

Every "agent economy" dashboard draws the same arrow: identity → wallet → payment. Registries count identities (mints). Payment rails count transfers. Nobody publishes the join between them, and the join is where every interesting claim lives. "This agent has paid for something" 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.

So we specified the join. A binding record is:

(agent_gid, wallet, bind_method, confidence, valid_from_block, valid_to_block, evidence[], superseded_by)

Methods are ranked, never averaged:

m	how the wallet is tied to the identity	confidence
5	wallet signs a challenge over the agent id + nonce	0.95
4	EIP-7702 / session policy that embeds the agent id	0.90
3	the registration declares a wallet and that wallet is the observed spender	0.70
1	`ownerOf(tokenId)` is the observed spender	0.55
0	name similarity, clustering	never a binding

Two rules make it a ledger instead of a snapshot: a binding is born, dies and can be superseded, never edited in place (when the NFT is resold, the binding is closed at that block and the new holder has to earn a new one); and every payment row references a binding_id, so attribution can be replayed at any block height.

What counts as a payment

A stablecoin transfer (USDC, USDT, EURC, DAI on Base) counts if:

the sender has a binding valid at that block,
the block is at or after the identity's mint block, and
the receipt does not show the money arriving and leaving the wallet in the same transaction (within 2%): that's a router hop, not a purchase.

Rule 2 sounds pedantic until you meet wallet #63877: it registered an identity on 18 August 2026 and had moved $34.6M in stablecoins before that date. Without the date rule, one identity would have added four times our entire counted total as "agent spending".

The partition of every dollar that left a bound wallet, as of 27 Sep 2026 10:00 UTC:

component	USD
counted payments	$8.8M
excluded: before the identity existed	$72.2M
excluded: routing hops	$17.8M
total	$98.8M

A naive total is 11× the honest one.

Where the counted money actually goes

We identified the recipients from verified contract source and from the transaction receipts of the largest transfers:

60% lending and vault adapters. The single largest recipient is a verified contract literally named Adapter whose NatSpec says it wraps Aave v3 and ERC-4626 deposits "so receivers are always bound to msg.sender", called by session keys. Agents parking their own cash at yield.
18% bridges. Across, Relay, LI.FI, a CCTP wrapper, and three unverified routers whose every sampled receipt forwards the full amount to the Across SpokePool in the same tx.
4.5% escrowed work (TermixEscrow: an order lifecycle with a dispute layer, in its own events).
1.5% swaps (Uniswap v3 / Aerodrome pools: USDC in, another token back).

The largest wallet is 28% of the total; the median payment is $48. So: the money registered agents control is mostly treasury management, not purchases. And only 5% of counted transfers are x402 micropayments; the wallets that buy APIs over HTTP and the identities registered under ERC-8004 are, so far, mostly different populations.

Check any agent yourself

Is this identity an economic actor?

curl -s "https://agenticfinancegraph.com/api/agents?q=53008" | jq '.ranked, .agent.liveness'

Its public record (bindings with their method, counterparties, 25 newest payments, float, incidents):

curl -s "https://agenticfinancegraph.com/api/agent?id=53008&format=json" | jq '.agent | {liveness, wallet, bindings, pay}'

The whole tape, every metric with a definition id and an as_of:

curl -s https://agenticfinancegraph.com/api/state | jq '.measured | {actors_l7_plus, observed_pay_usd_total, observed_pay_top_actor_share, observed_pay_usd_median}'

Every number resolves to a frozen definition that states what it does not assert:

curl -s https://agenticfinancegraph.com/api/def?id=rank.l7plus.v1

Agents can buy a dated evidence pack about a counterparty over x402, no account, $1 in USDC:

curl -i "https://agenticfinancegraph.com/check/liveness?id=53008"
# HTTP/1.1 402 Payment Required
# PAYMENT-REQUIRED: <base64 requirements: amount 1000000, USDC on eip155:8453, payTo ...>
# retry with PAYMENT-SIGNATURE (EIP-3009 authorization); the pack comes back with the receipt inside

And a badge you can embed that says exactly what the record says and nothing more:

<img src="https://agenticfinancegraph.com/badge/8004-base-53008.svg" alt="L9 · observed paying · Agentic Finance Graph">

What this does not assert

A binding is evidence of control, not of operation: the chain does not say whether a program or a person signs. A label describes what a contract does, never who runs it. A counted payment is a transfer, not proof it bought a good or a service. We publish those refusals next to every figure, and 37 assertion checks run against our own tables every three hours with their failing counts public. Every finding on the site is re-derived from the raw rows and matched in the transaction receipt before it is shown.

The full method, with the equations and six agents walked through by transaction, is in Research Note 01: The Binding Record (PDF, CC BY 4.0). The binding record spec is published to be copied; if you run an indexer and implement it, tell us what breaks.

We don't hold keys, move funds, or run a rail. We watch, and we count.