Recurring-charge permissions on Solana · devnet
Every allowance your wallet gave, on one screen. Cancel one, and the next charge is refused.
CancelChain lists the recurring-charge permissions granted from a Solana wallet — by any app — and closes any of them with one signature. The refusal comes from the chain, not from a request to the merchant.
Devnet only. Every merchant here is a simulator, and the plans are invented. What is real, and what is played.
Up to 15.00 USDC every 30 days
0.00 USDC of 15.00 USDC used this period
- Recipient
- FGHMNo…22fBkKF
- Ceiling
- 15.00 USDC
- Period
- 30 days
- Spent this period
- 0.00 USDC
- Next charge
- 5 Nov 2026, 21:35 UTC
What you agreed to
A card token sits with the merchant, and it has no ceiling of its own. On Solana a recurring charge is now a permission that sits in your wallet, with a limit written into it. CancelChain reads every such permission granted from your wallet, whichever app asked for it, and gives each one a card.
Each card names five things without opening anything: who receives, the ceiling, the period, what has been spent this period, and when the next charge can come. 5 of 5 on every card.
A wallet holding 100 permissions is listed in full in 1.54 s (p95 of 40 first visits, budget 3 s, deployed stand, 7 October 2026).
Pulling the plug
Two clicks, one signature. Cancel on the card, sign in your wallet. The permission's account is closed — not relabelled "cancelled" and kept — so there is nothing left to charge against.
A cancelled permission is gone from the active list within 1.7 s of confirmation (worst of 20, budget 15 s).
The cancel of the card above: xZd8Y1…3zP39mY on the devnet explorer.
The merchant's next attempt
After a cancel, 0 of 200 charges succeeded — every one refused on chain because the account no longer exists (devnet, 2 September 2026, recurring permissions). A refused attempt reaches your activity list in under 5 s (worst of 20, budget 30 s).
While a permission is live, it still holds its ceiling: 0 of 200 attempts took more than the limit, each one a single base unit over what was left.
Activity · G76zDD…MzQW · as the app lists it
The merchant here is our simulator, and the wallet held no USDC — so the attempt before the cancel was refused for funds, and the one after it because there was no permission left.
A plan subscription ends on a date
A subscription to a merchant's plan is cancelled differently: it stops at the end of the period already paid for. The card says the date, how much the merchant can still take before it, and whether it already has.
The merchant can still take up to its plan amount this period — or has already.
On devnet the end date landed on the second the card predicted. Whether no charge gets through after it, over 50 attempts, has not been measured yet.
What is real here, and what is played
Real
The protocol, the permissions, the signatures, the cancel and the refusal. Every transaction on this page opens on the devnet explorer.
Played
Every merchant is tools/merchant-sim. Plans, names and charge history are synthetic. This is devnet, not mainnet. No real merchant has agreed to be paid this way, and nothing here tests that.
Not yet
Pausing a subscription. Taking back "do not renew". A merchant panel. And the first screen on a 3G phone: 4.6–5.1 s against a 2 s target (WebPageTest 3G, 7 October 2026) — being worked on.
Not ever
Card or bank subscriptions. Editing a permission's ceiling, period or recipient — the network has no such operation. Refunding part of a paid period — nothing is held in advance.
What it stands on
CancelChain has no on-chain code of its own. It works through the Subscriptions Delegation Program, De1egAFMkMWZSN5rYXRj9CAdheBamobVNubTsi9avR44, audited by Cantina/Spearbit. That audit is of the program, not of CancelChain.
Transactions are signed only in your browser. The server holds no wallet; it reads the chain and hands the browser a recent blockhash.