[Proposal]: Optional Bitcoin-anchored proof-of-when for signed Mandates (extension, outside signed bytes)

[MarkovianProtocol]

AP2 mandates (Intent / Cart / Payment) are verifiable credentials: the signature proves who authorized and what was authorized. The embedded timestamp, though, is asserted by the signer. For chargeback and audit, the contested question is often when: did this mandate exist before the disputed charge, before a price change, before a revocation? A self-asserted clock is weak evidence against a motivated counterparty.

This is distinct from the post-checkout action record in #290 and the settlement-side bindings in #255 / #224. Those record what happened after authorization. The proposal here anchors the authorization artifact itself, and is orthogonal to all of them.

Proposal: attach an optional markovian-provenance/v1 commitment to a mandate as an extension, carried outside the signed bytes so it never affects VC verification. The issuer hashes the canonical mandate, POSTs the hash to an external service, and stores the returned record (a Merkle root plus a BN128 Pedersen commitment, anchored to Bitcoin with a block height). Later, any verifier re-hashes the mandate and checks the anchor with no account. The VC proves who, the anchor adds an independent proof of when.

Honest boundary: this is provenance, not truth. It proves a mandate existed at a point in time, it does not validate the payment, the authority, or the agent's behavior. It is additive, not a replacement for the signature or any settlement attestation, and it requires no change to the mandate schema (an extension field only).

Shape: POST sha256(canonical mandate) to https://api.quantsynth.net/stamp, store {merkle_root, block_height, verify_url} as a mandate extension, verify later at /verify/<root>.

Repo (Apache-2.0): https://github.com/MarkovianProtocol/markovian-protocol
Site: https://markovianprotocol.com

[AmitabhainArunachala]

Operational datapoint from a live mandate-verification endpoint — this proposal closes a real gap we hit in production.

We run a paid /mandate/verify endpoint (Base mainnet, USDC, x402-gated at $0.25) that checks 7 mandate properties: authority, scope/resource binding, spend cap, recipient binding, expiry, nonce/replay protection, and receipt obligation. The expiry check (#5) is exactly the "when" question this proposal addresses: we verify the mandate's self-asserted timestamp against the current block time and reject if expired. But we can only reject late mandates — we cannot prove a mandate existed before a revocation or price change, because the timestamp is self-asserted and the signer controls it.

That is the precise boundary the markovian-provenance/v1 extension fills. The 7-check matrix answers "is this mandate valid right now?" The Bitcoin-anchored commitment answers "did this mandate exist at the claimed time?" — and the two are orthogonal by design, which is the right decomposition. A mandate that passes all 7 checks but was backdated after a price change would slip through our verifier; the anchor commitment is what stops that.

One integration question: the proposal says the hash is posted to an external service and stored as a mandate extension. For an AP2 verifier consuming this, the question is whether verify_url should be resolvable by an agent programmatically (machine-readable JSON) vs. a human-facing page. Our /mandate/verify returns a structured JSON verdict with a tier (REJECT/REVIEW/ACCEPT) and per-check pass/fail — if the provenance anchor were checkable the same way (programmatic JSON, no account), we could wire it as check #8 in the matrix without changing the mandate schema.

If you have a sample anchored mandate (canonical hash + the {merkle_root, block_height, verify_url} record), send it — we'll run it through the matrix and confirm the integration path. The endpoint is https://x402.167-172-95-184.nip.io/mandate/verify (POST, $0.25 on Base/USDC).