Skip to main content

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.

​
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 MegaETH, the recommended Meridian flow is now Permit2 via facilitator V4_2. The older USDm forwarder remains available only for backward compatibility with legacy EIP-3009 clients and is 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
Current MegaETH integrations should use Permit2 settlement through the Meridian facilitator V4_2: 
Facilitator:           0x8E7769D440b3460b92159Dd9C6D17302b036e2d6
x402ExactPermit2Proxy: 0x402085c248EeA27D92E8b30b2C58ed07f9E20001
Permit2:               0x000000000022D473030F116dDEE9F6B43aC78BA3
  • Current path: Users approve Permit2 once, then sign a Permit2 witness authorization off-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 (MegaETH legacy compatibility)

The MegaETH forwarder path is deprecated for new integrations. Prefer the Permit2 flow above. Keep the forwarder only if you still need backward compatibility with existing USDm + EIP-3009 clients.
This forwarder adds EIP-3009 compatibility to USDm on MegaETH while keeping Meridian’s normal facilitator flow intact. It is based on the open source implementation here. 
0x2c2d8EF0664432BA243deF0b8f60aF7aB43a60B4
If you still use the forwarder on MegaETH, users give a one-time approval on the USDm token: 
USDm.approve(forwarder_address, type(uint256).max);
For the legacy Meridian flow on MegaETH, the signed payment still targets the facilitator. The forwarder is the facilitator’s deprecated MegaETH 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. On MegaETH, the recommended path uses Permit2 through x402ExactPermit2Proxy; the USDm forwarder remains 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.