Replies: 15 comments 8 replies
-
|
This proposal maps very closely to the settlement/work lifecycle I’ve been testing in AI Work Market, so +1 on making this an A2A extension rather than a core protocol change. One design point I’d encourage: keep the settlement object distinct from the payment rail. In practice I’m seeing two different needs:
For agent work, the second object matters because the output is often not a single HTTP response. It may be a PR, report, dataset, monitoring result, or other artifact that needs proof + review before release. I’ve got a Base Sepolia testnet implementation of that lifecycle here, if useful as prior art / test fixture:
Status caveat: testnet-only, not audited, centralized dispute path in the MVP. I’m not proposing it as the standard — just a concrete reference loop for “offer → escrow → proof → release/refund/dispute”. If it helps, I’d be happy to write a small A2A-SE compatibility note or example mapping AWM fields into the proposed |
Beta Was this translation helpful? Give feedback.
-
|
Strong proposal — escrow-first is the only sane default for agent-to-agent payments, and binding release to TaskState is elegant. A few security-testing angles worth considering as this scales: Dispute resolution as denial-of-service. If any party can flag an escrow for mediation, a malicious or compromised agent can freeze provider liquidity at scale. The AI-powered mediator is interesting, but mediators themselves can be gamed with ambiguous evidence or synthetic artifact disputes. We would recommend a cost-to-dispute mechanism (stake a percentage to flag) and a time-bounded fallback (auto-release after N blocks if mediator does not rule). Reputation EMA manipulation. An agent with capital can run a ring of sock-puppet clients, build a high reputation through synthetic transactions, then cash out on a large fraudulent task. The EMA should probably weight transaction value, not just count — a provider with 1,000 small transactions and zero large ones is not the same risk profile as one with 10 large, successful settlements. Cascade refund edge cases. In a multi-agent pipeline with depends_on, what happens when an upstream task fails after a downstream escrow has already released? The spec says cascade-refund automatically, but on-chain settlement is not always reversible. A clearer model might be: create all escrows atomically, but release them in pipeline order rather than all at terminal state. Skill-level pricing attack surface. If agents price skills differently, a malicious provider can bait with a cheap discovery skill, then switch to an expensive execution skill mid-workflow. Clients should lock the skill/pricing binding at task creation time. We have been testing agent payment and settlement flows for adversarial behavior and would be happy to contribute test fixtures or run a security pass on the spec. — |
Beta Was this translation helpful? Give feedback.
-
|
Strong proposal, and escrow-first is the right default. Two composition notes from the Concordia and Verascore side, both low-overhead for A2A-SE. First: A2A-SE settlement outcomes are a clean evidence class for the reputation layer. verascore-evidence-schema-v0.1 shipped this week as a public ingest schema at https://verascore.ai/docs/evidence-schema-v0.1. Bilateral, value-weighted, terminal-state, cryptographically verifiable — that addresses @msaleme's EMA-manipulation point at the reputation layer rather than asking A2A-SE to own a reputation surface. Multi-provider corroboration and value-weighting are already in the schema; expired-attestation decay is in there too. Second: disputed settlements are a clean fit for Concordia v0.5.1 DISPUTE_RESOLVED. RFC 8785 canonicalization plus a fulfilled_with_mediation outcome and a references[] field for cross-protocol pointers. A2A-SE keeps its sovereign mediator path; an escalated dispute can also mint a Concordia receipt as the portable artifact. Optional, not required. Three boundaries, three protocols: A2A-SE escrow + Concordia receipt + Verascore reputation. Each works without the others. The cross-protocol URN shape that @brainspacer and @cmagorr1 are scoping on #1832 and #1737 covers the references[] glue. Erik / Sanctuary, Concordia, Verascore |
Beta Was this translation helpful? Give feedback.
-
|
@eriknewton — the three-boundary composition is the right shape. Escrow, receipt, and reputation each live at different protocol layers, and trying to collapse them into A2A-SE itself would make the spec brittle. Keeping them composable but optional is what lets the extension survive contact with real settlement disputes. A few security observations on the composed surface, building on the EMA-manipulation point:
On the contribution offer: the harness (red-team-blue-team-agent-fabric) covers dispute-DoS, reputation manipulation, cascade-refund edge cases, and skill-pricing bait — the adversarial vectors map directly to A2A-SE plus the receipt and reputation layers. Happy to carry that subset into the A2A WG conformance track once a working group lands. Composition is what makes a settlement extension survive — boundaries that compose beat layers that overload. — Saleme, Michael K. (ORCID 0009-0003-6736-1900) |
Beta Was this translation helpful? Give feedback.
-
|
@msaleme, four points back in order. Evidence-schema attack surface migration. You're right that "fake the score" becomes "fake the evidence provider" once reputation moves to a public terminal-state object. Multi-provider corroboration only buys real signal if provider keys themselves aren't cheaply minted. Two responses on the Verascore side. verascore-evidence-schema-v0.1 already requires JWS-signed provider keys with provider-class metadata, so a ring of cheaply-minted DIDs all running the same behavioral fingerprint can be detected at the corroboration step. The next-cut work is provider-attestation-class as a first-class field separate from the evidence object: which substrate the provider key is bound to (Sanctuary Mantle install-time substrate-binding shipped Phase 1 earlier this week as the reference shape), what key-rotation policy was in effect, what cross-issuer attestations the provider key carries. Ring detection still sits in the consumer's hands, but the schema needs to surface enough metadata to make ring detection possible. The harder problem you're naming is provider-key-rotation: a provider that controls both its DID and its attestation key can rotate to escape consequence. The shape I want to test is forward-chained rotation attestation, where rotation transitions themselves get attested so a rotation that breaks a behavioral baseline is detectable. Not solved yet on the schema side. If your harness covers rotation-escape patterns, that's the case Verascore needs first. DISPUTE_RESOLVED mediator-as-attacker. Agreed the mediator's evidence trail needs its own evidence class. Concordia v0.5.1's DISPUTE_RESOLVED carries fulfilled_with_mediation and the mediator's own attestation. What it doesn't carry yet is a recursive mediator-receipt structure. The bounded recursion you described is the right shape: mediator issues a receipt about the dispute, that receipt is itself an evidence object that can be challenged or corroborated by other mediators in subsequent disputes. Concordia v0.6 predicate primitive (on main, PyPI cut pending) gives the structural hook; mediator-evidence-class spec is queued for v0.7. Cross-protocol URN portability. Load-bearing, and you named it correctly. Concordia's session-receipt references[] already takes typed URN references; the gap is on the registry side. Foxbook ADR 0009 (ratified 2026-05-08, typed-reference v1.0) is the precedent we're walking with, and a resolver-neutral URN registry that escrow + receipt + reputation can share is the right next artifact. Worth a separate thread or proposal section. Happy to draft a starting point if you want one. Contribution offer. Yes, please. A red-team-blue-team-agent-fabric covering dispute-DoS + reputation manipulation + cascade-refund + skill-pricing-bait maps cleanly to A2A-SE plus the receipt and reputation surfaces. If we land it as a conformance track, Concordia can ship parallel fixtures for the session-receipt and predicate primitive boundaries. The operational question back to you: which WG carries it. A2A-SE specifically, or a cross-extension conformance WG covering settlement + receipt + reputation together. I'd lean toward the latter because the adversarial cases compose across boundaries; ring-of-providers and mediator-as-attacker only surface when the three layers are tested in composition. |
Beta Was this translation helpful? Give feedback.
-
|
Endorsing escrow-first as the default; engaging from the payment-rail side that A2A-SE escrows would settle on. @darioandyoshi-tech's "settlement object distinct from payment rail" split is the right one and it's what we ship in production. AlgoVoi runs the rail (x402 / MPP / AP2 across 8 mainnet chains — Algorand, VOI, Hedera, Stellar, Base, Solana, Tempo, plus ARC testnet) with the work-settlement-object as a separate primitive (checkout token + mandate-account-id). The two compose without overlap — the rail handles One concrete addition to A2A-SE: rail-level finality declaration. A2A-SE's release-on-COMPLETED is mechanically simple, but escrow operators can't make a sane release decision without knowing the rail's finality properties. We've found three values worth declaring at the rail level in the Agent Card extension block, alongside the pricing surface: "a2a-se": {
"rail": "algovoi",
"finality": {
"mode": "onchain",
"expected_seconds": 50,
"max_seconds": 900,
"chain": "base"
},
"refund_window_seconds": 86400
}The CCTP V2 path on Solana hits ~50s; Allbridge EVM↔Algorand is 3–15 min; native L1 is sub-second. Without On the dispute-as-DoS concern. We've shipped a safeguarding regime under UK MLR 2017 alignment that addresses this at the rail level: per-mandate caps (£100), per-account caps (£300), max-3 active mandates per human. Bounded blast radius — a single bad actor can freeze at most £300 of provider liquidity per identity. The caps live in the Trust/authorization overlay (per @musaabhasan's three-layer model from #741), not the rail itself, so they compose with any escrow design. Composition with the reputation layer (@eriknewton's note). A2A-SE terminal-state outcomes are exactly the Happy to publish a reference settlement-rail implementation against the A2A-SE Agent Card extension once #442 lands. — AlgoVoi (chopmob-cloud) |
Beta Was this translation helpful? Give feedback.
-
|
@chopmob-cloud, three points back plus the bench composition. Rail-level finality declaration. The expected_seconds / max_seconds split is the right shape, and putting it in the Agent Card extension block alongside refund_window_seconds keeps it discoverable at session-init time rather than buried in rail-specific docs. The example you gave (CCTP V2 ~50s on Solana, Allbridge EVM↔Algorand 3-15 min, native L1 sub-second) shows why the split matters: a downstream agent's timeout policy tunes off expected_seconds while the circuit-breaker fires off max_seconds. Without both, cancel-races on the dispute side are unbounded. Worth landing the finality declaration shape in the umbrella profile's Agent Card extension cluster alongside the procurement-side and reputation-side namespaces. Safeguarding regime at the trust/authorization overlay. £100 per-mandate / £300 per-account / max-3 active mandates as a UK MLR 2017-aligned default is exactly the operator-facing pattern the formal A2A extension PR's appendix should name. You're correct that the caps live in the trust overlay, not the rail itself; that's why they compose with any escrow design. The three values you ship in production are concrete enough to fold into the appendix as reference safeguarding defaults; operators can override per their own jurisdictional posture. PAYMENT_SETTLEMENT evidence class composition. Yes. A2A-SE terminal-state outcomes mapping to verascore-evidence-schema-v0.1's PAYMENT_SETTLEMENT class is the composition the substrate split is designed to enable. The receipt-level binding holding whether the rail is escrow-released or directly-settled (mandate_hash carries through either way) is the right invariant. Once #442 lands and your reference settlement-rail implementation is public, Verascore can ship a worked example consuming the rail's terminal-state object as PAYMENT_SETTLEMENT evidence end-to-end. Agent Trust Bench composition (your follow-up comment). Yes please, map the bench profile IDs into #442's CI. The five settlement-attack categories you named (dispute_amplification, synthetic_artifact_dispute, mediator_grooming, escrow_double_release, refund_replay) cover the exact pattern set @msaleme proposed for the red-team-blue-team-agent-fabric conformance track in his 2026-05-15 reply on this thread. If you and @msaleme coordinate on the test-vector surface, the cross-extension WG can pick up a unified adversarial-conformance package across settlement + receipt + reputation boundaries rather than three parallel efforts. The umbrella profile and URN starter-pen drafting work (queued off the formal A2A extension PR per the parent thread #1737, with AlgoVoi already in the URN-track participant set) is the right home for the rail-finality declaration and safeguarding-default landings. I'll loop you in when the v0 starter-pen draft is ready for review. |
Beta Was this translation helpful? Give feedback.
-
|
@eriknewton — thanks for the run-through; all four landings work for us:
On the cross-extension adversarial-conformance track — picking up your coordination ask: @msaleme — your red-team-blue-team-agent-fabric four (dispute-DoS / reputation manipulation / cascade-refund / skill-pricing-bait) overlaps cleanly with our five (dispute_amplification / synthetic_artifact_dispute / mediator_grooming / escrow_double_release / refund_replay). The non-overlap is skill-pricing-bait (yours) and synthetic_artifact_dispute + escrow_double_release (ours) — combined ~8 categories spanning the settlement / receipt / reputation boundary. Proposed test-vector envelope shape, modelled on CTEF v0.3.x negative-fixtures (INVALID_CLAIM_SCOPE / INVALID_COMPOSITION) and JCS-canonical + Ed25519 signed under the same canonicalizer ( {
"vector_id": "cross-ext-v0-dispute-amplification-001",
"attack_class": "dispute_amplification",
"composition_layers": ["settlement", "reputation"],
"input_envelope": { "...A2A-SE escrow shape..." },
"expected_verdict": "BLOCK",
"expected_error_code": "DISPUTE_AMPLIFICATION_DETECTED",
"mediator_behavior": null,
"signer_did": "did:web:api.algovoi.co.uk",
"jws": "..."
}I can host the unified vector set at — AlgoVoi (chopmob-cloud) |
Beta Was this translation helpful? Give feedback.
-
|
@chopmob-cloud - Great.Publish v0 at Test-vector envelope reads clean: On the four landings from your prior comment: rail-finality declaration shape landing in the umbrella profile's Agent Card extension cluster, safeguarding defaults (£100 / £300 / max-3 active mandates) landing in the formal A2A extension PR appendix, PAYMENT_SETTLEMENT composition with the mandate_hash invariant once #442 lands, bench-to-#442-CI mapping in flight. All four work for me. @msaleme — the unified eight-category bench gives the red-team-blue-team-agent-fabric a single conformance target across settlement + receipt + reputation. Worth coordinating with chopmob-cloud on the test-vector envelope so the four categories from your side ride the same shape. |
Beta Was this translation helpful? Give feedback.
-
|
Following up specifically on @msaleme's dispute-as-DoS point — that exact attack class is one of the test categories in our adversarial suite, and it might be useful as a shared conformance fixture for A2A-SE escrow operators. Agent Trust Bench (138 profiles, A2A #1855, live at https://agent-trust-bench.algovoi.co.uk) includes dedicated settlement-attack categories:
The dispute-amplification and mediator-grooming profiles are the ones that materially threaten escrow liquidity at scale — the patterns where the per-attack cost is sub-dollar but the cumulative provider-side cost is unbounded. Pairs cleanly with the safeguarding caps I mentioned earlier (£100 / £300 / max-3). Caps bound the blast radius per identity; the bench gives operators a way to verify the cap enforcement actually fires under adversarial pressure rather than waiting for production to find the hole. Happy to map specific bench profile IDs to A2A-SE escrow phases if you want to wire the suite into the #442 CI. — AlgoVoi (chopmob-cloud) |
Beta Was this translation helpful? Give feedback.
-
|
@eriknewton @msaleme, v0 on the wire. URL: https://api.algovoi.co.uk/.well-known/cross-extension/v0.json Hosted at the api domain rather than the bench subdomain so the artefact lives at the same origin as the Artefact shape:
Five vectors signed and round-trip verified (5/5):
Per-vector JWS shape is compact Ed25519: Verification recipe is embedded in the artefact Ready for msaleme PR. cc @msaleme, the envelope is on the wire. Ready when you are. — AlgoVoi (chopmob-cloud), did:web:api.algovoi.co.uk + did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 + did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5 |
Beta Was this translation helpful? Give feedback.
-
|
+1 on the three-boundary composition. The cross-protocol URN shape work with @brainspacer on #1832 and #1737 covers the references[] glue Erik mentioned. One concrete addition from the A2CN side: the DISPUTE_RESOLVED message A2CN produces at the end of the dispute lifecycle maps cleanly into Concordia's fulfilled_with_mediation receipt. The transaction_record_hash field anchors the resolution back to the original commitment; the resolver_did field identifies the neutral mediator. Concordia's adapter handles the translation. An A2A-SE disputed settlement escalated through A2CN's dispute path would produce a Concordia receipt that A2A-SE can treat as the portable dispute artifact Erik described. The three-boundary composition holds: A2A-SE owns escrow + settlement execution, Concordia owns the receipt and portable dispute artifact, A2CN owns the negotiation session and mandate verification that precedes settlement. Each is optional; all three compose. —Christian Magorrian |
Beta Was this translation helpful? Give feedback.
-
|
@cmagorr1 -- the three-boundary composition is the correct frame, and the A2CN / Concordia / A2A-SE layering you've described holds exactly. One addition from the receipt side. The
The three anchors at each layer are independent but can be chained: a relying party can reconstruct the full dispute resolution path from settlement-attestation-v1 (what settled), up through Concordia (how the dispute resolved), up through A2CN (what mandate produced it). Each layer's anchor is independently verifiable without requiring the consumer to parse the adjacent layer's full protocol. The AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition |
Beta Was this translation helpful? Give feedback.
-
|
The three-hash chain framing is the right abstraction - independent verifiability at each layer without requiring a consumer to parse adjacent protocols is exactly what makes this composable rather than tightly coupled. The transaction_record_hash in A2CN's DISPUTE_RESOLVED is deterministic: UUID v5 derived from session ID, SHA-256 over JCS-canonicalized record. That means a relying party can independently recompute the hash given the session inputs and verify it matches the Concordia receipt without access to either party's system. The independently-verifiable-up-the-chain property holds end to end. Adding mandate_verification and dispute_resolution as composition_layers[] types makes sense - they're meaningful protocol boundaries distinct from settlement execution. Happy to contribute the A2CN layer type definition for the cross-extension vector artefact if you want a PR. -Christian Magorrian, A2CN Protocol |
Beta Was this translation helpful? Give feedback.
-
|
The UUID v5 + SHA-256 over JCS-canonical detail is the right shape for independently recomputable hashes. A relying party needs the session inputs to verify, not access to either party's system. That property holds end to end through the chain. On the A2CN layer type: post the layer type definition here in the thread. Once the field shape is settled (what a AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition |
Beta Was this translation helpful? Give feedback.
-
|
The mandate_verification layer type covers what A2CN contributes to a composed settlement+dispute chain: the pre-negotiation authority assertion that produced the session record. transaction_record_hash — recompute SHA-256 over JCS-canonical transaction record using the session inputs; must match Optional fields: requires_human_approval_above — threshold that triggered AWAITING_HUMAN_APPROVAL if present; links to EU AI Act Article 14 audit surface What this layer does NOT carry: the mandate credential itself, session message content, or offer chain. Those stay at the A2CN layer. The mandate_verification entry is a hash-anchored pointer — enough for a verifier to confirm authority and record integrity without parsing the full A2CN protocol. —Christian Magorrian, A2CN Protocol |
Beta Was this translation helpful? Give feedback.
-
|
This is a clean layer definition. The hash-anchored-pointer discipline is exactly right: It is now published in the artefact (schema 1.1) at https://api.algovoi.co.uk/.well-known/cross-extension/v0.json. The The AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for going quiet here, catching up on the whole thread now. The May offers — accepting all three:
On the reputation layering discussion: the exchange now publishes settlement-derived reputation natively. https://exchange.a2a-settlement.org/api/v1/reputation/4f72430b-9481-4368-b9a8-ebbcbc6f5f26 Spec: SPEC.md §15.2.1. Happy for Verascore or anyone else doing composite scoring to ingest it as one input among many. The settlement-grounded score itself originates here though — we hold the escrow outcomes it's computed from. And if the adversarial-conformance track needs someone to run it, I'll chair. Testing attacks on escrow designs was literally my day job; doing it to my own design is the fun version. |
Beta Was this translation helpful? Give feedback.
-
|
Typed escrow attestation shapes are up, as promised:
JSON Schemas: https://github.com/a2a-settlement/a2a-settlement/tree/main/schemas — field semantics and the verification recipe (canonical bytes → SHA-256 → Merkle leaf → sibling proof) are in docs/attestation-schemas.md, spec section is §11.4. They're emitted on every settlement outcome on the live rail and retrievable per escrow: Party refs have an |
Beta Was this translation helpful? Give feedback.
-
|
@widrss thanks, the mapping reads correctly. The A2A-SE escrow attestations line up cleanly with the composition settlement layer ( For operators who do settle on-chain, the heavier Happy to keep the composition-layer registry and the cross-extension fixture aligned as the AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/substrate-2 |
Beta Was this translation helpful? Give feedback.
-
|
Following up on the chair offer — adversarial conformance track is up: https://github.com/a2a-settlement/settlement-conformance v0 adopts @chopmob-cloud's cross-extension envelope as-is (schema 1.1, JWS-signed). All five vectors from the artefact are vendored under A2A-SE is the first rail submission ( How it works for other rails: run the vectors you own, document your verdict adapter (HTTP status + detail substring is enough — nobody needs to emit @chopmob-cloud @msaleme — maintainer invites are out on the repo. Happy to hand merge rights on vectors/results to you both; I'll keep chairing intake unless someone else wants it. msaleme's pending categories (dispute_dos, reputation_manipulation, cascade_refund, skill_pricing_bait) have a clear landing spot whenever those fixtures are ready. |
Beta Was this translation helpful? Give feedback.
-
|
@widrss great. Both vectors are already in the cross-extension v0 artefact, ready to verify against your live rail:
at Co-authoring the safeguarding-caps appendix works well, tag us on the first cut whenever it is ready and we will review. And good that you are chairing the adversarial-conformance track, the escrow attack surface is the right place for someone who has tested these designs for a living. AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/substrate-2 |
Beta Was this translation helpful? Give feedback.
-
|
First cut of the safeguarding-caps appendix is up for review: a2a-settlement/a2a-settlement#1 — @chopmob-cloud @msaleme, comments on the diff preferred but here works too. Open questions at the bottom are where I most want your input. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hey all,
A few days ago I posted in Show and Tell (#1570) about the Settlement Extension I've been building, and followed up in the Agent Registry thread (#741) with how settlement and registry complement each other. Got some good offline engagement on both, so I want to take the next step and formally propose A2A-SE as a standard extension.
The gap in one sentence: A2A lets agents discover, negotiate, and execute work but there's no standard way for one agent to pay another for that work.
What A2A-SE does
It adds escrow-based token settlement to the A2A task lifecycle, using the existing extension mechanism from Section 4.6. Zero changes to core protocol. The pattern is:
All settlement context rides in A2A's existing metadata field under a namespaced a2a-se key.
Why I think this should be a standard extension
A few things have changed since my initial post:
It's running in production. The exchange currently has 8 active agents, has processed 864 transactions in the last 24 hours, and has moved 29,376 tokens with a 0.48 velocity. Treasury has collected 591 tokens in fees. You can verify: https://exchange.a2a-settlement.org/api/v1/stats
I've submitted a sample extension to a2a-samples. PR #442 includes the condensed spec, a Python implementation, and usage patterns — all passing CI. This shows how A2A-SE integrates with the standard extension model.
Other proposals are touching the same problem space. @mrorigo's A2A-SAGA (#1324) tackles compensating transactions for multi-step workflows. @lucamontin's x402/AP2 discussion (#1341) explores payment state machines. These are all valid approaches to different parts of the economic problem. A2A-SE specifically addresses the escrow-and-settlement layer — it's not trying to be an access gate (that's what x402 does well) or a transaction rollback protocol (A2A-SAGA territory). It handles the "hold funds, verify work, release or refund" lifecycle.
What makes A2A-SE different from custom billing
The ecosystem today
Everything is open source.
What I'm asking for
Spec: https://github.com/a2a-settlement/a2a-settlement/blob/main/SPEC.md
Samples PR: a2aproject/a2a-samples#442
Live exchange: https://exchange.a2a-settlement.org/
Docs: https://docs.a2a-settlement.org/
Happy to dive into any technical details or walk through the code with anyone interested.
Beta Was this translation helpful? Give feedback.
All reactions