x402 subscriptions: pay once with a pass, then sign in with your wallet

Version two of x402 added extensions, and one of them is sign-in-with-x. Its documentation describes it as a way for a client to prove control of a wallet that already paid for a resource, so it can get access again without paying again ^[2]. The client sends the proof in a request header named SIGN-IN-WITH-X ^[2].

Under the hood it follows CAIP-122, a chain-agnostic standard for signing in with a blockchain account ^[3]. CAIP-122 grew out of Sign-In with Ethereum, the EIP-4361 message format that wallets already know how to show and sign ^[4]. So the buyer signs a plain, readable message, not an opaque blob.

That is all a pass needs. Payment proves the buyer paid once. Sign-in proves the same wallet is back. Put the two together and you get x402 subscriptions with no new protocol, no account and no stored card.

Step one happens on the seller side. In SpendTheBits the seller opens a resource, taps Pass, sets a price and picks how long the pass lasts, from one day to a full year. The app asks for a pass price above the price of a single call, because a pass that costs less than one call makes no sense. The resource keeps answering normal x402 payments for anyone without a pass.

Step two is the purchase. The buyer pays once at the pass address, which is the resource address with pass added to the end ^[6]. It is an ordinary x402 payment, so any standard client can make it with no special code. Our server books the paying wallet as the pass holder for the chosen period.

Step three is every visit after that. The buyer calls the resource as usual. The payment request it gets back now carries a sign-in challenge with a fresh nonce, as the extension describes ^[2]. The buyer signs it with the wallet that paid, sends it back in the SIGN-IN-WITH-X header, and gets the content with no new payment.

Step four is the end of the period. When the pass runs out, the next request simply returns the ordinary payment request with the normal price ^[6]. Every x402 client already knows what to do with that, so renewing needs nothing new. If a holder buys again before the pass ends, our server adds the new days to the end of the old ones, so no paid time is lost.

Very little, and that is the point. Buying the pass is a normal payment, so an agent that can pay any x402 resource can buy one. The only new skill is answering the sign-in challenge.

When an agent calls a resource that sells passes, the payment request lists sign-in-with-x as a supported extension, with the message the wallet should sign ^[2]. An agent that holds a pass signs that message with the same key it paid with and sends the proof in the header. An agent that has no pass ignores the extension and pays per call as before.

This keeps old clients safe. A client that does not understand the extension never sees anything it must handle, and we only advertise the extension on resources that really sell a pass. Some buyer tools refuse a payment request that carries an extension they do not recognise, so adding it everywhere would break them for no reason.

For a developer, the change is a few lines: keep the paying key, sign the challenge when the answer offers one, and fall back to paying when the pass is gone. That fallback is what makes x402 subscriptions feel natural. An expired pass is not an error to handle, just the ordinary price coming back.

A pass is only worth selling if it cannot be copied. The sign-in-with-x documentation lists the checks a server must make: verify the signature, match the domain and address of the message to its own configured origin, respect the issued and expiry times, and accept each nonce only once ^[2]. We follow each of these, and two of them are where most mistakes happen.

First, the expected domain comes from our own configuration, never from the Host header of the request. If a server trusted the header, a proof signed for one site could be replayed against another that claims the same name.

Second, every nonce is ours. Our server creates it, ties it to one resource, and accepts it only once, within a short time window ^[2]. This matches the replay advice in EIP-4361, which says a nonce should be chosen with enough entropy to stop a captured signature from being used again ^[4]. When we tested a pass in production, sending the same signed proof a second time was refused ^[6].

The pass also belongs to a wallet, not to a person. Only the address that paid can sign in with it. Handing the URL to a friend gives them nothing, because they cannot sign for that wallet.

We do not describe a feature as live until it has moved real funds. In September our team bought a one-day pass on Base with an unmodified public x402 client and no SpendTheBits code. The payment was 0.02 USDC, and it is public on the Base explorer ^[5].

The same wallet then signed in with a sign-in-with-x proof and received the content without paying again. Our records show one free call made with that pass. A replay of the same proof was refused, as described above.

There are honest limits today. Our sign-in check supports ordinary wallets that sign with a private key. Smart contract wallets and Solana sign-in are refused cleanly for now rather than half checked, even though the extension itself describes both ^[2]. Passes also apply to resources with a fixed price per call, not to metered pricing.

Passes fit any resource that the same buyer calls again and again: a price feed, a risk score, a dataset that updates during the day. They also suit a seller who wants to reward regulars without building a billing system.

They fit less well for one-off calls, where plain pay per call is simpler and cheaper for everyone. A seller can offer both at once, and the buyer chooses.

For buyers, the appeal is control. Nothing is charged on a schedule, and nothing renews by itself. The wallet pays once, and when the period ends it decides whether to pay again. That is a subscription without a standing charge, which is what x402 subscriptions should be.

To start selling, read our guide to getting paid by AI agents and the walkthrough on monetizing an API with x402. If you are on the buyer side, paying an x402 API from your wallet covers the payment step, and the agents page shows everything sellers can switch on.