Skip to main content

​
Limitations of x402

The x402 core protocol defines the fundamental payment flow and data formats, but currently has some limitations:
  • Single payment method: on EVM, only USDC that conforms to EIP-3009 is supported
  • Lack of incentives: no economic incentives for Facilitators
  • Fixed trust model: cannot support more flexible trust models (e.g., minimal-trust based on EIP-7702)
As use cases diversify, we need to provide more extensions while adhering to x402’s core principles.

​
What is x402x?

x402x is an extension implementation of the x402 core protocol. Through an extension mechanism (schemes), it remains fully compatible with x402 while supporting more token standards, trust models, and incentive mechanisms, enabling broader ecosystem integration and usage. Core idea: do not change the x402 base protocol; enhance capabilities through scheme extensions.

​
Extensions provided by x402x

​
1. More payment methods

Extended support for EVM token authorization standards:
  • EIP-2612: standard Permit signature (supported by many stablecoins)
  • EIP-3009: USDC’s transferWithAuthorization (natively supported in x402)
  • Permit2: Uniswap’s generalized authorization contract covering all ERC-20 tokens

​
2. Facilitator incentives

Introduce fee distribution to make the payment ecosystem healthier:
  • Fee field: define facilitator’s fee share in the seller’s EIP-7702 contract
  • Mining-like incentive: facilitator, acting like a miner, earns by submitting on-chain payments
  • Ecosystem growth: incentivize more tools and services to integrate x402x
Example: the seller sets a 1product,with1 product, with 0.99 to the seller and $0.01 to the facilitator

​
3. EIP-7702 minimal-trust integration

Based on the seller wallet approach using EIP-7702, achieving minimal trust while enabling flexible payment logic:
  • Principle: the seller upgrades their EOA to a smart account via EIP-7702
  • Security: the buyer’s funds are authorized only to the specific seller via signature
  • No third party required: the buyer only needs to trust the seller, not the facilitator or others
  • Flexibility: the seller wallet contract can implement richer logic (e.g., 1% facilitator fee)

​
x402x technical architecture

x402x keeps the x402 core flow unchanged, and extends it via:

​
Scheme extension mechanism

Each scheme defines an extended payment method:
  • exact-permit: exact payment using EIP-2612 Permit
  • exact-permit2: exact payment using Permit2
Each scheme defines:
  1. The extra field format in PaymentRequirements
  2. The payload field format in PaymentPayload
  3. The concrete logic for verification and settlement

​
Backward compatibility

x402x is fully compatible with x402:
  • Uses the same HTTP 402 response format
  • Uses the same X-PAYMENT and X-PAYMENT-RESPONSE headers
  • Follows the same core principles (open standard, HTTP-native, chain/token agnostic, minimal trust, usability)

​
Why choose x402x?

  • ✅ Need to support tokens beyond USDC (e.g., USDT, USD1, DAI, etc.)
  • ✅ Need to support more chains (e.g., BSC)
  • ✅ Want to incentivize Facilitators to get transactions on-chain faster

​
Get started

Want to use x402x? Check out:

Quick Start

Run the full x402x flow in 5 minutes

Seller Guide

How to integrate x402x on the server

Buyer Guide

How to use x402x on the client

EIP-7702

Learn the minimal-trust seller wallet approach