April 5, 2026
x402 on BSC: Four Approaches, Two We Support, One We Built
BSC stablecoins don't have transferWithAuthorization. USDT and USDC on BSC are Binance-Peg bridge wrappers — standard ERC-20, nothing else. The function that powers x402 on Base, Polygon, Arbitrum, Optimism, and Avalanche does not exist on these contracts.
Four approaches to x402 on BSC exist. We investigated all of them on-chain, built one, and adopted another.
The landscape
Permit2 is the upstream x402 standard for chains without EIP-3009. Uniswap's canonical Permit2 contract is deployed on BSC alongside the x402 foundation's x402ExactPermit2Proxy. Any ERC-20 works. The user approves Permit2 once, then signs PermitWitnessTransferFrom authorizations per payment. The standard @x402/evm client handles this when the facilitator signals assetTransferMethod: "permit2". Added to the upstream SDK in January 2026.
AEON has 573,792 settlement transactions since December 2025. 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 @x402/evm package cannot use AEON on BSC. Contract source is not published. We decompiled the bytecode and confirmed OZ v5 Ownable, Pausable, SafeERC20, Initializable. No ReentrancyGuard.
Milady BSC uses $U by United Stables, which natively implements EIP-3009. Three settlements. Standard x402 exact scheme. Users must hold $U.
Dexter built DexterBSCFacilitator and a new scheme type called exact-approval. User approves the contract once, then signs a custom EIP-712 Payment message per transaction. The contract enforces fee caps, token allowlists, and pause on-chain. Source is public.
Pieverse, Unibase, and B402 claimed BSC x402 support. No on-chain evidence for any of them.
| Permit2 | AEON | Milady BSC | Dexter (exact-approval) | |
|---|---|---|---|---|
| Works with USDT/USDC | Yes | Yes | No ($U only) | Yes |
| Requires forked SDK | No | Yes | No | No |
| Custom contract | x402 proxy (open) | Yes (closed) | No | Yes (open) |
| Scheme name | exact |
exact (ambiguous) |
exact |
exact-approval |
| ReentrancyGuard | N/A (proxy) | Not in bytecode | N/A | Yes |
| On-chain fee caps | No | Unknown | N/A | Yes (5% MAX_FEE_BPS) |
| On-chain token allowlist | No | Unknown | N/A | Yes |
| Pause mechanism | No | Yes | N/A | Yes |
| BSC settlements | Proxy deployed, volume depends on facilitators | ~573K | 3 | 2 |
Full competitive analysis with bytecode decompilation and reproducible verification: research report.
Dexter on BSC
The facilitator at x402.dexter.cash registers both schemes for eip155:56. The /supported endpoint returns two kinds:
scheme: "exact"withextra.assetTransferMethod: "permit2"— standard Permit2 path, works with unmodified@x402/evmclients. The facilitator sponsors the Permit2 approval gas via theerc20ApprovalGasSponsoringextension, so the user never needs BNB.scheme: "exact-approval"with contract metadata — hardened path through DexterBSCFacilitator. User pays ~$0.02 BNB for the one-time contract approval.
The Permit2 path is fully gasless from the user's perspective. The facilitator broadcasts the user's pre-signed approval transaction and pays the BNB. Developers using the standard SDK get BSC with zero gas requirements for their users.
The contract
0x3D56A1A196aC81c959A1be21ABC28c173fB063B8 (proxy, verified on BscScan)
| Feature | Detail |
|---|---|
| ReentrancyGuard | nonReentrant on executePayment |
| Pausable | Owner-callable pause() / unpause() |
| Token allowlist | USDT + USDC, owner-managed |
| Fee caps | minFee floor + 5% hard max (MAX_FEE_BPS) |
| Fee separation | Fees go to feeRecipient, not executor |
| Nonce tracking | usedNonces[user][nonce], random 128-bit |
| Access control | Facilitator-only on executePayment |
| SafeERC20 | Required — BSC USDT doesn't return bool |
| Proxy | TransparentUpgradeableProxy, upgradeable without re-approval |
Source: DexterBSCFacilitator.sol
Why both
Permit2 is what the upstream SDK uses. Any @x402/evm client works on BSC through Dexter without modification. Not supporting it would cut off the standard ecosystem.
The custom contract exists because Permit2 settles through a generic proxy with no fee enforcement, no token restrictions, and no pause. DexterBSCFacilitator adds those properties on-chain, enforced in the contract regardless of what the facilitator software does.
Settlements
Two verified via exact-approval on BSC mainnet, April 5, 2026:
USDT: 0xdfb827d7...
USDC: 0xa177e436...
Contract: 0x3D56A1A196aC81c959A1be21ABC28c173fB063B8
Research: Competitive analysis with on-chain evidence
Documentation: BSC integration guide