> For the complete documentation index, see [llms.txt](https://docs.wildmeta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wildmeta.ai/trading-terminal/x402-support-and-extension/features-and-advantages.md).

# Features & Advantages

Here are the key benefits of this x402 +4337 extension:

#### Token-agnostic Payment — No ERC-3009 Token Required

Traditional x402 models might require a specific “payment token” (e.g., an ERC-3009 token) to simplify settlement. By contrast:

* Since the payment is simply a balance transfer (or arbitrary contract call) wrapped in a UserOperation, we can accept *any* ERC-20 token (or native token) as payment.
* Supports multi-chain environments (e.g., BSC, Ethereum mainnet, L2s) where a dedicated ERC-3009 token may not exist.
* This greatly broadens flexibility for publishers and users.

#### Leveraging ERC-4337 / Account Abstraction

By using UserOperations and account abstraction we gain:

* Smart wallet features: e.g., social recovery, multisig, advanced validation logic.
* Potential for paymasters: e.g., DApp or publisher may subsidise gas or accept payment in token rather than native chain gas.
* Better UX: users don’t need native token (ETH etc) just for gas; wallet logic handles that.
* Custom validation logic: e.g., restricting payment to exact token, amount, chain, or even more complex logic (staking, contract calls).
* Improved extensibility and future-proofing as AA becomes more pervasive.

#### Dual Compatibility: Standard x402 + UserOp

Our facilitator supports both:

* “Standard” x402 where the payment data is a simple `transferWithAuthorization` signature (e.g., ERC-3009 or another token standard)
* UserOperation-based payment where the data is a signed UserOp. The data type (3009 vs 4337) is encoded in the `X-PAYMENT` header.\
  This allows the system to interoperate with legacy implementations or mixed markets.

#### Server-side Agnosticism & Opaque Blob

The server (resource provider) does *not* need deep awareness of the on-chain mechanics:

* The `X-PAYMENT` header carries opaque bytes (either token-transfer directive or UserOperation struct)
* The server simply forwards those bytes to the facilitator, which handles verification/settlement
* The server thus remains lightweight and unaware of token types, chains, or wallet logic.

#### Customised Payment Logic

Since the payment is expressed as a UserOperation, it need not be a plain token transfer. Examples:

* A call to a staking contract (user stakes tokens as access)
* A subscription contract invocation
* Multi-step actions: e.g., approve → transfer in one UserOp
* On-chain logic: e.g., user pays in token A; contract automatically converts to token B; access is granted only if conversion succeeded.\
  This opens up advanced monetisation models beyond “send X tokens”.