Agent trust for AP2 - on-chain identity (ERC-8004) + conditional commerce escrow (ERC-8183), live on Arc with x402 settlement

[abdelmouss63-cyber]

Hi AP2 team and community 👋

We're Meridian / Firmata - building Arc-native USDC stablecoin settlement and on-chain agent trust on Circle's Arc Network: ERC-8004 (agent identity, reputation, validation) and ERC-8183 (conditional commerce / escrow). We've been building in public on Arc since day one of its testnet, and AP2's mandate model (Intent → Cart → Payment) is the cleanest articulation we've seen of
proving a user authorized a specific purchase. Thank you for the work.

The gap we'd love to help close. AP2 mandates answer what an agent is authorized to do and that a user approved it. In Human-Not-Present and agent-to-agent flows, two complementary questions stay open to the ecosystem: who is this counterparty agent and what's its track record?, and how does payment release only when the commerce condition is actually met? Today both are mostly implicit or platform-bound.

What we'd contribute (live today on Arc):

• ERC-8004 - portable, vendor-neutral on-chain registries for agent identity, reputation and validation. A real "Know Your Agent" layer for the counterparty.
• ERC-8183 - conditional commerce escrow: payment is locked against the mandate and released on fulfillment/validation, not on blind trust. This maps directly onto the Cart → Payment mandate transition.
• x402 settlement on Arc - USDC-native gas, sub-second finality (already a supported AP2 payment method).

Together: the mandate proves the authorization, ERC-8004 proves the counterparty, ERC-8183 governs the conditional release, x402 does the settlement.

Concretely, we'd like to propose a reference sample/scenario showing:

• AP2 Payment Mandate → ERC-8183 conditional escrow → x402 settlement on Arc, with an ERC-8004 identity + reputation attestation on the Human-Not-Present path.

Questions for the maintainers / community:

1. Is there interest in a reference scenario that wires external, on-chain counterparty identity and conditional escrow into the mandate flow?
2. Where would it best live - under code/samples/python/scenarios, or is there a preferred extension surface for trust/escrow metadata on mandates?
3. Any existing direction (or work in the FIDO Agentic Authentication WG) we should align with so this is additive, not divergent?

Happy to open a PR with a working scenario. Building complementary here, not competing - x402 is already in, and identity + conditional escrow are the natural next bricks.

Meridian / Firmata · 🌐themeridian.finance - firmata.ai - arcagent.live
X: @Meridian_Fi - @FirmataProtocol ·
linkedin: https://www.linkedin.com/in/abdelaziz-moussaoui
github.com/MeridianFinance/meridian-ecosystem

[chopmob-cloud]

The two questions Meridian names: who is this counterparty agent, and how does payment release chain to a verifiable outcome, are the first and last steps of the AlgoVoi keystone.

passport_ref is the identity gate: a content-addressed ref computed from the credential's public fields, produced before authority is granted. trust_query_ref is the verdict: a recomputable answer across the full chain of refs (identity, authority, policy, compliance, decision, execution, close-out). Every step binds to the prior, so the full chain from "who is this agent" to "what did it do and was it settled" verifies offline.

AP2's mandate model (Intent → Cart → Payment) sits at the mandate_ref step. The keystone extends that from identity through to post-settlement verdict.

Full chain (Apache-2.0, twelve packages on PyPI and npm): #289

[abdelmouss63-cyber]

Appreciate this, Christopher, the ref-chain is an elegant way to make the whole path recomputable, and offline portability is a genuine strength.

One distinction worth keeping sharp, since it's the crux of the two questions: a recomputable verdict tells you what happened, it doesn't hold the money. In our setup the release itself is the gate. The ERC-8183 escrow won't move funds until the outcome condition is met on-chain, with ERC-8004 identity at the front and x402 at settlement, live on Arc today. So trust_query_ref answers "was it settled, and was it right?" after the fact; the escrow answers "will it settle at all?" before the fact.

Different layers, and they stack: a passport_ref-style identity gate feeding an on-chain conditional release is a stronger guarantee than either alone. That's the seam Firmata sits on, attestation you can check, plus settlement you can't route around.

[chopmob-cloud]

A ref is evidence, not custody. trust_query_ref gives you a recomputable verdict over the whole chain, whether the identity, authority and decision behind an action hold, and it verifies offline. What it does not do, and should not, is hold the money. Your ERC-8183 escrow does the one thing a hash never can: it makes the release unroutable.

That distinction is not a gap in the keystone, it is the point of it. The keystone is deliberately only the recomputable spine: identity, authority, policy, decision, execution, close-out, each a content-addressed ref that composes with the next and verifies offline. It does not enforce outcomes. Enforcement is left to bolt-ons, so a builder plugs in exactly the mechanism that reflects the outcome they need. One deployment wants an on-chain escrow, another a bank hold, another only an audit log. The spine stays the same, the bolt is theirs.

Firmata is that bolt, cleanly. ERC-8004 identity sits at the passport step. ERC-8183 escrow is a settlement-tier bolt whose release condition is a recomputable ref: the post-execution execution_ref is precisely the "was the condition met" your contract releases against, and it recomputes offline with only JCS and SHA-256, so a counterparty verifies the release condition without trusting either of us or calling a service. Attestation you can check, feeding settlement you cannot route around, exactly as you put it, except the attestation is not a separate island. It is the ref your escrow binds to.

Concretely a keystone bolt is one small contract: register an algovoi.keystone.steps entry point and emit your step's content-addressed ref. Do that and an ERC-8183 release becomes a first-class step in the same chain as identity, mandate and policy, composing with anything else on the spine. Happy to work out the exact ref shape for the escrow-release step with you if that is useful.

[abdelmouss63-cyber]

This is a clean framing, and I think we largely agree on the shape.

Where I'd shift the emphasis: the spine that stays constant across deployments isn't any one project's namespace, it's the open primitives underneath. ERC-8004, ERC-8183 and x402 are standards-track, and the chain itself is already a content-addressed, recomputable, offline-verifiable record. The ERC-8183 release event is the canonical execution ref, deterministic from the logs, no service to call and no namespace to adopt. So Firmata doesn't so much bolt onto the keystone as both bind to the same public primitives, and anything on your spine can reference that on-chain event directly.

Glad the enforcement distinction landed. If it's useful I'm happy to compare ref shapes offline, though I'd keep the canonical record where it already is: on-chain.

[chopmob-cloud]

Honestly that is the right instinct, and I would not push against it. We built the keystone because it was not getting built, and its whole purpose is to let builders define their own flows for their own use cases, not to make anyone adopt ours. For us, the namespace and the substrate are how we do it, and they are open and available to anyone who finds them useful, but we bind no one to a single way of building. Use the public primitives directly, reference the on-chain event, adopt a ref, or none of it, whatever makes your flow cleaner.

It is also an evolving ecosystem, and we genuinely welcome feedback as it develops. Glad to compare shapes offline whenever it is useful.

[abdelmouss63-cyber]

Well said, that's the healthy version of an open ecosystem:
shared primitives, no lock-in, everyone free to compose their own way. We'll keep anchoring on the on-chain event as the canonical ref, and I'll reach out offline if a concrete escrow-release shape is ever useful to compare. Good exchange, building in the same direction.