April 5, 2026
The First x402 Facilitator on BSC That Works With the Tokens You Already Have
Every x402 payment on an EVM chain goes through the same function: transferWithAuthorization, from EIP-3009. The user signs an off-chain message. The facilitator submits it to the token contract. Tokens move. No gas for the user. This is how it works on Base, Polygon, Arbitrum, Optimism, and Avalanche.
BSC's stablecoins don't have that function. USDT and USDC on BSC are Binance-Peg bridge wrappers — standard ERC-20, nothing more. No transferWithAuthorization. No permit. There is no Circle-native USDC on BNB Chain. We called the function on both contracts. It reverts.
Several projects claimed to have solved this. We investigated each one on-chain.
What exists today
AEON has 573,792 settlement transactions since December 2025. They're a BNB Chain MVB Season 10 graduate and the most active BSC x402 implementation by far. They embedded EIP-3009 into their own smart contract and forked the entire x402 SDK — their client has a function called signAuthorizationNoSuperEip3009 with their contract address hardcoded as a string literal. A developer using the standard Coinbase @x402/evm package cannot use AEON on BSC. Their contract source is not public. We decompiled the bytecode and confirmed OpenZeppelin v5 Ownable, Pausable, SafeERC20, Initializable. No ReentrancyGuard.
Milady BSC uses $U by United Stables, which natively implements EIP-3009. Three settlements total. Standard x402 exact scheme, no modifications. But users must hold $U — a niche stablecoin almost nobody has.
Pieverse announced pieUSD in October 2025. Testnet only, no mainnet deployment. Unibase claimed "first x402 facilitator on BSC." No on-chain evidence. B402 is a spec document.
| AEON | Milady BSC | Dexter | |
|---|---|---|---|
| Works with USDT/USDC | Yes | No ($U only) | Yes |
| Requires forked SDK | Yes | No | No |
| Contract source public | No | N/A | Yes |
| Scheme name | exact (ambiguous) |
exact |
exact-approval (explicit) |
| ReentrancyGuard | Not in bytecode | N/A | Yes |
| BSC settlements | ~573K | 3 | 2 |
| Active since | Dec 2025 | Mar 2026 | Apr 2026 |
Full competitive analysis with bytecode decompilation and reproducible verification: research report.
What we built
A new x402 scheme type called exact-approval and a smart contract called DexterBSCFacilitator.
The contract is on BSC mainnet behind a TransparentUpgradeableProxy. Source is public.
Proxy: 0x3D56A1A196aC81c959A1be21ABC28c173fB063B8
OpenZeppelin v5. ReentrancyGuard on the settlement function. Pausable. Token allowlist. Fee caps — a minFee floor and a MAX_FEE_BPS hard cap at 5%. Fees go to a separate feeRecipient, not the executor wallet. On-chain nonce tracking with random 128-bit nonces. Facilitator-only access control. SafeERC20 for BSC USDT compatibility.
The x402 V2 protocol has a plugin architecture. SchemeNetworkFacilitator is the interface for registering custom schemes on specific networks. We used it. exact-approval is registered for eip155:56. The name tells clients this is not the standard EIP-3009 flow — there's an approval step.
AEON calls their BSC scheme exact, same as Base. A client receiving scheme: "exact" has no signal that the signing target is a facilitator contract instead of the token contract. exact-approval removes that ambiguity.
Payment flow
Once per token: Approve the contract. Standard ERC-20 approve(). Same as PancakeSwap. About $0.02 in BNB.
Every time after that: Sign an EIP-712 Payment message. No gas. The facilitator verifies the signature, checks the nonce and allowance on-chain, calls executePayment() on the contract. The contract re-verifies, marks the nonce, moves tokens from payer to seller via safeTransferFrom. Dexter pays the BNB gas.
After the first approval, the user experience matches Base — sign and done. The approval itself is the one UX gap compared to EIP-3009 chains, and it's the same step every BSC DEX already requires.
Why a new scheme instead of wrapping EIP-3009
Both approaches work. AEON proved theirs at scale. Ours is four months newer.
The tradeoff is ecosystem integration. AEON forked every @x402 package to make their BSC path transparent to clients. Developers adopt AEON's SDK or they don't get BSC. The contract is closed.
We built a plugin. exact-approval can be registered alongside exact without replacing anything. It can be proposed as a standard scheme in the x402 spec. Any facilitator on any chain where stablecoins lack EIP-3009 can use it. The contract is open.
The difference matters if you're not building exclusively on AEON's stack. If you are, their approach is fine.
Settlements
Two verified on BSC mainnet, April 5, 2026. This is a fresh deployment — AEON has four months and 573K transactions on us. We're not competing on volume. We're competing on openness and protocol alignment.
USDT: 0xdfb827d7...
USDC: 0xa177e436...
AEON also supports USDT on BSC through their forked SDK. The difference: our contract is open source, our scheme is a standard plugin, and we support both USDT and USDC.
Next
x402 spec proposal. exact-approval works on any EVM chain where the dominant stablecoin lacks EIP-3009. We're proposing it as a standard scheme type so the entire ecosystem can use it.
SDK integration. Wiring exact-approval into @dexterai/x402 so wrapFetch handles BSC automatically.
Contract hardening. BscScan source verification. Ownership transfer to multisig.
Contract: 0x3D56A1A196aC81c959A1be21ABC28c173fB063B8
Research: Competitive analysis with on-chain evidence
Documentation: BSC integration guide