Roadmap
What we have done, and what comes next.
It reads from the top, like a story: first what we have built, then what we are working on now, then what is coming. Further down, the five phases from March 2027.
Updated 12 October 2026The phases count from March 2027
PullCap is new, and two of us are building it. The five phases start in March 2027. What already works, with the data, is on the main page, under “What works today”.
The story
From the first subscription to today, and beyond.
- Done
- In development
- In testing
- Coming next
Done · August – September 2026· 11 items
-
late August 2026
Subscriptions that pay themselves
You sign once from your wallet, and the payments go out at every due date.
-
late August 2026
A cap set by the payer
The payer writes the limit in their own wallet: above that number, the wallet refuses.
-
early September
Retries and grace period
A payment that does not go through is retried on its own; the seller chooses the grace period.
-
September
PullCap uses PullCap
Our own fee has gone through PullCap itself since 10 September, and anyone can sign the 1-sat-an-hour public plan since the 17th.
-
mid-September
Dashboard and API for sellers
Subscribers by status, payments, an export for the accountant, and a code per subscription to ask “is this one paid up?”.
-
mid-September
The payer’s page
Status, with the real reason when a payment does not go through, receipts, plan changes, and a link you can recover from your wallet if you lose it. No name, no email.
-
mid-September
Revocation recognised
When the payer removes the permission and the wallet says so, PullCap notices and stops on its own.
-
mid-September
Sealed authorisations
The part of PullCap that can be reached from the internet seals new authorisations, but cannot open them.
-
26 September
Two ways to sign
In one click with Coinos, or by pasting the connection of another NWC wallet.
-
27 September
The first wallet tests
Coinos, custodial, and Zeus on iPhone, self-custody, revocation included: what we saw.
-
29 September
The payment that arrives late
If a wallet pays after we have stopped asking, PullCap finds it, records it and tells both the seller and the payer. And a payment retried several times is paid only once, even if the wallet wakes up and finds all the requests at once.
In development · now· 3 items
-
now
The split key
The key that opens the authorisations, split across independent services: each one checks the request before giving its share. Whoever gets into only one of them cannot open them all at once: they must ask for them one at a time, only when they are really needed, and can be stopped.
-
now
Nobody suspended for a fault that is not theirs
An empty wallet is a late payment. A provider that does not answer, or a seller’s address that does not produce the invoice, are faults: they must be called by their name.
-
now
The new seal for every authorisation
The last authorisations from the old system move to the new one, and the ones no longer needed are destroyed.
In testing · now· 4 items
-
now
A plan ready to try
The 1-sat-an-hour public plan is for anyone: sign it from your wallet and see how easy it is to subscribe with PullCap. It is also where we test every wallet all the way: when the balance runs out, it has to stop and give the right reason. As of 12 October, 407 payments in a row.
-
since 26 September
Wallets on the phone
Zeus on iPhone and on Android, Primal on iPhone: whether a wallet on the phone pays even when nobody is looking at it. The tests are running, and what we see is on the wallets page.
-
29 Sep – 1 Oct
A phone acting as a node
Zeus on Android, on a phone that does only this, always on charge and with the screen on: a self-custody node that draws a few watts. In almost two days, from 23:37 on 29 September to 19:40 on 1 October, it paid 45 times out of 45, once an hour; then it stopped. It is a first step towards a test on a real node, to see how PullCap behaves in every respect.
-
since 2 October
Alby Hub, a node on a computer
Alby’s node, on one of our computers: the keys stay there, and no phone in between. It pays, and since 3 October it gets paid too: we signed up as sellers with the same node. It pays and gets paid as long as the computer is on. What we see is on the wallets page.
Coming next · in the coming months· 8 items
-
coming next
Your own Lightning node
The main test: paying and getting paid from your own node, which has to stay on and connected to the network at all times. We have started with Alby Hub, on one of our computers.
-
coming next
Four more wallets
Custodial and self-custody, for paying and for getting paid: they are on the wallets page.
-
coming next
One-click signing with more wallets
Not just Coinos: also the wallets that open the app directly.
-
coming next
Alerts for sellers, without email
A message in their wallet when something changes, and a webhook for those with a system of their own.
-
coming next
Changing the payout address
The seller moves to their own node without any subscriber having to sign again. The first to do it will be PullCap.
-
coming next
A guide to getting paid on your own node
To go from a custodian to your own keys, step by step.
-
coming next
An external review
Someone from outside looks at how we keep the authorisations.
-
coming next
The gate
A subscription that opens a door, without anyone keeping a log of who came in.
The plan · from March 2027
Five phases, and their milestones.
-
All year · from March 2027 planned
The sellers
It is not a phase that ends. We start from Lugano, from the Plan ₿ ecosystem, where paying in Bitcoin is already normal: we look for businesses that renew, and open the accounts by hand, one by one. Being close to the first sellers is how we find out what is wrong — from their customers, not from our tests.
Ongoingwe keep looking for new sellers.
-
Months 1–4 · March – June 2027 planned
The price and the company
The shape of the fee is set: tiered on active subscriptions, never a percentage, paid with PullCap itself. We decide the figures together with the first sellers. In the same period, the company and the legal opinion: PullCap never holds funds, and this has to be confirmed in writing by someone qualified to do so.
Milestonea public price list and a registered company.
-
Months 2–6 · April – August 2027 planned
Wallets — and the sellers’ keys
A subscription needs a wallet that answers even when nobody is looking at it, and on a phone that is not a given: it depends on the wallet, the phone and how you leave it. So far our tests have gone through four wallets: two custodial and two self-custody, on the phone and on a computer — what we saw, with the date. We will test more, and work with their developers where the protocol is missing something a subscription needs.
Your payments, your keys.
Sellers get paid on their own address, and the invoice is requested there at every payment: they can move from a service to their own node without any subscriber having to sign again. It needs a feature that does not exist today — changing the payout address — and it has to be built with care: you prove you own the new address, the old one gets a notice, and the change takes effect after 48 hours, and can be cancelled. The first to move to its own keys will be PullCap.
And self-custody is something we want to spread, not just allow: a public guide to getting paid on your own node, and meetings with sellers to make the move together.
Milestonea public list of tested wallets — for paying and for getting paid — with what works and what does not, a guide to getting paid on your own node, and at least one proposal sent to a wallet or protocol team.
-
Months 4–9 · June – November 2027 planned
The gate
Proving to a door that a subscription is paid up, without the door asking us anything — so nobody builds up a log of who went where and when. Three levels, from the simplest:
- Today. Every subscription has a code, and the seller’s system can ask whether it is paid up. That works for linking an account; at a door it does not, because a fixed code can be photographed.
- The gate on the phone. Whoever is at the door scans the code with the camera. The list of who is paid up is downloaded beforehand, as fingerprints, and nobody gets called from the door. The code changes by itself every few seconds, so a photo is not enough.
- The card. An NFC card that gives a new, signed code at every tap: the only form that is truly impossible to copy.
The first door can be an event: people come in now and then, and there is someone at the door. Then a coworking space or a gym — where you come in every day but pay every month. Transport comes later: there the gate has to work without a network too.
Milestonea working prototype at the entrance of a real seller.
-
Months 9–12 · November 2027 – February 2028 research
The payer’s history, without a name
Someone who has paid twelve months in a row has a history worth something. We want them to be able to show it — to another seller, or at the door of an event — without revealing who they are or where they paid, with anonymous credentials. It is research, not a promise.
Milestonea published design note and a proof of feasibility.
Fixed points
Whatever we build, this does not change.
- We hold nobody’s money. The sats go from wallet to wallet, and do not pass through us even for an instant.
- We hold nobody’s keys. We help sellers have their own; we do not hold them on their behalf.
- We do not ask payers for names. There is not even a place in the system to put them.
- We do not read the payer’s wallet. The permission asks for two things only: paying for the subscription and checking an invoice.
- Never a percentage of what you take in.
- We do not record who asks whether a subscription is paid up — neither from a website, nor from a door.
Building it together
Do you have a case we need?
If you sell something that renews to people who already pay in Bitcoin — a course, a community, a space, a series of events — or you have a door to open, write to us. We want to build the phases on this page with someone, not alone.
Changes
What changed, and when.
- In testing: our public plan, 407 payments in a row.
Earlier changes (14)
- In testing: our public plan, 382 payments in a row.
- In testing: our public plan, 360 payments in a row; and Rizful on the seller side too.
- In testing: our public plan, 336 payments in a row.
- In testing: our public plan, 288 payments in a row.
- In testing: our public plan, 263 payments in a row.
- In testing: our public plan, 241 payments in a row.
- The roadmap opens stage by stage, one glowing button each; the plan’s phases and earlier changes open the same way.
- The split key, said better: whoever gets into only one of them cannot open them all at once. In testing: our public plan, 213 payments in a row.
- In testing: Alby Hub, which now gets paid too, as a seller; our public plan, 192 payments in a row.
- In testing: the phone acting as a node paid 45 times out of 45 in almost two days, then it stopped; Alby Hub, a node on one of our computers; our public plan, 166 payments in a row.
- In testing: the always-on node paid 21 times out of 21 on its first day.
- Done: the payment that arrives late. In testing: wallets on the phone, now with Primal too, and an always-on node.
- Zeus on Android moves into testing.
- First publication.