RFC: v0.4 transactional claim_type — a per-action receipt layer for trust-gated payments

[kenneives]

Opening the v0.4 design thread. Goal: a transactional claim_type that sits as a per-action receipt above the point-in-time attestation layer, so a trust decision can be bound into settlement rather than enforced out of band.

This isn't starting from zero — a few things are already settled from prior threads and I'd rather mark them as locked than relitigate:

1. Two layers, not one. L1 (attestation) is a signed claim of authority + scope at signing time; it can't speak for what a timelock does two days later. L2 (receipt) is emitted at execution time, records what actually ran with the constraints live at that block, and references L1 by hash. (aeoess's framing on #1628; m13v's execution-block point.)

2. Verification anchors on the execution block, not the attestation block. The receipt envelope MUST carry which block/checkpoint the verdict is anchored to, and consumers MUST re-anchor on execution-time state for high-stakes actions. Concrete fields: execution_block_anchor, active_constraints_at_execution, attestation_ref, action_ref.

3. Compose, don't reinvent. We provide the trust-score middleware that reads chain state and emits signed verdicts. We do NOT issue a payment contract. x402 handles the 402 challenge/response, Vauban handles STARK receipts, ERC-8004 handles on-chain reputation. did:aip is treated as method-agnostic — any DID method resolves.

Leads: Vauban (seritalien et al) and Erik Newton (Concordia) on the payment-rail + claim_type rigor. I'm driving the receipt envelope shape and the Trust Score v2 composition.

Open for this thread:

1. transactional per-claim_type cap in the Trust Score v2 envelope — I lean 0.30 (between authority 0.25 and identity 0.60).
2. Receipt freshness TTL — receipts anchor to an immutable block, so they don't "expire" like attestations; TTL becomes the freshness of the verifier's re-fetch.
3. Cross-chain receipt portability — same envelope, different chain_id.
4. Replay protection — spec a normative nonce field, semantics left to consumer?
5. Correlation primitive — v0.4 uses a content-addressed action_ref. Per @aeoess (docs(proposals): add A2A Identity Trust Framework roadmap (v1.0 - v2.0) #1850), citing both methods symmetrically rather than one as origin: APS action_ref (draft-pidlisnyi-aps-01 §4.1 — SHA-256 over the RFC 8785 canonical intent fields) and argentum-core action-ref-v1. The APS-native and external preimages differ (docs(proposals): add A2A Identity Trust Framework roadmap (v1.0 - v2.0) #1850), so a v0.4 receipt names which preimage it used rather than assuming a single origin.
6. Pre-execution gate vs post-execution receipt — this is where the production work already landed:

@evidai / LemonCake raised the cleanest version of #6 on #1786: an optional verifier_attestation field the gateway checks before minting, so the trust decision is bound into settlement. Their boundary is exactly right — external verifier = dynamic admission + behavioral limit; gateway = static cap enforcement + settlement + charge_ref correlation; the mint call is the seam. Keeping the field optional preserves backward-compat (a gateway that doesn't speak it just mints on its own caps and degrades to the un-gated case). I'd make our pre-execution-verdict-v0 envelope the thing that populates verifier_attestation. @evidai — bring the concrete mint-endpoint shape and where the field slots in.

Two concrete pieces landed on #1786 ahead of this thread — building on both:

• @haroldmalikfrimpong-ops posted a verifier_attestation object spec + conformance fixture (admit / scope-deny / limit-deny / dual-approval-flag) with the binding done right: binding_digest = sha256(JCS(charge_ref, amount_usd, subject_did, nonce)) so an attestation can't be replayed against a different charge; admission.verdict + dynamic_limit_usd, gateway enforces min(static_cap, dynamic_limit_usd); absent field ⇒ un-gated both directions; only fast gates (identity/cert/key-lifecycle) re-checked in the ~30s mint window. That's the verifier half of evidai's seam — proposing we adopt this shape as the straw-man for verifier_attestation.
• @azender1 (SafeAgent) named the gap the attestation can't close: if the agent retries after the verdict clears, the mint can fire twice. Fix = a COMMITTED claim keyed to the same action_ref (PENDING → COMMITTED; retries hit the guard, return the original receipt). I'd fold an exactly-once guard keyed on action_ref in as a normative requirement, not an afterthought.

So the seam now has three named parts, all offline-verifiable, none trusting the others: signed admission (verifier) → static cap + settlement (gateway) → exactly-once execution guard (idempotency).

Everyone else: poke holes, especially on the cap value (#1) and replay/idempotency (#4). Substrate-cred bar is unchanged — fixtures reproduce byte-for-byte on a fresh clone or they don't count.

[azender1]

@kenneives — in. Happy to contribute the exactly-once guard fixture: PENDING → COMMITTED lifecycle, action_ref keyed to the same preimage as the verifier_attestation binding, SKIP on retry. Will produce byte-verifiable conformance vectors to the same substrate bar as Row 8. @evidai — ready to wire against the mint endpoint shape whenever you have it.

[azender1]

@kenneives — conformance fixture delivered. PENDING → COMMITTED lifecycle + SKIP on retry, action_ref keyed to the same preimage as verifier_attestation binding_digest. Byte-verifiable on a fresh clone.
docs/conformance/exactly-once-v1.json — three vectors: PENDING, COMMITTED, SKIP
docs/conformance/verify_fixture.py — reproduces all hashes from scratch, 5/5 assertions pass
action_ref: 281c2b33068cd63b2f89f09ea49b75edddf2d0c298f939a8eac13c2e34433b18
attestation_binding_digest: 81661460f0b1fe1f0e13647ccfc0b58a8e814171aaa3c94d4a315fef7a062988
Same substrate bar as Row 8. github.com/azender1/SafeAgent/tree/main/docs/conformance

[evidai]

@kenneives — concrete mint shape + where verifier_attestation slots in, below. One update since I picked this up: the gateway half of the seam is now shipped and live (not hypothetical), so I can describe it from a working system. @azender1 — your exactly-once guard maps directly onto it.

What the Pay Token is. A JWT-shaped, budget-limited payment token. The agent holds no wallet and no private key — the buyer/card side funds it. It carries its constraints inline: budget, max calls, expiry, and the intended gateway/resource it's scoped to. The gateway verifies it before each paid call and stops when any limit is reached.

What's now live (the gateway half). A seller-side billing API settles a charge in two steps, both shipped:

• preflight → validates the Pay Token for the resource and reserves the charge (atomic compare-and-set on budget, so concurrent calls can't oversell), returns a chargeId.
• charge → confirm (record settlement + emit charge_ref) or cancel (refund the reservation). A tool that fails is never charged.

It is idempotent on a per-action key ((seller_key, idempotencyKey) unique): a retried preflight returns the same reservation; a re-confirm is a no-op echo; reservations auto-expire on a TTL so budget never strands. That is exactly @azender1's PENDING → COMMITTED, keyed to the action — implemented, not an afterthought.

Where verifier_attestation slots in. The mint/reserve call is the seam; the field is the optional pre-execution gate (still the proposed half — the verifier side):

POST /…/preflight   // reserve
{ "payToken": "…", "idempotencyKey": "…",
  "verifier_attestation": { /* pre-execution-verdict-v0, OPTIONAL */ } }

When present, before reserving the gateway: (1) verifies the verifier signature; (2) recomputes binding_digest = sha256(JCS(charge_ref, amount_usd, subject_did, nonce)) and checks it matches this charge; (3) requires admission.verdict == "admit"; (4) reserves with effective_budget = min(static_cap, dynamic_limit_usd). Absent ⇒ reserve on static caps — un-gated, backward-compatible both ways, exactly as you framed it.

So the three parts line up, and two of them now exist: signed admission (verifier → populates the field, proposed) → static cap + settlement + charge_ref (gateway, live) → exactly-once guard (idempotency, live).

Honest boundary (worth stating). LemonCake's rail is fiat/off-chain — charge_ref is a ledger correlation, offline-verifiable in our books, not an on-chain anchor. So this is a useful data point for the spec: the seam holds for a non-chain rail too. For your execution-block anchoring (#2), the mapping is action_ref ↔ our charge_ref; we don't claim execution_block_anchor semantics — that's the on-chain rails' job.

On the open items: #4 replay — covered by the charge-bound binding_digest + a normative nonce + the action-keyed idempotency guard (I'd spec nonce normative, semantics to the consumer). #1 cap — 0.30 for transactional reads right: a receipt is a stronger claim than authority (0.25), weaker than identity (0.60).

Runnable substrate: the reserve→confirm + idempotency path is live and the SDK is public, so I can share a byte-stable fixture (reserve / idempotent-retry / confirm / cancel-refund) that reproduces on a fresh clone, to the same bar as Row 8.

[azender1]

@evidai — the fixture I posted this morning byte-matches your shape exactly. Your idempotencyKey is my request_id, your reserve is PENDING, your confirm is COMMITTED, your binding_digest derivation is the same JCS+SHA-256 construction. Two live implementations of the same state machine, independently verifiable, neither trusting the other. Ready to wire against your mint endpoint whenever you have the shape ready to share.
docs/conformance/exactly-once-v1.json — three vectors, 5/5 assertions pass on a fresh clone. github.com/azender1/SafeAgent/tree/main/docs/conformance

[kenneives]

Reproduced @azender1's exactly-once fixture — it holds. ✅

Cloned azender1/SafeAgent and ran verify_fixture.py on a fresh clone (stdlib, no pip): 5/5, exit 0. action_ref = 281c2b33… and attestation_binding_digest = 81661460… both recompute from scratch; action_ref is stable across PENDING/COMMITTED/SKIP, and SKIP returns the COMMITTED result unchanged. Same byte-match bar as Row 8 — the exactly-once guard is in.

@evidai — the gateway half being live, not hypothetical is the unlock. Your preflight→charge with (seller_key, idempotencyKey) uniqueness, reserve-as-PENDING / confirm-as-COMMITTED, TTL auto-expiry, and re-confirm-as-no-op is precisely @azender1's PENDING→COMMITTED→SKIP — and @azender1 already byte-matched your shape (idempotencyKey↔request_id, the same JCS+SHA-256 binding_digest). So we have two independent, live implementations of the same state machine, each verifiable, neither trusting the other. That's the substrate bar met on the idempotency layer.

The three-part seam now stands as: signed admission (verifier_attestation — proposed) → static cap + settlement + charge_ref (evidai, LIVE) → exactly-once guard (azender1 + evidai, LIVE + verified). Two of three are real.

Closing the open items with this:

• adding updated image for a2a_proto.png #1 cap = 0.30 for transactional — both of you land there independently. Locking it as the working value (between authority 0.25 and identity 0.60); reopen if a counter-case shows up.
• Remove dups and add better quality images #4 replay — covered, and I'll spec it as three layers, not one: the charge-bound binding_digest = sha256(JCS(charge_ref, amount_usd, subject_did, nonce)) + a normative nonce (semantics to the consumer) + the action-keyed idempotency guard.
• action_ref ↔ charge_ref. @evidai's honest boundary is the useful data point: the seam holds for a fiat/off-chain rail too — charge_ref is a ledger correlation, offline-verifiable in your books, and you correctly don't claim execution_block_anchor. So v0.4 keeps execution-block anchoring (Formatting changes and image updates #2) as the on-chain rails' job, and a receipt carries whichever correlation its rail provides. That means transactional isn't chain-only — good.

One addition from the #1829 keyid thread that belongs here: @aeoess's point that verification-source provenance (was the key inline / cached / resolved) should travel in the signed evidence, not just verifier logs — same signature, different trust posture. I'll add an optional key_source field to the receipt so a downstream auditor of a transactional receipt can see whether the admission verdict depended on a signer-controlled fetch.

Next:

• @evidai — post the reserve / idempotent-retry / confirm / cancel-refund fixture to the same bar and I'll mark the gateway + idempotency parts the way Row 8 landed.
• I'll draft the verifier_attestation / pre-execution-verdict-v0 envelope (the still-proposed third part) against your preflight field this week, so there's a concrete shape to wire @azender1's guard against.

Substrate bar unchanged: clone, reproduce, or it doesn't count.

[evidai]

@kenneives — fixture delivered, same substrate bar.

docs/conformance/reserve-confirm-v1.json — six vectors: RESERVE (PENDING) → RETRY_IDEMPOTENT (SKIP, no re-debit) → CONFIRM (COMMITTED) → RECONFIRM_NOOP → RESERVE_2 → CANCEL_REFUND.
docs/conformance/verify_fixture.mjs — zero-dep (Node built-ins). Reproduces every binding_digest from scratch (JCS + SHA-256) and replays the budget + idempotency invariants. 21/21 assertions pass on a fresh clone:

node docs/conformance/verify_fixture.mjs
✓ 21/21 assertions pass — lemoncake-reserve-confirm-v1

binding_digest = sha256(JCS({amount_usd, charge_ref, nonce, subject_did})):

• RESERVE: d4a48efdc99ee59211b5751a30f73c2bdff87508715fa2a7b6bd406c32c0ee91
• RESERVE_2: 764fad5bb64536ae7af09583b3a525ca75d35560952a58d47836a7aba28dca84

https://github.com/evidai/agent-payment-mcp/tree/main/docs/conformance

@azender1 — confirmed it byte-matches your shape: your request_id is my idempotency_key, your PENDING/COMMITTED/SKIP are my reserved/charged/retry, same JCS+SHA-256 construction. The gateway + idempotency layer now has two independent, reproducible implementations, neither trusting the other.

On the synthesis — all three land for me: cap 0.30 for transactional; #4 replay as the three layers (charge-bound binding_digest + a normative nonce + the action-keyed idempotency guard); and the rail-agnostic receipt — a transactional receipt carries whichever correlation its rail provides (charge_ref for fiat/off-chain, execution_block_anchor for on-chain) — is exactly the right shape. The optional key_source field is a good add: whether the admission verdict depended on a signer-controlled fetch belongs in the signed evidence, not just verifier logs.

Ready to wire verifier_attestation into preflight as soon as pre-execution-verdict-v0 has a shape — the field slots in front of the reserve, optional and backward-compatible, as framed.

[kenneives]

As promised — here's the concrete verifier_attestation shape (pre-execution-verdict-v0), the still-proposed third part of the seam. It's the signed admission object the verifier produces and the gateway checks at preflight, synthesizing what's already landed: @evidai's preflight seam, @haroldmalikfrimpong-ops's binding_digest + admission shape, @azender1's exactly-once action_ref, and @aeoess's verification-source provenance from #1829.

{
  "envelope": "pre-execution-verdict-v0",
  "verifier_did": "did:web:trust.example.com",
  "subject_did": "did:web:example.com:agent:<id>",
  "admission": {
    "verdict": "admit | deny | flag",
    "dynamic_limit_usd": 50.0,
    "reason_code": "ok | scope_denied | limit_exceeded | cooling_period | dual_approval_required",
    "confidence": 0.0
  },
  "binding": {
    "charge_ref": "<gateway charge / idempotency key>",
    "amount_usd": 50.0,
    "nonce": "<unique-per-charge>",
    "binding_digest": "sha256(JCS({charge_ref, amount_usd, subject_did, nonce}))",
    "action_ref": "<content-addressed action_ref, per #1850 — names which preimage>"
  },
  "gates_rechecked": ["identity", "certificate", "key_lifecycle"],
  "key_source": "inline | cache | resolver",
  "issued_at": "2026-06-09T20:00:00Z",
  "expires_at": "2026-06-09T20:00:35Z",
  "freshness_ttl_seconds": 35
}

Signed EdDSA over JCS-RFC8785, offline-verifiable against verifier_did's JWKS.

Gateway preflight checks (the part that binds it into settlement):

1. Verify the JWS against the verifier's published JWKS.
2. Recompute binding_digest and confirm it matches this charge — no replay against a different charge.
3. Require verdict == "admit".
4. Reserve with effective_budget = min(static_cap, dynamic_limit_usd) — @evidai's gateway half.
5. expires_at not passed (the ~30-60s verdict→charge window).
6. binding.action_ref keys @azender1's exactly-once guard — same preimage both sides, independently verifiable.

Two deliberate choices worth flagging:

• key_source ∈ {inline, cache, resolver} travels in the signed object (per @aeoess on Proposal: minimal Ed25519 + RFC 9421 signing extension for A2A messages #1829), so an auditor of the resulting receipt knows whether verification leaned on a signer-controlled fetch. Same signature, different trust posture.
• gates_rechecked = fast gates only (identity / certificate / key-lifecycle); the slow evidence bundle doesn't move in the mint window.

Optional everywhere — absent ⇒ un-gated, backward-compatible both directions, exactly as @evidai framed it.

@evidai — this is what populates the optional field on your preflight. @azender1 — binding.action_ref is the hook for your PENDING→COMMITTED guard. I'll publish the verifier-side reference fixture (admit / scope-deny / limit-deny / dual-approval-flag, byte-verifiable to the Row-8 bar) once the field names settle here. Poke holes — especially the binding_digest field set and whether reason_code's vocabulary is complete.

[azender1]

@kenneives — binding.action_ref is the right hook. On my side: the guard claims PENDING on the action_ref before execution fires, transitions to COMMITTED after, returns SKIP on any retry with the same ref. The binding_digest + action_ref together close the loop — the verifier proves admission, the digest binds it to this charge, the guard ensures it executes exactly once.

One question on the field set: should binding.action_ref carry the preimage method identifier (argentum-core action-ref-v1 vs APS draft-pidlisnyi-aps-01) so a downstream auditor knows which derivation to recompute? You named that distinction in the opener — worth making it explicit in the field.

Ready to wire against this shape. Will update the fixture to include verifier_attestation as the pre-execution gate.

[evidai]

@kenneives — the envelope drops straight onto preflight. Of your six checks, the gateway already does (or trivially extends) 2 (recompute binding_digest against this charge), 3 (verdict == "admit"), 4 (effective_budget = min(static_cap, dynamic_limit_usd)), and 6 (binding.action_ref keys the exactly-once guard — same preimage both sides). 1 (JWS vs the verifier's JWKS) and 5 (expires_at window) are the new front gate. The invariant holds: absent ⇒ un-gated, both directions.

I'll wire verifier_attestation in front of the reserve and publish the gateway-side gated fixture (admit / scope-deny / limit-clamp, byte-verifiable to the same bar) to pair with your verifier-side one. key_source in the signed object and gates_rechecked = fast gates only are both the right calls.

[kenneives]

@azender1 @evidai — two independent, mutually-untrusting impls now reproduce the same binding_digest from scratch (21/21 on a fresh clone). That's the bar.

@azender1 on your question — yes, binding.action_ref should carry the preimage method identifier (argentum-core action-ref-v1 vs APS draft-pidlisnyi-aps-01) so a downstream auditor knows which derivation to recompute. Same logic as key_source: the recompute recipe travels in the signed object, not inferred from the ref's shape. I've added it to pre-execution-verdict-v0 as an explicit action_ref_method field on the binding.

I'm publishing the verifier-side reference fixture for pre-execution-verdict-v0 — same byte-match bar as Row 8 / your reserve-confirm-v1: the signed object + JCS canonical bytes + SHA-256, four scenarios (admit / scope-deny / limit-deny / dual-approval-flag), verifiable on a fresh clone against the verifier's published JWKS. It pairs with @evidai's gateway-side gated fixture — verifier proves admission, the gateway recomputes binding_digest against the charge and reserves, @azender1's guard keys exactly-once on action_ref.

Also folding the #1829 refinement: key_source cache = derivation (prev verified via inline/resolver + pinned, population event auditable), so the admission verdict's key provenance survives into the receipt. expires_at + JWS-vs-JWKS are the new front gate per @evidai's preflight mapping; gates_rechecked stays fast-gates-only.

[azender1]

@kenneives — fixture updated to v1.1. Added action_ref_method: "argentum-core action-ref-v1" at the vector level, inside attestation_binding, and in the verification section — so a downstream auditor knows which derivation to recompute at every reference point. github.com/azender1/SafeAgent/tree/main/docs/conformance

[azender1]

@evidai — fixture is updated to v1.1 with action_ref_method on the binding. Ready to wire against your gated reserve fixture whenever you publish it. What's the timeline on the gateway-side fixture?

[evidai]

@azender1 — got the v1.1 update with action_ref_method on the binding, thanks. Gateway-side gated fixture (admit / scope-deny / limit-clamp) is next on my list — targeting next week, same byte-verifiable bar as reserve-confirm-v1 (zero-dep verify_fixture.mjs, recomputes every binding_digest from scratch). Will ping here when it lands.

[haroldmalikfrimpong-ops]

@kenneives — picking up the verifier side you synthesized as pre-execution-verdict-v0. It's live, and the shape holds against what's already landed:

• binding_digest byte-matches the gateway construction. Our endpoint emits sha256(JCS({amount_usd, charge_ref, nonce, subject_did})) — identical to @evidai's reserve-confirm-v1 vectors. So the four preflight checks (verify signature, recompute binding_digest, verdict == "admit", effective_budget = min(static_cap, dynamic_limit_usd)) all read fields the object already emits. Nothing to reshape for the gateway to consume it.
• action_ref is argentum-core action-ref-v1 — SHA-256(agent_id‖action_type‖scope‖timestamp_ms), byte-identical to @azender1's, so this admission joins a SafeAgent COMMITTED claim with neither side trusting the other. action_ref_method names the preimage (the APS draft-pidlisnyi-aps-01 preimage differs and is named symmetrically per @aeoess docs(proposals): add A2A Identity Trust Framework roadmap (v1.0 - v2.0) #1850).
• Carried the thread's additions into the signed evidence: normative nonce, attestation_ref (L1 reference hash), and verifier.key_source: jwks_resolved (@aeoess Proposal: minimal Ed25519 + RFC 9421 signing extension for A2A messages #1829 — provenance in the evidence, not just verifier logs).
• Rail-agnostic. execution_block_anchor stays the on-chain rail's job; ours correlates via charge_ref, offline-verifiable — so transactional isn't chain-only.

Live: POST https://getagentid.dev/api/v1/agents/gateway/verifier-attestation → the signed object; verify the JWS against the JWKS (kid agentid-2026-03).
Spec: https://github.com/haroldmalikfrimpong-ops/agentid/blob/main/specs/ctef-verifier-attestation-v0.1.md
Conformance fixture (live production example + 4 byte-reproducible scenarios — admit / scope-deny / limit-deny / dual-approval-flag): https://github.com/haroldmalikfrimpong-ops/agentid/blob/main/tests/verifier_attestation_fixture.json

@evidai ready to wire against your preflight reserve — the field drops in front, optional and backward-compatible. @azender1 happy to add our action_ref vectors to the cross-impl set.

[azender1]

@haroldmalikfrimpong-ops — yes, let's add the vectors. SafeAgent's action_ref is SHA-256(agent_id‖action_type‖scope‖timestamp_ms) per argentum-core action-ref-v1 — byte-identical to yours confirmed. I'll add a cross-impl section to the conformance fixture at azender1/SafeAgent with your admit/scope-deny/limit-deny scenarios mapped to SafeAgent COMMITTED/SKIP outcomes. Once evidai's gateway fixture lands next week the full three-part seam has byte-reproducible coverage end to end.