ERC-TBA: Agent Income Statements

[priors-agents]

An agent that sells over x402 is paid to its ERC-8004 agentWallet, and a lender or a buyer wants to know what it earns. This draft is a profile of the ERC-8004 Reputation Registry: a writer posts chained statements of what an agent’s agentWallet received in one asset, each incoming transfer a leaf of a Merkle root, under ERC-8004’s revenues tag (tag2 x402.statement; x402 payments are the motivating case, but the totals are gross receipts). Windows are cut at the logs of an owner or wallet change (the ERC-721 Transfer and MetadataSet("agentWallet")), so a reader can rebuild every figure from the token’s logs, and a contract can verify one transfer against a root. It is public by choice, as a statement a reader can check rather than a figure it has to trust.

• Repository (text, verifier, reference writer and checker, Foundry tests): GitHub - priors-agents/erc-agent-income-statements: Draft ERC: public, chained statements of what an agent's ERC-8004 agentWallet received, one leaf per transfer, rebuildable from token logs · GitHub
• It was raised first on ERC-8434’s thread (Agent Identity), whose author confirmed how the two fit: an AID Document can list a facet in its open namespace that points at the statements, and cumulative figures reach the Document through that facet, read as the latest statement per writer, never as a mean. The draft now says so.
• The reference implementation is not audited and must never be deployed without an external audit.

Questions for agent builders, lenders and indexers:

1. Is one statement per asset per window the right grain, or should a statement carry several assets of the same payer set?
2. The profile requires the registry to emit MetadataSet for every wallet change, which ERC-8004’s reference registry does and its text names only at registration. Should ERC-8004 say so for every change? ERC-8434 depends on the same event.
3. Who should be able to write: any writer a reader chooses to trust (as now), or should the draft name a default set, such as the agent’s own facilitator?

[Zealynx]

Really thorough draft, and cutting windows at the log position instead of the block is the detail most people would miss. On Q2, yes: I’d ask ERC-8004 to require MetadataSet on every agentWallet change, since without it a wallet set and unset inside one window can’t be seen, as your Security Considerations already say.

On Q3, plus two things from reading the reference:

1. Writers: I wouldn’t name a default set. A facilitator only sees the payments it settled, while a statement counts every transfer, so it has no data edge, and a full rebuild needs no trusted writer anyway. What readers are missing is which chain to read. The registry refuses the owner as a client, so the agent can’t write its own chain, but it could name one: a metadata key on the identity (say incomeWriter) set by the owner. Readers read that writer first, and planted entries from anyone else are skipped by default.

2. verifyPayment rejects three of the four excluded transfers (zero amount, mint, payTo to itself) but not the owner’s, because owner isn’t in the leaf. Owner top-ups are probably the most common transfer into an agent wallet that isn’t income, so a root that includes them still proves them as payments on chain. Putting owner in the leaf (it’s fixed per window) and checking payer != owner closes it.

3. payer is the log’s from. If settlement goes through an escrow, a batching contract or a fee splitter in front of payTo, every leaf has that contract as payer. The payer signals in Security Considerations then break both ways: an honest agent looks like it has one customer, and a self payer hides inside the contract’s flow. Worth a line telling readers to resolve known settlement contracts to the original payer, or to treat that payer as unknown.