Overview

The goal is to build the x402 payment protocol implementation for Miden, a ZK-optimized rollup with a non-EVM architecture. The deliverable is an open-source SDK package (@x402/miden) plus a hosted facilitator service, enabling any API or service to accept Miden micropayments via x402 — with zero Miden-specific knowledge required from the merchant.

This is strategically significant because Miden’s note-based, proof-verified transaction model is fundamentally different from EVM and Solana — making this the first x402 implementation for a ZK-native chain and the first to use proof verification rather than signature verification for payment settlement.

Architecture Context

Why Miden is different from EVM/Solana

On EVM, x402 works via EIP-3009 transferWithAuthorization — the payer signs a message off-chain, the facilitator submits it on-chain in one atomic step. On Solana, it’s SPL token transfers with signature authorization. In both cases, settlement is a single atomic transaction, and the merchant never needs to interact with chain-specific infrastructure.

<aside> ⭐

Key point: The merchant should never need to interact with chain-specific infrastructure. For example: if New York Times is the merchant, they just say: I want to accept payments from Ethereum, Solana, and Fiat, and it should “just work” for them.

</aside>

Miden uses a hybrid UTXO/account model where:

• Asset transfers require two transactions: one to create a note (sender’s tx), one to consume the note (receiver’s tx)
• Every transaction is executed and proven locally.
• Assets are native — stored directly in account vaults, not in contract registries
• Notes are programmable messages with scripts defining consumption rules (P2ID, P2IDE, custom)
• Accounts and notes can be private — only their hash is known to the network.

The core design problem

Miden’s two-phase transfer model (note creation → note consumption) breaks x402’s assumption that settlement is atomic. If the merchant were required to consume notes themselves, they would need Miden-specific infrastructure, breaking x402’s chain-agnostic abstraction. A merchant who adds one middleware line to accept x402 payments on EVM would suddenly need to run a Miden client, manage a Miden account, and actively process incoming notes just to support one additional chain. No merchant will do that.

The facilitator must therefore own the entire settlement lifecycle end-to-end, fully abstracting Miden away from the merchant. This is the only approach that adheres to x402’s spec and design philosophy: merchants add one middleware line and accept payments from any supported chain without knowing or caring which chain the payment came from.

<aside> ⭐

Key Point: merchant should not be required to run miden-specific infrastructure. The Facilitator needs to handle the flow end to end.

</aside>