Agentic Payments on Miden

[Dominik1999]

Building Agentic Payments Support on Miden

Overview

This doc suggests what to build and why. The goal is native support for the primary agentic payment protocols on Miden, positioning Miden as a privacy-preserving settlement layer for autonomous agent transactions, with Guardian-enforced authorization as the technical differentiator.

Background: three categories of agentic payments

The agentic payments space spans three categories with very different dynamics. Understanding which one we're targeting matters for design decisions.

Agent-to-Service (M2M). An agent calls an API and pays per request. Currently the most active category. Coinbase reports 140M x402 transactions. MPP launched March 2026 with 100+ adopters including Anthropic, OpenAI, Shopify, Alchemy, Dune, Browserbase, Parallel Web Systems. AWS shipped AgentCore Payments and CloudFront x402 reference architecture in March. Sub-dollar transactions, sub-second settlement, machines on both sides.

Agent-to-Merchant (e-commerce). Agent buys consumer products from merchants. Live via ChatGPT Instant Checkout with Walmart, Target, Sephora and others. Flows through ACP and settles in fiat via Stripe. The merchant is locked to their existing payment processor. Hard to get it tbh, because Stripe settles crypto vs. Fiat in the end and they won't accept Miden payments (today).

Agent-to-Agent. Two autonomous agents transacting directly. Mostly aspirational today. Real production volumes are not reported. Not realistic future bs.

We're targeting M2M. Reasons: real volume today, settlement choice is genuinely open (API providers choose what they accept, unlike merchants who are locked to Stripe), privacy actually matters (agent API call patterns reveal strategy and customer lists), and buyers are addressable.

For the future, we also target e-commerce.

The full agentic commerce stack has four layers. We touch two.

1. Commerce layer. Product discovery, cart, checkout. Owned by ACP (OpenAI/Stripe) and UCP (Google/Shopify). Off-chain. Not relevant.
2. Authorization layer. Mandates that authorize an agent to act on behalf of a user. Owned by AP2. This is where Guardian fits.
3. Payment layer. HTTP 402 negotiation, signed credentials, receipts. Owned by x402 and MPP.
4. Settlement layer. Where the money actually lands. Tempo, Base, Solana, Miden, or fiat via Stripe.

Our work lives at layers 2 (Guardian-as-mandate via AP2) and 4 (Miden as settlement chain). The x402 and MPP work at layer 3 is the integration glue that makes layer 4 reachable.

Scope of work

Four deliverables, in priority order.

1. x402 facilitator on Miden

x402 is the crypto-native HTTP 402 protocol from Coinbase, open-sourced under Apache 2.0.

Flow:

1. Agent requests a resource from a paid endpoint
2. Server responds with 402 Payment Required plus payment details
3. Agent constructs a payment payload, resends the request with a PAYMENT-SIGNATURE header
4. Facilitator (our work) verifies the payment on Miden
5. Server delivers the resource

Build:

• x402 facilitator that verifies USDC payments on Miden (USDM as fallback)
• Reference merchant endpoint (Python and Node) that integrates with the facilitator
• Reference agent client that pays the merchant
• Working end-to-end demo: agent pays a test API service privately, receipt is verifiable, transaction graph is not exposed

2. MPP integration

MPP is Stripe and Tempo's machine payments protocol. Similar 402-based flow, broader payment method support, on the IETF track.

Three implementation levels exist in the spec:

• One-shot payments (tagged stablecoin transfer with challenge ID)
• Session-based streaming via onchain escrow contracts (state channels)
• Gasless execution via relayed transactions

For this initial work, build level 1 only. Onchain escrow for streaming vouchers is significant additional engineering and is out of scope for now.

Build:

• MPP one-shot payment support on Miden
• SDK skeleton in TypeScript and Python (these are the mppx target languages)
• Documentation showing how to integrate

3. AP2 + Guardian integration

AP2 is Google's agent payments protocol. It defines verifiable digital credentials that encode delegated authority: spend limits, time windows, merchant allowlists, transaction categories. The standard implementation pattern is "merchant verifies the mandate signature, decides whether to accept."

Our implementation pattern is different and is the technical wedge: Guardian co-signs every transaction, and the Guardian signing policy directly encodes AP2 mandate conditions. Authorization is enforced at the chain layer, not the application layer.

What this means in practice:

• A Miden transaction without valid Guardian co-signature does not settle
• Mandate violations are rejected by the chain, not by the merchant
• The mandate chain (user signed mandate, then Guardian-enforced policy, then transaction) is auditable end-to-end
• Privacy and mandate enforcement compose, because Guardian sees what others don't

Build:

• AP2 mandate parsing on Miden (W3C VDC standard)
• Guardian policy module that ingests an AP2 mandate and translates it to a signing policy
• Reference flow: user signs AP2 mandate, agent constructs transaction within mandate bounds, Guardian co-signs, transaction settles. Same flow attempted outside mandate bounds is rejected by Guardian.

4. Benchmarks

Once the above is working, produce a benchmark matrix comparing Miden against the main alternatives.

Chains to benchmark:

• Miden (our implementation)
• Tempo (Stripe and Paradigm's payments-first L1, mainnet live March 2026)
• Base (Coinbase L2, the default x402 settlement chain)
• MultiversX (shipped MPP integration with three-tier architecture in March)

Metrics to measure:

• Transactions per second under sustained agent workload
• End-to-end latency from 402 response to receipt
• Cost per transaction in USD
• Privacy properties: what's visible onchain, and to whom

Workload should be a realistic M2M pattern, not synthetic stress testing. Suggested reference workload: an agent making sequential API calls of varying cost, mixed payment methods, occasional mandate validation.

Why this matters: the settlement adoption challenge

Important context for design decisions.

Today's M2M flow: agent pays in USDC on Base via x402, or pays via MPP with Stripe converting to fiat at the boundary. The API provider gets paid in their existing rail and doesn't care which chain settled it.

For Miden to actually be a settlement layer, three things need to work:

1. API providers must accept Miden settlement specifically, not just "stablecoin"
2. A facilitator must verify Miden payments (this is what we're building)
3. Agent infrastructure (Crossmint, Skyfire, Payman, Nevermined) must be able to construct Miden transactions

Implication for design: the SDKs and facilitator need to be drop-in easy. If integrating Miden takes more effort than integrating Base, providers won't bother. Target: an API provider should be able to add Miden as an accepted settlement chain in under an hour, given they already accept x402 elsewhere.

The privacy story is what gets providers to consider Miden in the first place. The integration ease is what gets them to actually ship.

Out of scope

Explicit list to avoid ambiguity:

• ACP and UCP merchant checkout protocols
• Google A2A agent coordination protocol
• ERC-8004 agent identity registry
• MPP streaming vouchers and onchain escrow contracts
• Card or Lightning payment method support in MPP
• Frontend or dashboard work

References

• x402 spec: x402.org
• x402 reference implementation: github.com/coinbase/x402
• MPP announcement and integration guide: stripe.com/blog/machine-payments-protocol
• AP2: Google's agent payments protocol (W3C Verifiable Credentials based)
• MultiversX MPP implementation (closest comparable, useful for benchmarking and design reference): multiversx.com/blog/stripes-machine-payments-protocol-on-multiversx
• AWS x402 reference architecture: aws.amazon.com/blogs/industries/x402-and-agentic-commerce-redefining-autonomous-payments-in-financial-services

[bobbinth]

Thank you for writing this up! For now, just commenting about x402 part:

There was a pretty in-depth discussion about how to support x402 on Miden here: 0xMiden/node#1796. Key takeaways from it (at least for me) summarized in 0xMiden/node#1796 (comment):

• If the latency between 5 and 10 seconds is acceptable, the design with using private notes and sending note inclusion proofs via the retry header, would probably be the best option.
• If this latency is not acceptable, then we need some kind of state channel-based solution, and this could be a good time to start research in this direction.

So, I think one of the main questions is whether we are OK with 5 - 10 second latency (at least initially).

---

I think one of the nice aspects in how agentic payments could interact with the Guardian-based architecture is the following (and I think you mention similar above):

In the setup of 1 hot key + 1 cold key + 1 guardian key, we could give the agent the hot key and not worry too much about the downside because all agent actions can be monitored/assessed by the guardian which could enforce very sophisticated rules. So, the downside to the agent doing something wrong is pretty limited. And not all of this needs to be enforced by on-chain code - some basic things could be, but the Guardian could go way beyond what's possible with on-chain code too.

[ermvrs]

I am currently developing an example facilitator. There won't be any problem with public notes but yes on private notes we need a decision. Also @Dominik1999 is private payment must for first scope? Or a demo with public is good enough before 0.15

[Dominik1999]

Wow I totally missed this 0xMiden/node#1796.

So, we need a private note payment for sure. Otherwise we are not competitive. We would be public as Base, but slower. The question is, what is the fastest we can get? I don't fully understand where the 5-10s come from. According to the design in #1796, the user just creates a private note and sends it to a server / facilitator if I am not mistaken.

[bobbinth]

The latency is driven by the need to get the note included into a block. Just sending the note is not enough - the facilitator (or anyone else), needs to know that the transaction was actually submitted and included in a block (otherwise, the user could build a transaction, and never submit it).

And 5 - 10 seconds breaks down as follows:

• 1 - 2 seconds to prove a transaction (could potentially be much lower).
• 2 - 3 seconds for a transaction to make it into a batch.
• 2 - 3 seconds for batch to be included in in a block.

So, if we need to get below 5 seconds, we need to come up with a way for a user to guarantee that the transaction but w/o having the transaction on-chain yet.

[Dominik1999]

Idea: Guardian as x402 Facilitator (Batched Settlement)

Following the latency discussion in node#1796, I want to float an architectural alternative that I think collapses three roles into the Guardian and changes our competitive position on M2M latency.

The pattern

Standard x402 on Miden (per Digine-Labs/miden-x402): agent constructs note, proves locally, submits to network, waits for block inclusion, sends {note_id, inclusion_proof} to merchant, merchant verifies via the facilitator. End-to-end ~5-10s, dominated by proving + block time. Settled-at-commit model: a P2ID note in a committed block is the settlement event, and the facilitator is a read-only verifier.

Standard x402 on Base: agent signs an EIP-3009 authorization, facilitator verifies signature, merchant delivers, facilitator settles on-chain async. Sub-second perceived latency, but trust assumption that facilitator submits and merchant delivers.

Proposed pattern: use the Guardian as the x402 facilitator with batched settlement.

The 402 response follows the standard x402 spec structure, with Miden-specific note parameters carried in the extra field:

{
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "miden-p2id-private",
      "network": "miden-mainnet",
      "payTo": "<recipient_account_id>",
      "asset": "<faucet_id>",
      "maxAmountRequired": "100000",
      "resource": "https://api.example.com/premium",
      "maxTimeoutSeconds": 60,
      "extra": {
        "note_tag": "<tag>",
        "serial_num": "<server_generated>"
      }
    }
  ]
}

Agent                Guardian-Facilitator             Merchant
  |                          |                           |
  |-- GET /resource ------------------------------------>|
  |<- 402 (standard x402 with Miden scheme in accepts) --|
  |                          |                           |
  | Build private P2ID note  |                           |
  | + sign tx (NOT proven)   |                           |
  |                          |                           |
  |-- Signed unproven note ->|                           |
  |                          |                           |
  |       Verify: signature valid, note matches 402,     |
  |       agent has balance?, mandate satisfied,         |
  |       input note reserved (nullifier lock)           |
  |                          |                           |
  |                          |-- Verification OK ------->|
  |                          |                           |
  |<-- Resource delivered -------------------------------|
  |                          |                           |
  |                          |<-- Resource delivered ----|
  |                          |                           |
  |       Batch with other pending payments              |
  |       Co-sign + prove batch                          |
  |       Submit batch to network                        |

The merchant's trust model here is the same as on Base: trust the facilitator's verification message and deliver. The merchant does not independently verify on-chain inclusion at delivery time. Batch settlement produces an auditable on-chain record post-hoc, useful for accounting and reconciliation but not on the critical path.

Why so?

Same trust assumptions as Base, better latency profile. The agent trusts the Guardian (which it already does, by definition of Guardian). The merchant trusts the Guardian to settle (same trust model as trusting Coinbase's CDP facilitator). No new trust assumptions added, one trust assumption reused.

Proving moves off the critical path. Steps 1-5 take maybe 200-500ms. Proving and settlement happen asynchronously, amortized across a batch. Per-transaction proving cost drops to 1/N. This is what makes sub-cent micropayments economically viable.

Guardian is doing 3 jobs at once. Mandate enforcement (already), payment verification (new), batch settlement (new). For users who already have a Guardian, the facilitator role comes for free. For Guardian operators, this is a new revenue stream that fits the "custody economics without custody liability" framing of Phase 1b.

Privacy doesn't degrade. Guardian sees its users' transactions (it would anyway). Merchant sees {note_id, inclusion_proof} post-batch. No facilitator-as-privacy-leak issue that exists when a third party like Coinbase facilitates across all merchants.

Competition

Right now our honest benchmark story is "Miden settles privately in 5-10s, Tempo in ~500ms, Base in ~2-4s." That's cool, but we can do better.

With Guardian-as-facilitator the story becomes "Miden settles privately with sub-second perceived latency. Faster and more private than base and tempo." That sounds better if we make it happen :).

Open question

1. Nullifier reservation for verify-before-prove. To prevent the Guardian from verifying two transactions that consume the same input note, the Guardian maintains an in-memory reserved_nullifiers set:

• At verify time, compute the nullifiers the note would produce
• If any are already in the reserved set, reject (agent is trying to double-spend in the pending window)
• Otherwise add them to the reserved set and continue
• On batch settlement success, nullifiers move from "reserved" to spent (and are now on-chain via the batch tx)
• On batch settlement failure or timeout, release the reservations

This is structurally the same mechanism EIP-3009 (the basis for x402) uses with nonces, just enforced at the Guardian rather than the contract. Since the Guardian co-signs anyway, it's the natural serialization point for the agent's pending transactions.

Does that make sense? (@bobbinth, @partylikeits1983, @ermvrs, @Mirko-von-Leipzig )

Plan

For the next 4 weeks: Miden team / Digine Labs operates one Guardian with a facilitator module as the reference implementation. Single endpoint (e.g. facilitator.miden.io), branded as Miden. Merchants integrate against it the same way they integrate against Coinbase's CDP.

For year 1: package the facilitator module as a drop-in component that existing x402 facilitator operators (PayAI, Dexter, x402.rs) can integrate to add Miden as a supported chain. They already run facilitator infrastructure across Base, Solana, Polygon. Adding Miden is a module, not a new operation. This is how we get to facilitator diversity without asking anyone to stand up a Guardian.

[partylikeits1983]

Big +1 on Guardian-as-facilitator. One thing that is still needed is a standard for the x402 note, below is a brief outline of essentially what I presented at the technical offsite.

Concrete shape for the x402 note that makes the verify step enforceable in the note itself, not just a Guardian-side policy check:

Model it on PSWAP (crates/miden-standards/src/note/pswap.rs + asm/standards/notes/pswap.masm). PSWAP already does the two-outputs-on-consumption pattern we want: consuming one note emits (a) a P2ID note to a target and (b) a remainder note carrying the unfilled balance.

For x402, the agent funds an x402 note with some ASSET; consuming it emits a P2ID note to the merchant/recipient for the charged amount, and an x402 remainder note with the change. That remainder roll-forward is a good fit for the sequential-API-call M2M workload - one funded note covers many calls.

The twist vs PSWAP: the x402 note script would require two signatures to release funds - signature_creator (the agent) and signature_guardian (might be possible to not have the signature of the guardian for the x402 note) - each over h(ASSET, NOTE), where NOTE is the exact P2ID note (recipient + amount) being created. Both come in via the advice map: note storage/args carry only commitments, and the script pulls the signatures and the destination-note preimage from the advice provider. This puts the Guardian co-signature into the note's own consumption rule - a payment can't settle unless the Guardian signed off on that specific (asset, destination) pair, which is exactly where AP2 mandate enforcement (deliverable 3) bites.

On open question 1:

agreed, the Guardian holding an in-memory reserved_nullifiers set is probably the right call - though it might be better kept in the storage of the facilitator account than purely in-memory, so it's durable. Related open question the proposal doesn't pin down: which account actually consumes the x402 notes? That facilitator account isn't named, and it determines where the nullifier set lives and who the on-chain settling party is.

[ermvrs]

Repo: Miden x402

What's shipped

Phase A — settled-at-commit, public + private P2ID (the standard x402
flow from Scope 1 of the original post):

• Read-only facilitator (/verify, /settle, /supported, /health)
  against Miden testnet — 11 verification rules in a single unified
  pipeline handling both noteType: "public" and noteType: "private".
• Private-note binding works by base64-encoding the canonical NoteFile
  in the Payment-Signature header, decoding it server-side, recomputing
  the noteId from the off-chain blob, and using GetNotesById to
  resolve FetchedNote::Private(NoteHeader, NoteInclusionProof) on
  chain. The recomputed-noteId equality is the cryptographic bind.
• Node + Python merchant SDKs, Node agent SDK using
  @miden-sdk/miden-sdk, four end-to-end demos (Express, Hono, FastAPI,
  Flask). Live testnet smoke binary.

Phase B — Guardian verify-before-prove + nullifier reservation
(implements the architecture from @Dominik1999's "Guardian as x402
Facilitator" comment):

• New endpoints: POST /guardian/challenge (issues server-generated
  serial_num), POST /guardian/verify, POST /guardian/settle.
• Server-generated serial_num: at 402-time the merchant calls the
  facilitator's /guardian/challenge, which generates a 32-byte
  serial_num and stores it in a TTL'd map. The buyer must use that
  exact value when constructing the P2ID, so the Guardian knows the
  future nullifier before any signed payload reaches it.
• Offline Falcon signature verification: the wire payload carries
  txInputs (canonical TransactionInputs), signature
  (miden_protocol::account::auth::Signature), and signedSummary
  (TransactionSummary — needed separately because the salt is
  kernel-generated and not derivable from TransactionInputs alone).
  The Guardian extracts the buyer's PublicKeyCommitment from
  tx_inputs.account().storage() via the AuthSingleSig slot, binds
  the wire Signature to the on-chain commitment via Poseidon2 hash
  equality, then runs the standalone Falcon verify.
• Nullifier reservation: atomic try_reserve_all with all-or-nothing
  rollback, promote_to_consumed on settle success, release on
  failure, TTL sweeper.
• Synchronous prove-and-submit via RemoteTransactionProver::prove
  then submit_proven_transaction.

86 Rust tests passing. Public/Phase-A path is byte-for-byte
regression-free — the /guardian/* endpoints are mounted only when
MIDEN_X402_GUARDIAN_ENABLED=true.

What we deliberately didn't build

These are gaps relative to the architecture described in this thread, all
intentional, all blocked on decisions we'd like the team's input on:

1. Guardian co-signing. Our Guardian verifies the buyer's single
   Falcon signature and submits — it doesn't co-sign. The "Miden
   transaction without valid Guardian co-signature does not settle"
   property from Scope 3 of the original post is not satisfied.
2. Batched settlement. We do synchronous prove-and-submit per
   request. The "1/N proving cost" amortization claim is not delivered.
3. AP2 mandate enforcement. No mandate parsing, no policy hooks.
   This is Scope 3 territory.
4. Custom x402 note type (@partylikeits1983's PSWAP-derived
   proposal). We use vanilla P2idNote from miden-standards. The
   note's script does not enforce dual signatures.
5. Durability of the reserved-nullifier set. It's in-memory in a
   single process — fine for the reference deployment, not production.

We also took one deliberate divergence from @Dominik1999's wire example:
we use scheme: "exact" with extra.settlement: "guardian-fast"
instead of scheme: "miden-p2id-private". Reason: keep the same scheme
across public, private, and Guardian flows so SDKs don't fork their
dispatch. Easy to change if the team prefers the distinct scheme name.

Open questions we need your input on

Q1 — Which architectural direction do you want for Guardian
co-signing? This is the biggest open call. Three options seem viable
to us:

(a) AuthMultisig 2-of-2 on the buyer's account. Available today from
miden-standards/src/account/auth/multisig.rs. Threshold enforced by
the account's MASM. Caveat: BasicAuthenticator signs locally — a
remote Guardian sign needs a custom TransactionAuthenticator
implementation. Buyers also need to deploy multisig accounts up front,
which is friction for ephemeral agent accounts.

(b) Custom x402 note modelled on PSWAP, per @partylikeits1983's reply.
The note script reads signature_creator + signature_guardian from
the advice map and verifies both before consumption. Buyers stay
single-sig; the two-outputs-on-consumption pattern also unlocks "one
funded note serves many sequential API calls" for the M2M workload.
Substantially more new MASM than (a).

(c) Status quo — Guardian-as-facilitator with no co-signing. Mandate
violations would be enforced at the Guardian layer (refuse to submit),
not the chain layer. Less work, but doesn't satisfy the "rejected by the
chain" framing from the original Scope 3.

We can implement any of these; we'd rather not pick the wrong one
unilaterally. Strong opinions welcome.

Q2 — Which account consumes the x402 notes? @partylikeits1983 raised
this and we didn't see a resolution in the thread. Our current Phase B
keeps the merchant as the consumer (matches Phase A semantics). If you
go with the PSWAP-style note (Q1.b), the consumer is naturally a
Guardian-owned account, which changes who pays the consumption gas and
where the on-chain settling party shows up. Worth pinning down before
the note type is built.

Q3 — Durability of the reserved-nullifier set. Three options:

(a) In-memory (what we have). Restart wipes pending reservations.
(b) External durable store (Redis / Postgres). Standard.
(c) On-chain in the facilitator account's storage, per
@partylikeits1983's suggestion. Most durable but costs a tx per
reservation — only viable if reservations are batched.

We'd recommend (b) for production; flagging in case (c) is the
preferred direction once the consuming-account question is settled.

Q4 — Should we keep the unified scheme: "exact" + extra.settlement
or switch to scheme: "miden-p2id-private" for the Guardian flow?
Purely a naming/wire-shape call; happy either way.

Happy to take any of this through implementation once we have answers.
The repo is set up so swapping the auth model is mostly contained to
the guardian/ module + the buyer-side WASM SDK path (which has its
own known gaps for producing signed-but-unproven transactions — that's
a separate miden-client extension we'd want to coordinate on).

cc @Dominik1999 @bobbinth @partylikeits1983

[Dominik1999]

Update: Prefunded Agent Debit Notes for Guardian-Facilitated Payments

Coming back to the design after thinking through the actor-model implications with @partylikeits1983 . The "agent signs unproven tx" pattern I proposed earlier doesn't work in Miden, and Digine-Labs' planned guardianFast variant has the same issue. Worth being explicit about why, then proposing a different approach.

Why "agent signs unproven tx" fails

A signed-but-unproven Miden transaction commits to a specific account state. The proof, when eventually generated, must verify against that exact state. So between sign-time and prove-time:

• The agent's account state cannot change for any reason
• If it does change (consumes another note, receives a note, anything), the signed tx becomes unprovable
• Locking the agent's account between sign and prove means one in-flight payment = agent is frozen

This is structurally the same problem Digine-Labs' guardianFast variant has. The signedSummary field commits to specific txInputs that must remain valid until the Guardian proves. Same lock-or-fail dilemma.

So the design needs to avoid the agent's account state being on the critical path.

Proposed pattern: prefunded agent debit notes

Instead of the agent signing tx authorizations, the user prefunds a custom AgentDebitNote that the Guardian can consume on the agent's instruction. Conceptually a payment channel without bidirectional updates, or a prepaid debit card, or a UTXO chain where each payment splits the UTXO. Established mental model.

Setup happens once. Per-payment, the agent signs only a consumption authorization. No account state involvement, no kernel execution, no proving.

Lifecycle

========================================================================
PHASE 1: SETUP (once per agent, off the critical path)
========================================================================

User Account                                              Agent
  |                                                         |
  | Create AgentDebitNote(value=100 USDC)                   |
  |   script: "consumable on (agent_sig + guardian_sig),    |
  |            outputs must be exactly:                     |
  |              P2ID(merchant, amount=x) +                 |
  |              AgentDebitNote(value=V-x, same script)"    |
  |   storage: agent_pubkey, guardian_pubkey                |
  |   noteType: private                                     |
  |                                                         |
  |-- prove + submit tx --------------- chain --------------|
  |                                                         |
  |-- note_id --------------------------------------------->|


========================================================================
PHASE 2: PER-PAYMENT (hot path, target sub-second)
========================================================================

Agent              Guardian-Facilitator                  Merchant
  |                        |                                |
  |-- GET /resource ----------------------------------------|
  |<-- 402 (x402 + Miden scheme) ---------------------------|
  |                        |                                |
  | sign(consume(          |                                |
  |   note_id,             |                                |
  |   merchant=payTo,      |                                |
  |   amount=x))           |                                |
  |                        |                                |
  |-- {note_id, merchant,  |                                |
  |    amount, agent_sig}->|                                |
  |                        |                                |
  |    Verify agent_sig against note's agent_pubkey         |
  |    Check mandate (limits, allowlists, time windows)     |
  |    Check note remaining balance >= amount               |
  |    Check note nullifier not reserved                    |
  |    Reserve nullifier (in-memory)                        |
  |                        |                                |
  |                        |-- x402 /verify OK ------------>|
  |                        |                                |
  |                        |<-- OK ------------------------ |
  |<-- resource ------------------------------------------- |


========================================================================
PHASE 3: BATCH SETTLEMENT (async, off the critical path)
========================================================================

Guardian                                                  Chain
  |                                                         |
  | Collect N pending consumptions over batch window        |
  | Construct batch tx executed by Guardian's account:      |
  |   consume(note_1, ..., note_N)                          |
  |   outputs:                                              |
  |     P2ID_1 -> merchant_1, ..., P2ID_N -> merchant_N     |
  |     remainder_1, ..., remainder_N (new AgentDebitNotes) |
  |                                                         |
  | Guardian co-signs + STARK proves the batch              |
  |                                                         |
  |-- submit batch tx ------------------------------------->|
  |<-- block inclusion -------------------------------------|
  |                                                         |
  | Move nullifiers from "reserved" to spent                |
  |                                                         |
  |-- new note_ids per agent -------------------> Agents.   |


========================================================================
PHASE 4: REFUND (when user wants funds back)
========================================================================

User              Guardian                                Chain
  |                   |                                     |
  |-- request ------> |                                     |
  |                   |                                     |
  |   Consume current remainder note                        |
  |   Output: P2ID to user_account for remaining_balance    |
  |   Requires Guardian co-sig (user-initiated refund)      |
  |                   |                                     |
  |                   |-- prove + submit ------------------>|
  |                   |<-- block inclusion -----------------|
  |                   |                                     |
  |<-- USDC in user account ---|

Why this works

No agent account state on the critical path. The agent's signature authorizes consumption of an immutable note. The agent's account is uninvolved. Sign-time and prove-time can be arbitrarily far apart without invalidation. This is the core insight that makes the pattern viable.

No agent-side proving or kernel execution. Agent just signs {note_id, merchant, amount} with its key. EIP-3009-level simplicity for thin agents. Crossmint, Skyfire, Payman can integrate without shipping a full Miden client.

Merchant compatibility preserved. The output is a standard P2ID note to the merchant. From the merchant's side, x402 verification looks identical to Digine-Labs' existing noteType: "private" flow. No facilitator changes needed downstream.

Privacy preserved. AgentDebitNote and remainders are private. Only commitments on chain. Same privacy posture as the existing private P2ID flow.

Mandate enforcement composes. Guardian's signing policy enforces AP2 mandates before co-signing the batch consumption. The note script can also encode hard limits (per-tx max, daily caps) as a belt-and-braces layer.

Revocation is built in. The note script requires both agent_sig AND guardian_sig for consumption. User-initiated revocation = Guardian refuses to co-sign = note becomes unconsumable. Agent key compromise alone cannot drain funds. This is stronger than EIP-3009, which has no revocation primitive once a signature exists.

How does the AgentDebitNote look like?

The note is pretty similar to a Pswap note.

@ermvrs you should be able to write a Rust or even a MASM version of this. I am also more than happy to help.

[Mirko-von-Leipzig]

iirc we've had this debit card note idea before (and by we I mean @partylikeits1983 or @PhilippGackstatter). Is there sense in making this a standard of sorts, or is the agent pub key overly specific/restricted?

I guess that's also something we can think over for the future i.e. doesn't have to be standardized now.

[Dominik1999]

True, I got the idea form @partylikeits1983 ... if it works, we should standardize

[bobbinth]

I'm not sure I see the a lot of benefit of this design over the one described in #2919 (comment) above. And this design feels a bit more complicated because we need to introduce the AgentDebitNote and guardians need to know how to handle it. Though, the other approach does require some additional changes in the client/wallet.

Why "agent signs unproven tx" fails

A signed-but-unproven Miden transaction commits to a specific account state. The proof, when eventually generated, must verify against that exact state. So between sign-time and prove-time:

• The agent's account state cannot change for any reason
• If it does change (consumes another note, receives a note, anything), the signed tx becomes unprovable
• Locking the agent's account between sign and prove means one in-flight payment = agent is frozen

I don't think these are correct in the guardian-based setting. To go over this point by point:

• The user can absolutely build transactions on top of unproven/uncommitted state. As long as all transactions are ordered sequentially (i.e., there are no "forks" in the account state) there should be no logical issues - e.g., tx1 changes the state from A to B, tx2 changes the state from B to C etc.
• As long as the state change happens on top of the most recent state - that shouldn't be an issue.
• There is no need to lock the agent as explained above - we can always build a transaction on top of the latest valid state.

The above only works if user cannot introduce "forks" in the account state, but since we have the guardian, it can take care of it. The flow would work like this:

• The user builds/signs tx1 (account state change A -> B) and sends it to the guardian.
• The guardian accepts the transaction, signs it, and updates the state of the account to B.
• The user considers B to be a "pending" state until they see the state update on-chain, but they can still build transactions on top of this state.
• So, the user builds/signs tx2 (account state changes B -> C) and sends this transaction to the guardian.
• The guardian makes sure that the initial state of the account is B and then updates the state it tracks to C.
• At some point later (e.g., in 5 mins or in 1 hour), the guardian builds a batch that includes both tx1 and tx2 (the guardian would need to generate tx proofs before this), and submits it to the network.
• Once the user sees that tx1 and tx2 landed on-chain, it'll mark state C as "committed".

The above does require making some changes in the client/wallet and the Guardian. Specifically:

• We need to introduce the option to invert the flow of transaction. So, instead of "user gets a signature from guardian and the send tx to the network", we'll need "user builds and signs a tx, and the guardian proves and sends the tx to the network". But I think we need to do this anyway.
• We need to update the client to handle in-flight states and allow the client to build transactions on top of the latest state even if it hasn't appeared on-chain yet. But again, I think we'll need to make such changes anyways (and maybe some parts of this are already working). cc @igamigo

[igamigo]

We need to update the client to handle in-flight states and allow the client to build transactions on top of the latest state even if it hasn't appeared on-chain yet. But again, I think we'll need to make such changes anyways (and maybe some parts of this are already working). cc @igamigo

This indeed already works and has been working for a while. The user can execute an arbitrary amount of transactions on top of non-finalized states (from the perspective of the client). The new states are pending until a sync loop confirms that transactions made it to a block. If, on a sequence of 5 transactions, the third one gets rejected for whatever reason, the client-canonical state of the account will be rolled back to that one that resulted from executing the second transaction in the sequence. So, any new transactions will be built on top of that one after the sync.

Sharing the intermediate, non-confirmed states is a separate problem but would be the work of something like the guardian. This should be enough, but let me know if that's not the case.

[Dominik1999]

Proposed Design: Guardian-as-Facilitator for x402 on Miden

Following @bobbinth's clarification on in-flight state, this is a concrete proposal that builds on the original sketch without requiring protocol changes. The goal is sub-second perceived latency for x402 payments on Miden by moving proving off the agent's critical path and into a Guardian-operated facilitator.

The pattern reuses primitives that already exist (the multisig PoC ships a "sign-without-prove" client and a coordinator that batches and submits) and applies them to the agent-payment shape. No new note types, no new account types, no MASM changes.

Detailed flow

========================================================================
SETUP (once)
========================================================================

User creates agent account on Miden with two keys:
  - hot key (held by agent, used for signing payment txs)
  - cold key + Guardian co-sig required for any out-of-mandate action
User signs AP2 mandate, sends to Agentic Guardian
Agentic Guardian stores mandate, registers agent account


========================================================================
PER-PAYMENT (hot path, target sub-second perceived latency)
========================================================================

Agent             Agentic Client       Agentic Guardian          Merchant
  |                     |                     |                     |
  |-- GET /resource ----------------------------------------------->|
  |<-- 402 (x402 + Miden scheme in accepts) ------------------------|
  |                     |                     |                     |
  | Construct tx        |                     |                     |
  | against latest      |                     |                     |
  | pending state       |                     |                     |
  | Sign with hot key   |                     |                     |
  |                     |                     |                     |
  |-- signed unproven tx + 402 context ------>|                     |
  |                     |                     |                     |
  |                     |   1. Check initial_state matches latest   |
  |                     |      pending state for this agent         |
  |                     |   2. Verify hot-key signature             |
  |                     |   3. Check tx output: P2ID to merchant,   |
  |                     |      amount and asset match 402           |
  |                     |   4. Check AP2 mandate satisfied          |
  |                     |      (amount cap, merchant allowlist,     |
  |                     |       time window, daily total)           |
  |                     |   5. Compute output nullifiers            |
  |                     |   6. Check none are in reserved_nullifiers|
  |                     |   7. Reserve nullifiers (WAL persisted)   |
  |                     |   8. Advance pending state for this agent |
  |                     |                     |                     |
  |                     |<-- ack (tx accepted, pending state = X) --|
  |                     |                     |                     |
  |                     |        |-- x402 /verify OK -------------->|
  |                     |        |                                  |
  |                     |        |<-- 200 OK + resource ------------|
  |<-- resource ---------------------------------------------------|


========================================================================
BATCH SETTLEMENT (async, off the critical path)
========================================================================

Agentic Guardian                                              Chain
  |                                                            |
  | Every N seconds or M pending txs:                          |
  |   1. Take snapshot of pending txs across all agents        |
  |   2. Order them per agent (preserve state-transition order)|
  |   3. Generate STARK proofs (in parallel, per tx)           |
  |   4. Assemble batch tx submission                          |
  |                                                            |
  |-- submit proven txs -------------------------------------->|
  |                                                            |
  |<-- block inclusion confirmation ---------------------------|
  |                                                            |
  |   5. Move nullifiers from reserved -> spent                |
  |   6. Mark pending states as committed                      |
  |   7. Notify Agentic Clients of commitment                  |


========================================================================
FAILURE RECOVERY
========================================================================

If batch fails on submission (e.g. one tx invalid):
  - Identify failing tx, isolate it
  - Resubmit remaining batch
  - Release nullifiers reserved by failing tx
  - Notify Agentic Client of failure for that specific tx

If Agentic Guardian crashes:
  - Recover reserved_nullifiers from WAL
  - Recover pending state from persistent store
  - Replay any in-flight txs not yet committed

What changes where

No Miden protocol changes. No new note types. No new account types. The work splits cleanly into two components.

---

1. miden-agentic-client

A new client crate (or extension of miden-client) that handles the agent-side flow. The reference architecture already exists in miden-multisig-client, which implements the same "sign without prove, send to coordinator" pattern for the human multisig case.

The multisig client is human-paced (collect N-of-M signatures from humans over minutes/hours). The agentic client needs the same architectural shape adapted for machine pace: one signer, sub-second cadence, many concurrent in-flight txs.

What it must do:

• Sign-only mode. Construct a transaction, sign with the agent's hot key, do not prove. Serialize the signed-but-unproven tx for transmission.
• Track pending state per agent account. After sending a signed tx to the Guardian and receiving ack, advance the client's view of the agent's account state. The next tx must be constructed against this pending state, not the on-chain committed state.
• Handle multiple in-flight txs. Bobbin's clarification is the foundational point: as long as the Guardian is the single serialization authority, no forks are possible, so the client can keep building on pending state without risk of invalidation.
• Reconcile with on-chain commitment. When the Guardian reports a tx as committed, mark that state transition as final. If a tx fails, roll back the pending state.
• Light footprint. Agent infrastructure (Crossmint, Skyfire, Payman) should be able to embed this in constrained environments. No proving keys, no kernel execution at runtime, just key management and state tracking.

Open decision: extend miden-client with a sign-only mode, or ship a separate miden-agentic-client crate that wraps the core client. The multisig precedent is "separate crate that wraps." Arguments either way:

• Separate crate: clear boundaries, doesn't burden core client users with agent-specific state machine
• Core integration: sign-only mode is generally useful (mobile, browser, any constrained signer), agentic-client becomes a thin wrapper that adds the high-throughput pending-state tracking

Needs input from @igamigo on which factoring fits the core client roadmap.

---

2. agentic-guardian (or extension of OpenZeppelin Guardian)

Likely a fork or extension of OpenZeppelin Guardian plus the coordinator server pattern from the multisig PoC. The coordinator server is roughly the right shape (Rust/Axum, REST API, PostgreSQL persistence, accepts proposals, batches, submits to network). It needs adapting for the agent-payment workload.

What it must do:

• Accept signed unproven txs. New endpoint that takes a serialized signed tx, validates the signature against the registered agent's hot key, and queues for batch settlement.
• Per-agent pending state tracking. Maintain the latest acknowledged state for each registered agent account. Reject txs that don't build on the latest pending state for that agent (prevents forks).
• Per-agent nullifier reservation DB. Reserve nullifiers in memory at verify time, persist to WAL for crash recovery, move to spent at commitment. This prevents double-spend in the pending window.
• AP2 mandate enforcement. Per-agent mandate stored. Each incoming tx checked against mandate conditions (amount caps, merchant allowlists, time windows, daily totals). Reject if violated.
• Concurrent multi-agent throughput. Unlike the multisig coordinator which serves one account per proposal, the agentic guardian must handle N independent agents each with multiple concurrent in-flight txs. Lock contention design needs attention.
• Batch proving. Generate STARK proofs for pending txs in parallel and assemble a batch for submission. Proving infrastructure (CPU/GPU) sized for target throughput.
• Batch submission and reconciliation. Submit proven txs, watch for block inclusion, notify clients of commitment or failure.
• Crash recovery. All in-flight state (reserved nullifiers, pending account states, queued txs) must survive a process restart. PostgreSQL + WAL pattern from the coordinator server is a reasonable starting point.

Open decision: extend OZ Guardian directly, or ship as a separate agentic-guardian component that integrates with Guardian for custody and mandate verification but handles the high-throughput payment flow itself. The latter is probably cleaner because the operational profiles are different (Guardian: low-frequency high-value custody operations; agentic-facilitator: high-frequency low-value payment flows). Needs input from @bobbinth and OZ team on what fits their architecture.

---

Why this design works

• Sub-second perceived latency. Agent's critical path is sign + send + ack. Proving and on-chain settlement happen asynchronously. Latency budget is dominated by network round-trips (~200-500ms), comparable to Base x402.
• No protocol changes. Stays inside the existing Miden account and note model. The "inverted proving flow" Bobbin described is the only architectural shift, and the primitives already exist in the multisig PoC.
• Privacy preserved. Notes can be private (per Digine-Labs' existing noteType: "private" variant). The Guardian sees its registered agents' txs (which it would anyway as co-signer), the merchant sees only what x402 verification needs.
• Mandate enforcement composes. Guardian's per-agent mandate check happens at verify time. AP2 enforcement at the chain layer rather than the merchant layer.
• Cleanly reuses existing patterns. Multisig client for sign-without-prove. Coordinator server for batched async submission. OZ Guardian for custody and mandate. New work is mostly gluing these together and adapting for machine-pace throughput.

What this comment is for

If the design is acceptable in principle to @bobbinth, @igamigo, @partylikeits1983 and @ermvrs this can serve as the shared baseline for a more detailed implementation design across the four parties. Each component (agentic-client, agentic-guardian, x402 scheme variant, end-to-end testing) can then be scoped and assigned.

Open questions left for the design discussion:

1. Sign-only mode in core miden-client vs. separate miden-agentic-client crate
2. Extending OZ Guardian vs. separate agentic-guardian component
3. Where pending-state tracking primarily lives (client, Guardian, or duplicated)
4. Batch trigger (time window, size threshold, hybrid) and target latency-to-finality
5. WAL persistence design for nullifier reservations
6. How Digine-Labs' miden-x402 scheme spec gets updated to express the new flow (likely a new variant alongside noteType: "private")

The actor-model concerns raised in my earlier follow-up are resolved by the Guardian being the single serialization authority, as Bobbin explained. The AgentDebitNote proposal is withdrawn, sorry @partylikeits1983

[Dominik1999]

The transaction needs to be executed, then sent over to the guardian, proven there, sent over to the network, and finalized into a block before the merchant is able to validate the payment is correct, right?

Not quite. In my understanding of x402, the merchant trusts the Facilitator. So as long as the facilitator sees a correct unproven tx, it will tell the merchant that payment is there. In the background the Facilitator / Guardian would batch prove every couple of minutes or so, but the merchant already submits the paid resource once the Facilitator gets the unproven note from the agent.

[Dominik1999]

"Sign-only mode" here really only means executing transactions but not proving them, right? If so, nothing to do there in regards of the client. And more generally, there is nothing that miden-agentic-client would have to do that is not already on miden-client, except for the guardian integration (but according to the above that would require the new endpoint first, etc).

That's awesome, @ermvrs for vis. Let me know if you need to understand how to use those features (submitting non-proven tx) and I can point you to the code.

That means we need to "only" branch the OZ Guardian and add a couple of features.

[bobbinth]

Ideally, we wouldn't need to use special miden-agentic-client and agentic-guardian and this would be just a part of the standard client and guardian.

On the guardian side, we'd need an endpoint that accepts and executed transaction + user's signature, and then manages the pool of executed transactions (i.e., dispatches them to provers, batches them, and then sends the batch to the network). We could start pretty simple here (e.g., immediately prove and submit a single tx to the network), and then incrementally make this more sophisticated (i.e., building batches can come later). The main reason for this is that more sophisticated transaction management is highly non-trivial as the guardian needs to deal with potential transaction errors, state rollbacks etc.

On the client side, when the client is connected with a guardian, instead of the client sending transactions to the network, the client would just need to execute a transaction and send the executed tx to the guardian. I don't believe we have this flow yet (we always execute and prove txs at the same time).

Also worth noting that "many concurrent in-flight txs" has a practical limit here as there is the need of distributing the states correctly at the correct time to the user and expecting that nothing gets executed until the user sends in their signature/transaction.

Agreed - that's the main reason for my suggestion above to start with a super simple implementation when the guardian proves/submits the received transaction immediately.

On this point, and extending the idea of inverting the flow I wonder if the guardian should just receive and manage a sequence of TransactionRequests (basically miden-client-service) and both execute and prove the transactions at their own pace. The guardian could ask the user for the signature once that's required, so the user just acts as a TransactionAuthenticator. Maybe this was already being implied in your comments and I misinterpreted the original ideas.

This is possible, but would potentially be more work - or it may be better then to have a different client as it could be much simpler (though, it would still need to track state, sync with the chain etc.).

[Mirko-von-Leipzig]

Is there not the problem that the user can change/remove the guardian/facilitator after the fact and front run them? This locks the guardian out.

[Dominik1999]

yes, but there is a delay window for that action in which the Facilitator can cash in

[VAIBHAVJINDAL3012]

Hi everyone, I might have an unpopular opinion here and could be completely wrong, please correct me if so.

In the current Guardian-as-facilitator design, the merchant still has to trust the Guardian of agent. I also worry that adding payment verification, nullifier reservation, and batch settlement on top of Guardian's existing responsibilities makes it significantly more complex over time.

I really liked the AgentDebitNote idea that was briefly proposed. It feels cleaner to me, and maps naturally onto MPP's session escrow model:

1. Agent creates one AgentDebitNote at session start — Guardian checks spend limits here, once. Hand it over to the facilitator (trusted by merchant). The note script only allows P2ID outputs to the merchant, so the facilitator needs zero trust from the merchant. The note itself enforces the constraint. (1 onchain tx)
2. Per API call, agent signs a lightweight intent — identical in spirit to MPP vouchers. No account state, no proving.
3. Facilitator batches intents and settles against the note. The note is the escrow — analogous to MPP's onchain escrow contract, but native to Miden with no separate contract needed.
4. User reclaims unspent funds at end. (1 onchain tx)

This keeps the Guardian simple, removes per-payment trust assumptions, and gives Miden a cleaner MPP Level 2 equivalent than any EVM chain has. And more importantly it keeps the number of transaction and prove generation very less.

[bobbinth]

Thank you for pushing back! I think the main question here is: what trust assumptions are we comfortable with here. So far we have options:

1. No trust assumptions - but this requires 5 - 10 second latency.
2. The merchant trusts the agent's facilitator (option described by @Dominik1999).
3. The merchant trusts a facilitator of their choice (this thread).

If there is a way for the merchant select their own facilitator as a part of normal protocol interaction, option 3 may be preferable to option 2, and in that case we don't need a guardian at all (or at least from the x402 perspective, there whether there is a guardian doesn't really matter).

I do want to say that option 2 has some advantages over option 3:

• The user doesn't need to lock up any funds in the note - all transactions go out of their existing account.
• There is no need for the initial setup - i.e., we can start transacting immediately without first having to create a note on chain.

Whether these advantages outweigh the need to trust the user's facilitator really depends on who the facilitator is. For example, if everyone uses 5 big facilitators, then the merchant can probably be comfortable with using the user's facilitator. But if facilitator space is fragmented and there are many small ones, then merchant would probably want to rely on their own facilitator.

[VAIBHAVJINDAL3012]

Thanks for the more clarity.

I still believe merchants would be more comfortable with using their own current trusted facilitator rather than trusting new one, option 3 can be directly integrated in the current setup of existing facilitators, it would be like just integrating a new chain there.
And more importantly onboarding of merchants would be easy, as existing facilitator already have their distribution.

The user doesn't need to lock up any funds in the note - all transactions go out of their existing account.
There is no need for the initial setup - i.e., we can start transacting immediately without first having to create a note on chain.

I agree to both of your points, it add delay in the first step, but present MPP works on the same setup. So agent(using MPP) might not have any issue with locked funds.

I think main tradeoffs between option 2 and 3 would be-
In option 2

• no upfront locked funds
• more number of overall transactions

In option 3

• initial locked funds
• less number of transactions.

Please correct me if I am thinking in off direction

[bobbinth]

Yes, agreed. I think the main point here is:

option 3 can be directly integrated in the current setup of existing facilitators, it would be like just integrating a new chain there

If this is indeed the case and it would make integration with existing infra simpler, then option 3 should be the winning option.

[Dominik1999]

I think, this is what we need to find out with the 5 biggest facilitators out there. We should pick the setup that gets integrated there. However, what we can already analyse on our end is to see with which setup we have the lower latency. @ermvrs is setting up a real test harness for testnet. We can then build and test different designs against it.

[Dominik1999]

OK, so I read the x402 whitepaper and the spec. Initially, I just trusted Claude for the analysis, but this was not as helpful as I thought and led to a bit of more discussion than needed.

A few key considerations that define our design for x402 on Miden:

• There are three different payment schemes for x402 exact, upto, and batch-settlement. (https://docs.x402.org/schemes/overview)
• The merchant does not really trust the facilitator in x402. In fact, in the whitepaper there is not even the role facilitator.
• The facilitator's role just emerged as a helper for merchants to monitor the chain and allow gas-less payments for agents and merchants. However, the merchant can always also go onchain and settle (EIP-3009) and observe the chain.
• We need to adhere to the x402 schemas and trust assumptions. Otherwise, the facilitators won't integrate Miden as an option

Normal Guardian model does not fit

The Guardian as a co-signer does not match the specification - it would require a mandatory signature from the Guardian and the merchant could not settle without the Guardian (easily). It would create a liveness issue and bind the merchant and agent to a facilitator. However merchants are free to choose any facilitator. The agent doesn't even know which facilitator the agent has chosen.

batch-settlement is easy to implement using the AgentDebitNote from above

The batch-settlement scheme is for high-throughput payments where many requests are authorized individually and redeemed later in batches. The EVM implementation uses stateless unidirectional payment channels: a buyer deposits funds into onchain escrow once, then signs off-chain cumulative vouchers for each request. The merchant verifies vouchers quickly and redeems them onchain later in batches - with the help of any facilitator or without.
Use batch-settlement for repeated paid API calls, usage-metered endpoints, and other workloads where many small payments would be too expensive or slow to settle one-by-one.

Here is a reference implementation using that schema on Miden. This uses the exact HTTP messages and endpoints and could be implemented by any facilitator: https://github.com/Dominik1999/miden-x402

The AgentDebitNote (ADN) is bound to a specific merchant, not to a facilitator. However, anyone can consume the ADN as long as they have a signed message from the agent about the cumulative sum. The agent or agent's user can always reclaim the ADN after a certain, predefined block height.

If we would not bind the ADN to a specific merchant (multi-merchant ADN), then some coordinator needs to prevent double spends. If we bind the ADN to a facilitator, then all merchants trust the facilitator as a coordination layer which would not be the standard schema anymore.

For this use case and implementation we get competitive benchmarks. However, it is not clear if this schema is used a lot. In the past uni-directional payment channels that allow metered access were not used a lot. You can think of, one agent paying one merchant small sums over a longer period of time. We need to talk to the big facilitators and see if this schema is used.

exact and upto are actually even easier to implement but we need to wait for onchain settlement

exact refers to a one time exact payment from an agent to a merchant. In Miden terms, you can think of the agent sending a P2ID to a merchant. The merchant can either consume it directly or ask a facilitator whether the P2ID is onchain. In this case, the facilitator waits for onchain inclusion and acks back to the merchant that releases the resource. We can build the exact schema and follow the protocol, but for Miden it will be hard to match Base's claimed 400ms finality.

Maybe getting privacy for the payment is enough to accept 5-10s finality. But its basically a tradeoff: "Privacy vs Latency".

upto has the same tradeoffs as the exact schema.

Next steps

Is more of a business development task. We need to talk to the 4 biggest facilitators and see (a) which schemas are used most and (b) under which conditions would they implement Miden.