Leo Belyaev, a core developer at X1 Labs, has posted two litepapers to the X1 Builders Telegram group. Both are dated October 10, 2026, and both are about W2, the X1 Labs smart wallet that holds funds in an on-chain account and signs with a passkey instead of a seed phrase.
This article covers the first paper, W2 × x402, which explains how W2 would pay for things over the web using x402, the open standard for payments over HTTP. The second paper, on intents, is covered in our companion piece: how W2 would let solvers deliver a payment from whatever asset you hold.
The paper’s summary fits in one sentence: “one Touch ID can authorize a single request-bound payment, or a bounded budget that agents spend without the user present.”
Both papers describe designs, not shipped products. They target test networks first, list a roadmap and close with open questions, so nothing below is live on X1 mainnet yet.
What x402 is
x402 puts the old HTTP status code 402, “Payment Required”, to work. A server answers a request with a 402 that states the price, the token, the network and the address to pay. The client pays and retries, and a third party called a facilitator checks and settles the payment. No account, no API key, no card. That makes it the default way for an AI agent to pay for an API call, a theme we covered in our look at which chains suit AI agents.
According to the paper, x402 has been governed by the x402 Foundation under the Linux Foundation since April 2026, with members including Coinbase, Cloudflare, Stripe, AWS, Google, Visa, Mastercard and the Solana Foundation. It puts adjusted volume at roughly $19M across about 134M transactions since May 2025, concentrated in a few thousand wallets. Its verdict: “Infrastructure is ahead of demand, and the missing pieces sit on the payer side.”
The gap W2 is aimed at
x402 assumes the payer is a plain private key that signs a token transfer. The paper lists what follows from that:
| Gap | What x402 assumes today | Consequence |
|---|---|---|
| Custody | Payer is a raw key | Agents carry hot private keys; humans need a seed phrase |
| Gas | Payer can cover fees or has a funded path | A brand-new user cannot pay for their first request |
| Smart wallets | A plain TransferChecked signed by the token owner | Wallets that hold funds in a program account (W2, Squads, Swig, LazorKit) cannot pay through standard facilitators |
| Delegation | Spending limits live in off-chain wallet software | A compromised agent host can drain the key |
| Request binding | Payment authorizes an amount to a payee | A captured payment can be presented against another endpoint of the same payee |
| Chains | Facilitators cover Base, Solana, Polygon and a few others | X1 has no facilitator |
That last row is the X1 angle. Projects on X1 already sell API access through x402, FortiBlox among them, but the payment itself settles on Solana or Base.
How W2 works
W2 splits a wallet into four jobs: a program-derived account (PDA) holds the assets, passkeys and scoped keys authorize, a paymaster pays the gas, and the W2 program enforces the rules on-chain. The pieces that matter for payments:
- WalletV2, the PDA that holds funds. Its address comes from a random account ID, so it survives a change of passkey.
- Passkey authority, a WebAuthn P-256 credential (Touch ID, Face ID, a hardware key) verified on-chain through the P-256 precompile.
- Canonical intent, a typed payload that binds network, program, wallet, nonce, expiry, recipient, amount, asset and fees. What the wallet shows, what the paymaster builds and what the program executes all come from the same bytes.
- SessionAuthorityV2, a scoped key for agents, limited by time (up to 7 days), audience, asset, recipient, amount and number of uses.
- SitePermissionV2, which lets a merchant pull repeat charges for one asset to one destination, for up to 30 days, without becoming a signer.
- Child wallet, a separate PDA with its own balance, so a budget can never exceed what the child holds.
- Paymaster, which builds, checks and sponsors complete transactions, so users and agents need no native XNT.
Changing the wallet’s authorities moves an authority_epoch forward, which kills every outstanding session and stale intent at once.
Four things W2 adds to x402
1. A smart-wallet profile
Today’s Solana x402 scheme expects the client to sign a token transfer with its own key. A PDA cannot do that. In W2 the transfer is made by the W2 program, after one P-256 check, and no user Ed25519 key signs the transaction at all. The paper proposes this as a second, parallel way to settle the same payment, leaving the existing one untouched for ordinary wallets.
A side benefit: the passkey signs the intent, not the transaction. The intent carries its own expiry, so the facilitator can rebuild the transaction with a fresh blockhash without asking the user to sign again.
2. Payments tied to one request
Each W2 intent can carry a context hash. For x402 it commits to the payment terms, the URL, the HTTP method and a digest of the request body. The payment is good for exactly that request and nothing else, and the payer keeps a signed record of what it paid for.
3. Agent budgets the agent cannot exceed
The example in the paper: a user approves “this agent may spend up to 20 USDC over 7 days with this API provider” once. The agent then pays per call with no prompts, and the W2 program checks the limits on every transfer. “The limits hold even if the agent host or the paymaster is compromised, because the program checks them,” the paper says. “This is the product-level difference between W2 and a hot wallet with a policy file.” Put the session on a funded child wallet and the worst case is that child’s balance.
4. A facilitator for X1
The W2 paymaster already does a facilitator’s work: admitting requests, building transactions, checking policy, signing, submitting and reconciling. Exposed as an x402 facilitator, it would settle payments on X1, and on any other SVM chain, where no third-party facilitator runs today.
Gas paid in USDC, and who pays the rent
The paper is blunt about paymaster economics: the expensive line is account rent, not gas. Creating a recipient token account costs about 400 times a base fee on Solana (X1 parameters may differ), and wallet setup creates several accounts per user, some of which are never refunded. Failed transactions still charge the fee payer. “Rent and abuse are what break ‘free gas’ programs,” it says.
The fix it proposes is to let a user pay gas in the token being moved. A user who holds only USDC and no XNT signs one intent; the W2 program sends the payment and, in the same transaction, a capped USDC fee back to the sponsor. The paper credits the pattern to Octane and Kora. The wallet shows the fee in USDC, and the user never sees XNT.
Two more ideas build on that. The paymaster could quote its fee as an x402 402 response, listing USDC and XNT options, so several paymasters could compete on price. And with counterfactual wallets, a W2 address could receive USDC before the wallet exists on-chain, then create itself on the first spend and repay its own setup rent from that USDC. Onboarding would cost the sponsor nothing up front.
The paper names the largest open risk itself: XNT liquidity. A paymaster that earns USDC and spends XNT only works if it can reliably convert one into the other at scale.
Use cases
The paper focuses on payments plain x402 cannot handle safely:
| Use case | W2 mechanism | What plain x402 lacks |
|---|---|---|
| Agent API budget | Session key on a funded child wallet, limits enforced on-chain | On-chain spend limits |
| Paid oracle updates | Pay per signed data update; the context hash commits to the attestation | Proof that the data paid for is the data used |
| Pay-per-article content | Embedded wallet, one Touch ID, sponsored gas | A seedless, gasless first payment |
| Receive and resend USDC | Sponsor reimbursed in USDC in the same transaction | Gas paid in the token being moved |
| Paid MCP tools | Session scoped to one tool server’s payee and asset | A per-tool budget, revocable in one action |
| Recurring merchant charges | SitePermissionV2 | Subscriptions without a reusable signing key |
| Bridge-funded cold start | Warp-assisted funding to the W2 account, then payment | Paying on X1 without holding XNT |
| Acquire-then-pay | A solver gets the required asset, then x402 settles | Paying when you hold a different asset |
The acquire-then-pay row is where the two papers meet. Our intents article explains how it would work.
Security model
“No single layer can move value,” the paper says: the merchant describes the payment, the wallet shows it, the paymaster builds it, the signer policy checks it and the program enforces it. Unknown programs, lookup tables, signers and Token-2022 extensions are rejected until each is specified. It also lists what remains: a session key is a bearer credential up to its limits and belongs in secure hardware or an OS keystore, and x402 still does not prove the resource was delivered. “W2 binds what was paid for, not what was returned.”
Roadmap and open questions
The paper’s ten-step roadmap starts with writing the smart-wallet profile as test vectors and running a W2 facilitator on X1, then moves to headless agent payments, a broader agent session type, oracle attestations, USDC-paid sponsorship, the paymaster quote endpoint and counterfactual wallets. The last step is taking the smart-wallet profile to the x402 Foundation, since Squads, Swig and LazorKit share the same custody model and “a common profile lets any facilitator settle any of them.”
Questions it leaves open include:
- Does a session’s amount limit mean a lifetime budget, a per-transaction cap, or both?
- Will the first facilitator support only USDC, or XNT-denominated payments too?
- Is there enough XNT/USDC liquidity on X1 for a paymaster to rebalance at scale?
- Is the canonical paymaster the only operator, or one of several competing ones?
- Who funds onboarding rent before counterfactual wallets ship?
For the other half of the release, read W2 × Intents: how solvers could let you pay in any asset on X1.