# 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”.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.wildmeta.ai/trading-terminal/x402-support-and-extension/features-and-advantages.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.