Skip to main content

​
Overview

Meridian extends x402 with a proxy facilitator architecture that builds on top of Coinbase’s infrastructure. Unlike traditional direct wallet transfers, Meridian routes settlement through the facilitator and adds organization-scoped access control for verification and settlement. Across supported chains, the facilitator is the main Meridian payment entrypoint. On chains with native EIP-3009 support, Meridian settles standard x402 exact payloads through the facilitator. On chains where no EIP-3009-compatible token is present, Meridian now uses Permit2 via x402ExactPermit2Proxy 0x402085c248EeA27D92E8b30b2C58ed07f9E20001. This current Permit2 path applies to MegaETH, BSC, and BOT chain testnet and mainnet. The older BSC and MegaETH forwarders remain available only for backward compatibility with legacy EIP-3009 clients and are deprecated for new integrations.

​
Traditional x402 vs Meridian’s Innovation

​
Standard x402 (Coinbase Model)

Payer signs authorization → Direct transfer to recipient wallet

​
Meridian’s Proxy Facilitator Model

Payer signs authorization → Facilitator receives funds → Facilitator settles recipient and fees

​
Key Components

​
Smart Contract: X402ProxyFacilitator.sol

0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
  • Proxy Architecture: Payments flow through the facilitator contract rather than directly to the recipient
  • Settlement Layer: Same-chain payments are settled by the facilitator during payment processing
  • Fee Handling: Platform and treasury fees are handled inside the facilitator
  • Organization Integration: Payments can be linked to organizations for verification, settlement, and access control
  • Cross-Chain Support: The same entrypoint can be used for cross-chain settlement on supported networks

​
Smart Contract: x402ExactPermit2Proxy.sol (Current Non-EIP-3009 Path)

Current integrations on chains without EIP-3009-compatible tokens should use Permit2 settlement through the Meridian facilitator: 
Facilitator:           0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
x402ExactPermit2Proxy: 0x402085c248EeA27D92E8b30b2C58ed07f9E20001
Permit2:               0x000000000022D473030F116dDEE9F6B43aC78BA3
  • Current path: Users approve Permit2 once, then sign a Permit2 witness authorization off-chain on MegaETH, BSC, or BOT chain
  • Token model: paymentRequirements.asset is the ERC-20 token address being paid
  • Facilitator binding: payTo, witness.to, and witness.facilitator stay bound to the Meridian facilitator
  • Settlement: Meridian settles through transferWithPermit2, not through the buyer submitting a transaction

​
Smart Contract: EIP3009Forwarder.sol (Legacy on BSC and MegaETH)

Earlier Meridian integrations used EIP3009Forwarder as an adapter for tokens that did not expose native EIP-3009 transferWithAuthorization. That role has been replaced for new integrations by Permit2 through x402ExactPermit2Proxy. The forwarder verifies the buyer’s EIP-712 authorization and pulls the underlying token after the buyer has approved the forwarder, but it is no longer the current path. The forwarder remains available only for legacy BSC and MegaETH clients. The implementation is based on the open source forwarder here.
NetworkUnderlying tokenForwarder roleStatus
BSCUSDC 0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580dLegacy EIP-3009 adapter 0x2c2d8EF0664432BA243deF0b8f60aF7aB43a60B4Legacy only
MegaETHUSDm 0xFAfDdbb3FC7688494971a79cc65DCa3EF82079E7Legacy EIP-3009 adapter 0x2c2d8EF0664432BA243deF0b8f60aF7aB43a60B4Legacy only
Use the Permit2 flow above for new BSC and MegaETH integrations. Keep the forwarder only if you still need backward compatibility with existing EIP-3009-style clients.
Legacy users give a one-time approval on the underlying token, with the forwarder as spender: 
USDC_or_USDm.approve(forwarder_address, type(uint256).max);
For legacy forwarder-backed Meridian flows, the signed payment still targets the facilitator. The forwarder is a settlement adapter, not a separate Meridian entrypoint.

​
Backend Infrastructure

  • Organization Management: Users belong to organizations with shared payment infrastructure
  • API Key Authentication: Organization-scoped API keys for payment verification
  • Transaction Tracking: Complete audit trail of payments and settlements
  • Multi-User Access: Teams can manage payments collectively through organization structure

​
How x402 Works

  1. Authorization Signing: Payer signs a payment authorization with amount, recipient context, and network details.
  2. Verification: Server verifies signature and authorization parameters.
  3. Transfer Execution: Meridian executes settlement through the facilitator. Native EIP-3009 tokens use transferWithAuthorization; non-EIP-3009 chains such as MegaETH, BSC, and BOT chain use Permit2 through x402ExactPermit2Proxy. The BSC and MegaETH forwarders remain legacy compatibility only.
  4. Fee Application: Recipient and fee amounts are handled during settlement processing.

​
Meridian’s Unique Architecture

​
1. Proxy Facilitator Contract

function transferWithAuthorization(
    address from,
    address, // facilitator receives the funds
    uint256 value,
    // ... other params
    address recipient,
    address platform,
    uint256 platformFeeBps
) external {
    IFiatTokenV2(usdcContract).transferWithAuthorization(
        from,
        address(this),
        value,
        // ... other params
    );

    _handleFeesAndCashback(
        _usdcSettlementToken(),
        from,
        recipient,
        platform,
        value,
        platformFeeBps,
        block.chainid,
        block.chainid
    );
}

​
2. Organization-Scoped Management

  • Multi-User Organizations: Teams share payment infrastructure
  • API Key Management: Organization-scoped authentication
  • Shared Analytics: Transaction tracking across team members
  • Controlled Access: Organization admins manage payment permissions

​
3. Settlement Model

Earlier Meridian docs emphasized recipient withdrawal flows. In the current facilitator flow, same-chain payments settle to the recipient during payment execution, while fee balances remain managed inside the facilitator.

​
4. Enhanced Security Layer

Building on this proxy architecture, Meridian adds:
  • Organization Management: Users belong to organizations with shared infrastructure
  • API Key Authentication: Secure, organization-scoped access control
  • Multi-User Teams: Collaborative payment management without wallet sharing
  • Audit Trail: Complete transaction history and analytics

​
Why This Architecture Matters

For Developers:
  • Simplified Integration: One API for complex payment flows
  • Built-in Analytics: Organization-level transaction tracking
  • Team Management: Multi-user access without wallet sharing
  • Shared Settlement Path: A consistent facilitator model across supported chains
For AI Agents:
  • Standard x402 Compatibility: Works with the normal HTTP 402 payment challenge flow
  • Clear Role Separation: Buyer agents sign payments, seller backends verify and settle them
  • Organization Security: API key management prevents unauthorized settlement access
  • Framework Agnostic: Works with any AI agent framework
This proxy facilitator model extends x402 into a broader payment infrastructure while keeping the core signing and settlement flow recognizable across supported networks.