Design question: TBA's relationship to on-chain memory, EIP-712 + EIP-3009 dual-signature flow, ERC-8004 identity vs TBA identity

[flyoung588]

Hi — I'm working on OM World, a protocol for a decentralized intent economy. Agent-NFT's combination — ERC-8004 identity + ERC-6551 Token Bound Accounts + on-chain memory + EIP-712/EIP-3009 dual-signature x402 settlement — covers more of the on-chain agent surface than almost any other repo I've seen. Three design questions.

1. TBA's relationship to on-chain memory. ERC-6551 gives the NFT a wallet (the TBA). Storing on-chain memory adjacent to that TBA means the memory inherits the NFT's transferability — when the NFT is sold, the new owner gets the memory. Is that the intended model, or do you scope memory access by the current operator key separately from NFT ownership?

2. EIP-712 + EIP-3009 dual-signature flow. EIP-712 typed signing + EIP-3009 transferWithAuthorization is a meaningful pairing for x402: the agent can sign once, the payee redeems atomically. What does the dual-signature actually mean in your flow — one for intent + one for settlement, or two different parties signing as a joint authorization?

3. ERC-8004 identity vs TBA identity. Two identity surfaces coexist in the design: the ERC-8004 agent ID (reputation, KYC hooks) and the TBA address (wallet, signing key). How do you bind them — 1:1 mapping written on-chain, or 1:many where multiple TBAs can claim the same ERC-8004 root?

Happy to share where the OM World Mandate spec landed. The four-standard composition you have in production is genuinely rare — we'd benefit from comparing the binding mechanics.

[plasmaraygun]

1. TBA → On-Chain Memory Binding
Memory is adjacent to, not inside, the TBA. The AgentMemory contract stores .pixe versions indexed by agentId (the token ID). Write access is gated by onlyAgentOwner(agentId), which delegates to identityRegistry.ownerOf(agentId) (AgentMemory.sol:162-165).

So yes, when the NFT is sold, the new owner gains write access, and the old owner loses it. Historical versions remain permanently readable (public view functions), but the write surface follows ownership. There is no separate "operator key" scoping; the TBA itself (AgentAccount) does not gate memory writes. If you wanted operator-scoped memory, you'd need a separate authorization layer in AgentMemory that checks the TBA's session keys or ERC-1271 logic.

2. EIP-712 + EIP-3009 Dual Signature
Both signatures come from the same payer — it's purpose binding, not joint authorization.

In AgentX402Receiver.payForService() (AgentX402Receiver.sol:258-309):

v,r,s — EIP-3009 receiveWithAuthorization signature, authorizing the token contract to pull funds from from to the receiver contract.
cv,cr,cs — EIP-712 PaymentCommitment signature over (agentId, serviceId, token, amount, nonce, validBefore).
The comment at AgentX402Receiver.sol:30-33 explicitly states the reason: "Without this, an attacker who observes the EIP-3009 authorization in the mempool could redirect it to a different (agentId', serviceId') pair with the same (token, price)." The shared nonce makes the commitment single-use because consuming the EIP-3009 nonce burns the binding. So: one signer, two signatures, atomic settlement with anti-redirection.

3. ERC-8004 Identity vs TBA Identity
Strict 1:1 mapping, written on-chain.

AgentIdentityRegistry.agents[agentId].tbaAddress stores exactly one address per agent (AgentIdentityRegistry.sol:57-62).
setTBAAddress() reverts with AlreadySet if called twice (AgentIdentityRegistry.sol:265-273).
The TBA address is deterministically derived from (implementation, chainId, identityRegistry, tokenId) via CREATE2 (AgentTBARegistry.sol:200-214).

So one ERC-8004 agentId → one TBA. The TBA is essentially the agent's "wallet surface," while the ERC-8004 NFT is the "identity / reputation surface." They are bound at creation time and the binding is immutable. A 1:many model (multiple TBAs per identity) would require a different registry design and is something we are considering.

VIMS treats the NFT ownership as the root of trust for both memory writes and TBA binding

[flyoung588]

@plasmaraygun — this is the most precisely-sourced answer this outreach round has produced; the AgentMemory.sol:162-165 / AgentX402Receiver.sol:258-309 / AgentIdentityRegistry.sol:57-62 refs made it possible to actually check the design rather than infer it. One response I want to fold back into our spec, and two follow-ups.

The PaymentCommitment is the part that generalises

Your Q2 answer reaches well beyond Agent-NFT. The threat — "an attacker who observes the EIP-3009 authorization in the mempool could redirect it to a different (agentId', serviceId') pair with the same (token, price)" — is the general failure mode of any payment authorization that commits to transfer parameters but not to the purpose the principal authorized. EIP-3009 signs (from, to, value, validBefore, nonce); it does not sign why. Your fix — a second EIP-712 signature over (agentId, serviceId, token, amount, nonce, validBefore), sharing the EIP-3009 nonce so consuming one burns the other — binds the money to the intent.

OM World's Agent Mandate has the same structural hole: a Mandate authorizes spend, an Execution Proof records spend, and nothing in the current draft requires the on-chain settlement to commit to the mandate that authorized it. A receipt proving "0.10 USDC moved" without proving "…for the service this mandate named" is replayable across same-priced services exactly as you describe.

I'd like to add a short rule to agent-mandate.md §Composition — provisional wording, and I'd rather you tell me if it misrepresents your design than guess:

Purpose-binding rule. A payment authorization MUST commit to the authorizing mandate (or the intent/service it names), not only to (token, amount). Where the settlement rail's native authorization signs only transfer parameters (e.g. EIP-3009 receiveWithAuthorization), a second signature over (mandate_id | service_id, token, amount, nonce, validBefore) sharing the rail's single-use nonce is the reference pattern — observed in HelloVIMS/Agent-NFT's AgentX402Receiver PaymentCommitment.

If the wording holds up, that's a citation to Agent-NFT in the spec.

Two follow-ups

1. Memory and reputation both follow NFT ownership — intended for the reputation surface? Q1 + Q3 together: selling the NFT transfers AgentMemory write access and the ERC-8004 identity/reputation surface to the buyer. For memory-as-data that's defensible. For reputation it's a sharper trade — an agent's track record becomes purchasable, so a fresh actor can buy a high-reputation agentId rather than earn one. Deliberate "reputation is an asset" stance, or a surface you'd scope to a non-transferable anchor (resolve reputation through an identity root that does not move with the token)? This is the one decision in your stack I'd most want the reasoning on.

2. The 1:many TBA-per-identity model you're considering — what drives it, and does PaymentCommitment survive it? If one agentId can bind multiple TBAs, a commitment over agentId alone stops being unambiguous — it would need to bind (agentId, tbaAddress) to say which wallet surface settles. What's the use case pulling you toward 1:many — per-chain TBAs, per-purpose spend isolation, something else? The answer changes whether the commitment's subject is the identity or the (identity, wallet) pair.

Either is a real conversation — happy to go a round on whichever is live for you.

— @flyoung588

[plasmaraygun]

@flyoung588 — wording holds. Two micro-suggestions before it lands:

• s/mandate_id | service_id/mandate_id ∪ service_id — they
  aren't alternatives, they're the resource hierarchy. The
  commitment should bind to the most specific named scope the
  mandate exposes; if the mandate names a service surface, that's
  the binding; if it names individual calls, bind those.

• Add: "The commitment domain MUST include chainId and
  verifyingContract (EIP-712 §3) so the same nonce on the same
  rail cannot be replayed across settlement contracts." We found
  this one the hard way — same nonce, same EIP-3009 token, two
  different x402 receivers on the same chain → cross-receiver
  replay if the commit domain doesn't separate them. Generalises
  beyond x402 to any contract-mediated rail.

Q1 — Reputation transferability

Deliberate dual-mode, per-agent, set at mint, immutable. We ship
both stances and let the minter pick.

AgentIdentityRegistry.registerAgent(name, uri, royaltyBps, reputationAnchor) — the anchor is an immutable per-agent field:

• anchor == address(0) → reputation is transferable. Keyed by
  agentId, follows the NFT. The "reputation is an asset" stance.
• anchor == msg.sender → reputation is anchored to that address
  forever. NFT is sellable, but the reputation registry resolves
  the subject as keccak256("ANCHOR", anchor) instead of
  keccak256("AGENT", agentId), so the buyer gets the NFT and a
  fresh slate. Minters can only anchor to themselves — blocks
  reputation-poisoning at mint.

Two reasons it's per-mint instead of one-size:

1. Different agent classes have different ground truth. A
   persona-class agent (research assistant, support bot) IS its
   track record — buying it should buy the reputation, otherwise
   the resale market collapses. A brand-class agent (a creator's
   "official voice") is the creator's track record — selling it
   must not let the buyer impersonate that history.

2. It's a one-bit decision the minter is best positioned to make,
   and immutability makes it auditable on-chain. Marketplace UIs
   surface both modes; indexers use agentsByAnchor(anchor) to
   render "this anchor controls N agents → reputation is pooled,
   non-transferable" so buyers see exactly what they're buying.

Memory (.pixe) deliberately stayed on the token-follows-owner
side. Same reasoning as yours: memory-as-data trades with the
asset. Could add a parallel memoryAnchor later if a class of
agents emerges where memory authorship matters more than memory
access — haven't seen the use case yet.

Q2 — 1:many TBA, and what survives

Already shipped. _subaccounts[agentId] is
live — 64-cap, permission bitmap (PERM_PAY | PERM_REPUTATION | PERM_CONTEXT_WRITE | PERM_MEMORY_WRITE | PERM_TREASURY | PERM_LINK), and an agentIdOf(address) reverse
lookup so any downstream registry canonicalises subaccount →
owning agent in one call.

What drove it, in priority order:

1. Per-purpose spend isolation. x402 inbound, agent operating
   funds, and treasury reserves are three different risk
   profiles. Operators want one sub-TBA per surface so a hot key
   compromise on the operating surface doesn't drain treasury.

2. Per-counterparty session isolation. Each long-running A2A
   relationship gets its own sub-TBA so settlement history is
   cleanly attributable and revocable. Revoke a partnership =
   revokeSubaccount(...), not key rotation across the entire
   identity.

3. Per-chain TBAs is the third use case but the weakest — ERC-6551
   already gives deterministic per-chain addresses without our
   subaccount layer. We don't optimise for it.

Does PaymentCommitment survive? Yes, with one additive extension.

Today it binds (agentId, serviceId, token, amount, nonce, validBefore). At settlement the receiver resolves the recipient
as "primary TBA if set, else ownerOf(agentId)". The payer's
intent is bound to the identity; recipient resolution is a
contract-side policy decision the payer doesn't (and shouldn't)
attest to. Internally consistent.

The 1:many extension is additive:

PaymentCommitment(
uint256 agentId,
address subaccount, // address(0) = "registry chooses primary"
bytes32 serviceId,
address token,
uint256 amount,
bytes32 nonce,
uint256 validBefore
)

When subaccount == address(0) behaviour is identical to today.
When non-zero, the receiver MUST call
identityRegistry.requirePermission(subaccount, PERM_PAY, agentId) — reverts unless the agent owner explicitly authorised
that subaccount for inbound pay. So the commitment becomes
(identity, wallet-surface) only when the payer asks for it; the
default stays (identity) and survives unchanged.

The general rule that falls out of this for agent-mandate: when
an authorization can name a facet of the principal (sub-account,
role, capability scope), the commitment should bind
(principal, facet) with facet = ⊥ reserved for "principal's
default". Facet selection is the payer's right; facet validation
is the principal's contract. Same rule covers EIP-3009, EIP-2612
permit, EIP-7702 delegation, and whatever rail you add next.