ERC-8004 agent identity binding for solver-attributed execution

[kawacukennedy]

Hi — I'm building Kuberna Labs (https://github.com/kawacukennedy/kuberna-labs), a cross-chain intent execution SDK for ERC-8004 AI agents.

The OIF solver stack (ERC-7683 discovery, fill, settlement) is directly relevant. One gap we've identified in solver networks today: intent fulfillment is not attributable back to a specific agent identity. The solver fills the intent but there's no on-chain binding between the solver agent's ERC-8004 identity and the fill.

Proposal: When a solver fills an intent, the fill transaction should include an agentId (ERC-8004 tokenId) and a commitment signature from the solver's agent. This gives every fill a verifiable on-chain identity:

• Principals can verify which specific agent instance filled their intent
• Reputation accrues to the agent identity, not just the solver address
• Dispute resolution can check whether the solver agent had the right mandates

Is the OIF solver open to PRs adding an optional agentId / commitment field to the fill payload? I can put together a reference implementation in Rust that matches your crate structure.

[0xbrainkid]

This proposal gets stronger if the agentId binding is paired with a receipt that can be re-read after settlement, not only included in the fill payload.

A minimal shape could be:

• agentId / identity registry reference
• solver wallet that signs the fill
• intent id + fill tx hash
• result status / settlement status
• optional URI for richer execution evidence

That lets reputation accrue to the solver agent without forcing every consumer to trust an off-chain dashboard. In the AgentFolio/SATP model, this is the core distinction: an agent profile can display a trust score, but each claim should have a resolver and each job should leave a receipt. For an OIF solver, the fill tx is a natural anchor for that receipt.

[kawacukennedy]

@0xbrainkid The minimal receipt shape you proposed (agentId, solver wallet, intent id + fill tx hash, result status, optional URI for richer evidence) maps cleanly to our ERC-8004 adapter's settlement receipt. The fill tx hash as the natural anchor is the right choice — it's the one field every consumer can verify independently by reading the chain.

The AgentFolio/SATP distinction between a resolvable claim and a display score is worth emphasizing: our ERC-8004 registration anchor points to an off-chain identity document (DID or wallet-signed profile), not to a reputation score. The receipt chain on top is what reputation is derived from. An OIF solver that emits these receipts per fill gives any consumer the raw material to compute their own trust assessment without trusting a third-party scorer.

One practical question: does your receipt scheme anticipate multi-solver fills (where two solvers collaboratively fill one intent)? In our cross-chain escrow model, a fill can involve a primary solver and a liquidity provider on the destination chain. The receipt needs both participants' signatures. A single solver wallet field would miss the LP. We've been using a participants: address[] field instead.

[0xbrainkid]

Yes — for multi-solver fills I would avoid a single solverWallet field and make the receipt a parent envelope with participant entries.

A compact shape:

type SettlementReceipt = {
  intentId: string
  fillTxHash: string
  status: "pending" | "settled" | "disputed" | "failed"
  participants: Array<{
    agentId: string
    wallet: string
    role: "primary" | "route" | "liquidity" | "settlement" | "observer" | string
    contributionRef?: string
    signature: string
  }>
  evidenceUri?: string
}

The participant array preserves the independent signatures and lets reputation accrue at the right level. A primary solver, route finder, and liquidity provider should not all receive the same reputation delta just because they share one fill.

For AgentFolio/SATP-style evidence, the parent receipt is the durable object, and the profile/trust score is only an index over those receipts. That keeps ERC-8004 as discovery/registry, while the settlement path keeps the audit trail for who contributed what.

[kawacukennedy]

@0xbrainkid The parent-envelope + per-participant-receipts shape is the right model. The key design decision is that reputation accrues at the participant level, not the fill level — a route finder and a liquidity provider should not get the same reputation delta.

One refinement we've found useful in the Kuberna flow: the contributionRef field should distinguish between on-chain (tx hash) and off-chain (message hash, signed quote) references. A refType?: "tx" | "message" | "quote" on each participant entry lets the verifier know which namespace to check without guessing from the string format.

On the AgentFolio/SATP direction: the parent receipt as the durable object with the profile/trust score as an index over receipts is the same pattern we use. The ERC-8004 identity anchor should resolve to a list of receipt references, not a computed score — let consumers derive their own trust weight.