> ## Documentation Index
> Fetch the complete documentation index at: https://docs.x402x.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# What is x402x

> An extension implementation of x402 — supports more payment methods and incentives

## 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 $1 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:

<CardGroup cols={2}>
  <Card title="Quick Start" icon="rocket" href="/en/user-guide/quick-start">
    Run the full x402x flow in 5 minutes
  </Card>

  <Card title="Seller Guide" icon="store" href="/en/user-guide/seller-guide">
    How to integrate x402x on the server
  </Card>

  <Card title="Buyer Guide" icon="user" href="/en/user-guide/buyer-guide">
    How to use x402x on the client
  </Card>

  <Card title="EIP-7702" icon="shield" href="/en/user-guide/why-use-eip7702">
    Learn the minimal-trust seller wallet approach
  </Card>
</CardGroup>