The Meridian facilitator accepts several payment payload types over the same x402 endpoints (Documentation Index
Fetch the complete documentation index at: https://docs.mrdn.finance/llms.txt
Use this file to discover all available pages before exploring further.
POST /v1/verify and POST /v1/settle). The facilitator inspects each request and routes it to the correct settlement path automatically; clients do not call different endpoints for different payment types.
Supported types
Exact (EIP-3009)
Default scheme. Buyer signs an EIP-3009
transferWithAuthorization for USDC
and Meridian settles through X402ProxyFacilitator on the destination
chain. On BSC, this exact path is backed by a forwarder because BSC USDC
does not expose native EIP-3009 support.Permit2 (MegaETH)
Recommended path on MegaETH. Buyer approves Permit2 once, then signs a
witness authorization that Meridian settles through
x402ExactPermit2Proxy.Circle Gateway (Batched)
Gas-free, batched USDC nanopayments backed by Circle’s Gateway Wallet.
Detected via
paymentRequirements.extra.name === "GatewayWalletBatched".Comparison
| Capability | Exact (EIP-3009) | Permit2 (MegaETH) | Circle Gateway Batched |
|---|---|---|---|
| Tokens | USDC | Any ERC-20 | USDC only |
| Minimum payment | Token-decimal granularity | Token-decimal granularity | $0.000001 USDC |
| Settlement target | X402ProxyFacilitator | x402ExactPermit2Proxy (via facilitator) | Circle Gateway API |
| Buyer one-time setup | None | approve(Permit2, ∞) | Deposit USDC into Gateway Wallet |
| Per-payment signing | EIP-3009 typed data | Permit2 witness typed data | EIP-712 typed data over Gateway Wallet domain |
| Gas paid by buyer | None | None | None |
| Cross-chain | Same-chain | Same-chain | Unified balance across all funded chains |
| Buyer experience | < 2s on-chain settlement | < 2s on-chain settlement | Instant signature verification; onchain settlement batched by Circle |
| Platform fee / cashback | Supported | Supported | Not applied (Meridian fee logic is skipped on the batched path) |
How routing works
Both/v1/verify and /v1/settle follow the same first-level decision tree. Settle additionally distinguishes between EIP-3009 and Permit2 by trying PaymentPayloadSchema first and falling back to MegaethPermit2PaymentPayloadSchema:
The “is this a batched payment?” check is implemented via isBatchPayment from @circle-fin/x402-batching/server. It looks at paymentRequirements.extra only; the rest of the request body keeps the same x402 v1 shape regardless of which path is taken.
Choosing a payment type
- Building a typical x402 paywall on Base, Optimism, Polygon, etc. → Exact (EIP-3009). Nothing extra to set up for native EIP-3009 tokens; the SDK middleware handles it.
- Integrating BSC → Exact (EIP-3009) via Meridian’s forwarder-backed V4_1 path. Buyers approve the BSC forwarder
0x2c2d8EF0664432BA243deF0b8f60aF7aB43a60B4once, then sign against the forwarder domain while the facilitator remains the payment target. - Integrating MegaETH → Permit2 for new integrations. The legacy USDm forwarder uses the same adapter pattern as BSC, but remains backward compatibility only. See Smart Contracts and Supported Networks.
- High-frequency, sub-cent agent-to-agent payments where zero fees and unified balance matter more than per-tx settlement speed → Circle Gateway Batched.
Reference
POST /v1/verify: verification entrypoint for all three types.POST /v1/settle: settlement entrypoint for all three types.GET /v1/supported: list of{ x402Version, scheme, network }triples the facilitator accepts.