The second of two litepapers that X1 Labs core developer Leo Belyaev posted to the X1 Builders Telegram group, W2 × Intents, describes how W2, the X1 Labs passkey wallet, could let users sign an outcome and leave the route to someone else. Like its companion, it is dated October 10, 2026.
The paper’s own example: a user signs “deliver 5 USDC to this merchant on X1, paid from my SOL, at no worse than 1% below market” with one Touch ID. Solvers compete to deliver it, and the W2 program checks the result on-chain.
The first paper, on paying over HTTP with x402, is covered in our article on W2 × x402. This one builds on it. Both are design documents aimed at test networks first; nothing here is live on X1 mainnet yet.
What an intent is
“An intent is a signed outcome, not a signed transaction,” the paper says. The user commits to what must be true at the end, and anyone may compete to make it true. Three roles recur:
- Signer, who commits to the outcome: assets in, assets out, limits, deadline and a replay nonce.
- Solver (or market maker), who quotes and executes the route off-chain, often with its own capital.
- Verifier, an on-chain program that settles only if the signed outcome holds.
The paper points to NEAR Intents as the most widely used example. Users state outcomes such as a cross-chain swap, market makers fill them, and a verifier contract on NEAR enforces settlement. Most integrations go through its 1Click API, which returns a quote and a deposit address. There is no testnet, because fills come from real market makers with real liquidity. On Ethereum, ERC-7683 standardizes the order format so solvers can serve many front ends.
Intents and x402 solve different problems. “x402 says pay exactly this amount of this token to this address on this network,” the paper notes. Intents separate what the payer holds from what the payee receives. Combining the two, it argues, “is where most of the new use cases live.”
Why W2 fits
The paper’s case is that W2 already has the hard parts of an intent signer:
| Intent requirement | W2 already has | Effect |
|---|---|---|
| Sign an outcome, not a route | The passkey signs a hash of the typed intent | Solvers can rebuild transactions without breaking the signature |
| Bind chain and program | Network, program and deployment in every intent | An intent cannot be replayed on another chain or lookalike program |
| Deadline | Expiry slot, a 600-slot window | Stale intents fail on-chain |
| Replay protection | Nonces plus a separate intent ID | A filled intent cannot fill twice |
| Readable confirmation | The wallet renders the intent itself | The user approves the outcome, not opaque bytes |
| Bounded delegation | Session keys and child wallets | Agents can sign intents within on-chain limits |
| No native gas | The paymaster sponsors fees | A user holding only USDC can act |
What W2 cannot do yet is let a solver commit later. Today’s intents fix the recipient, amount and asset at signing time, so deferred solver commitment needs a new, versioned intent type.
Three ways to pair intents with x402
| Pattern | Who runs the intent | Protocol change | Best for |
|---|---|---|---|
| Buyer-side funding | The payer, before paying | None | Agents and users holding the wrong asset or chain |
| Seller-side sweep | The merchant, after settlement | None | Merchants who want one treasury asset |
| Intent as payment | Facilitator and solvers, during settlement | A new x402 scheme | Larger, less frequent purchases across assets |
The third pattern has a timing problem. x402 checks the payment before serving the resource, while solvers fill on their own schedule, so a facilitator would have to carry the risk of a fill that never comes. The paper notes that existing tools avoid this: NEAR-side agent libraries spot a 402, top up the needed token through intents, then pay with plain x402.
The three-stage plan
W2 would adopt intents in stages, each shipping only when the previous one has real use and its own test vectors:
- Stage 1, acquire then pay. A solver gets the required asset, then a normal x402 payment settles the merchant. On one SVM chain the swap and the payment can happen in a single transaction.
- Stage 2, an
xw2-intentextension. The payment carries a digest of the signed outcome: signer, verifier, ordered actions, deadline, a 256-bit nonce, limits and the settlement target. The W2 program enforces it on-chain. - Stage 3, a dedicated x402 intent scheme, proposed to the x402 Foundation only if deferred solver commitment turns out to be a common need.
At every stage, solver competition, routing and quotes stay off-chain. “What moves on-chain is only the check that the signed outcome happened.”
Use cases
| Use case | User signs | Stage |
|---|---|---|
| Pay in any asset | “Merchant receives 5 USDC; I spend at most X of my SOL” | 1 |
| Bridge cold start | “Funds from chain A arrive in my W2 wallet on X1, then pay this” | 1 |
| Agent top-up | A session-scoped budget per asset | 1 |
| Merchant treasury sweep | A merchant-side policy | 1 |
| Cross-chain checkout | “Merchant on chain B receives N; I pay from chain A” | 2 |
| Conditional purchase | “Buy only if the oracle price is below P” | 2 |
| Batched payroll | “These recipients receive these amounts by this deadline” | 2 |
| Price-limited orders | “Acquire Y at no worse than P before deadline D” | 2 or 3 |
Pay in any asset is the smallest version. The merchant keeps one simple price in USDC. A W2 user holding only SOL signs one outcome, and a solver swaps and pays in the same transaction. The user never holds USDC and the merchant never sees the swap.
Bridge cold start is the onboarding story. A new user with funds on another chain could pay for something on X1 in one journey: a Warp-assisted bridge delivers to the W2 wallet, the paymaster sponsors setup, and x402 settles. (For how Warp moves assets between Solana and X1, see our wXNT bridge coverage.) With counterfactual wallets, the first payment would create the wallet and repay its rent in USDC, so abandoned deposits cost the sponsor nothing.
What intents cannot promise
The paper is careful about limits. Intents guarantee the on-chain outcome a user signed; they do not make web delivery or cross-chain settlement atomic.
| Boundary | Atomic? | What W2 guarantees instead |
|---|---|---|
| Solver route + transfer on one SVM chain | Yes | All-or-nothing settlement |
| Payment + delivery of the resource | No | The payment is bound to the exact request |
| Source chain + destination chain | No | Separate receipts, timeouts, refunds and reorg handling |
| Intent signing + solver fill | No | An unfilled intent expires; a filled one cannot fill twice |
Solvers are untrusted: “They choose routes, never outcomes,” and the program rejects any fill that misses the signed recipient, amount, asset or limits. W2 allows only listed instruction shapes, so a solver cannot route through arbitrary programs, and each new DeFi route needs its own adapter. Bridges, new recipients and DeFi actions escalate to a wallet popup.
The paper also lists what no intent system can promise: a fill at all, since liquidity may be absent; a best price, only the signed limit; or recourse if the merchant never delivers.
Roadmap and open questions
Stage 1 needs no new protocol, only a solver adapter and receipts. The seven-step roadmap runs from a same-chain acquire-then-pay transaction, through a solver adapter interface, bridge receipts and an agent top-up policy, to the xw2-intent digest and an evaluation of W2 as a signer and verifier for NEAR-routed fills into X1. An upstream proposal to the x402 Foundation comes last, and only if stages 1 and 2 show demand.
The open questions are practical ones:
- Which solvers or market makers will quote X1 routes at launch?
- Who absorbs the fees when a solver starts a fill but fails: the solver, the paymaster or the user?
- Does stage 1 need a new intent type, or can the existing transfer intent carry the swap limits?
The first question may decide how far this goes. An intent is only as useful as the solvers willing to fill it, and the paper does not name any for X1 yet.
For the payment layer underneath all of this, read W2 × x402: passkey payments and agent budgets on X1.