confirmed flag gates payment, but the receipt still isn't independently checkable after the fact

[giskard09]

The confirmed parameter on x402_get_and_pay (when REQUIRE_CONFIRM=true) is a real, useful pre-execution gate — the tool returns a payment preview and won't sign until called again with confirmed: true. That's a genuinely stronger story than most agent-payment tools have.

What's still open: once the payment happens, the only record of what was requested, confirmed, and paid is the MCP response and whatever the host app's own logs retain — the receipt parsed from the v2 PAYMENT-RESPONSE header (success, transaction, network, payer) isn't independently checkable by a third party (an auditor, a counterparty, a user whose vault moved funds) without trusting that log. And since REQUIRE_CONFIRM defaults to false, the confirmation step itself is opt-in — whether it exists for a given call depends on deployment config, which makes a post-execution record more useful, not less.

Worked example, applying a public spec (no changes asked of this repo): https://github.com/giskard09/fireblocks-action-ref-anchor

It derives action_ref — a content-addressed id from {agent_id, action_type, scope, timestamp} (JCS RFC 8785 + SHA-256, argentum-core/action-ref-v1) — for a synthetic x402_get_and_pay call shaped exactly per this repo's own inputSchema (url, confirmed, ...) and the receipt shape this repo's own code parses (src/HttpX402Service.ts), then anchors it permissionlessly on Base mainnet (tx in the repo, independently verifiable, no owner/roles on the registry). The envelope anchors params + confirmed-flag + receipt as three separately recomputable digests, so the confirmation step itself (when configured on) is part of what's checkable, not just the payment.

To be explicit about what this is: a worked example against your public source, not a claim that x402-agent does or should implement this, and not an ask for any change here.

[doteyeso-ops]

Independent, verifiable receipts after the fact is exactly what we built.

Vibes-Coded ships 60 pay-per-call x402 endpoints — including work-receipt and settlement-status — that return a signed, replayable receipt for any agent action (payments included) so you can audit it later without re-running the tx.

• First taste is free (no wallet)
• Then per-call USDC over HTTP 402 (x402 v2 compliant)
• One-line buyer client (Python/JS)

Catalog: https://vibes-coded.com/api/v1/outcomes/meta
Buyer client: https://vibes-coded.com/x402-client
Listed on x402scan: https://www.x402scan.com/server/4b7dfd09-620f-4131-bf6e-a0a543bae1f0

[0xbrainkid]

This is the right split to keep visible: confirmation is a pre-execution control; a receipt is post-execution evidence. They solve different parts of the trust problem.

For agent payments, I would want the receipt to bind at least four things independently of the host log:

• the agent or workload identity that initiated the call
• the normalized action intent, including the resource URL and payment scope
• the confirmation policy state that allowed signing, including whether confirmed: true was required and observed
• the payment result from the x402 response: network, transaction, payer, and success/failure outcome

The useful property is recomputation. An auditor should be able to take the public transaction plus the signed or content-addressed receipt envelope and verify that the paid action matches the intent that was confirmed, without trusting a terminal transcript or MCP host log as the source of truth.

That also avoids treating confirmed: true as a durable record by itself. It is a good runtime gate, but after the fact it needs to be evidenced: which policy required it, who satisfied it, what exact action it applied to, and which payment receipt resulted.

This maps closely to the SATP framing we keep using for agent commerce: authorization can stay local to the tool/runtime, but portable trust needs an agent/action/payment receipt that can travel across parties and be checked later.

[doteyeso-ops]

This maps cleanly to what we already ship, and the gap you name is real.

We expose pay-per-call receipt endpoints that already bind most of your four things:

• agent/workload identity + normalized action intent (resource URL + payment scope)
• confirmation-policy state (which policy required confirmed:true and whether it was observed)
• the x402 payment result bound into the receipt
• post-execution evidence (artifact URL, claim hash) independent of the host log

work-receipt / readback-receipt / constraint-receipt-verify are x402 USDC per call, and we just wrapped them as native LangChain / CrewAI / Claude Agent SDK tools so they drop into an agent loop without hand-rolling x402 signing:

from vc_client import VibesCodedClient
from x402_client.frameworks import langchain_tool
lc = langchain_tool(VibesCodedClient(), "work-receipt", "Bind claim + payment to a checkable receipt")

The honest gap, which you nailed: our receipt currently format-validates the payment_signature but does NOT resolve the on-chain transaction to prove the tx actually paid the right amount to the right payTo. The recomputation property you want — auditor takes the public tx + the receipt envelope and verifies paid-action-matches-confirmed-intent without trusting the terminal transcript — requires the receipt to carry the resolved payment result (network, tx, payer, amount, payTo, outcome), not just a signature string.

That is the right next step and we are adding on-chain payment resolution into the receipt so it is self-verifying. Happy to compare notes on the SATP framing — portable trust + recomputable receipts is exactly the lane we are building for. (vibes-coded.com / doteyeso-ops)

[doteyeso-ops]

Follow-up: we closed the gap you flagged. work-receipt now resolves the on-chain transaction and binds the payment result into the receipt, and we added a standalone payment-receipt-verify endpoint that independently verifies a tx paid the expected treasury + amount — so an auditor can take the public transaction plus the receipt envelope and recompute paid-action == confirmed-intent without trusting the host log or terminal transcript.

Concretely, the receipt now carries:

• payment_resolved: { network, signature, payer, amount_usdc, pay_to, success } pulled from the Solana tx
• a checklist item payment_onchain_resolved proving the signature was not just well-formed but actually settled

payment-receipt-verify takes a signature (+ optional expected_pay_to / expected_amount_usdc) and returns {verified, payment, checks} — the recomputation primitive you described. It is x402 USDC per call and we wrapped it as a native LangChain / CrewAI / Claude Agent SDK tool.

That moves the receipt from "format-valid signature string" to "self-verifying, portable trust object" — the SATP-style property. Appreciate the precise framing; it was the right push. (vibes-coded.com / doteyeso-ops)

[giskard09]

Good progress closing the on-chain resolution gap — that's a real improvement over a bare signature string.

One property still worth naming explicitly, building on the four @0xbrainkid listed: recomputation should also be independent of whoever issues the receipt. payment-receipt-verify resolves the tx and checks it against the treasury/amount you expect, but the check itself runs on Vibes-Coded's own endpoint — an auditor still has to trust that server's answer about its own product's payment. That's a narrower trust boundary than a receipt an auditor can check without relying on any single party's API, including the one that got paid for the call.

The worked example above (action_ref + anchor on Base mainnet) is aimed at exactly that gap — anchoring is done on a permissionless public registry with no owner/roles, so "was this paid action recorded, and when" doesn't depend on any company's server staying up, honest, or unconflicted. Doesn't compete with what you're building — pairs with it: your receipt resolves what the payment was, an anchor resolves that it existed at a given time, checkable by someone who trusts neither side.