• The state of the art is hostile
• The bigger frame — for the families who come after us
• Three modes, not one app
• Six small apps, not one large one
• The hard problems we do not get to skip
• What ships, and when
• Why I am doing this in public

I have two children. They are still young enough to think Robux is a currency. They are not yet old enough to ask me why some money has my face on it and other money lives inside a wallet I have to type a password into.

In about ten years they will need to understand both. Not as a hobby. Not as a financial-literacy elective. As a basic life skill — the way the previous generation needed to understand a passbook and a chequebook.

When they do, the software they will need is not going to exist. Not at the level a non-technical Indian family can use safely, without losing money to a typo at eleven o’clock on a Tuesday night. So I am building it. Eighteen design documents in. About twenty-four months from a v1.

This is what it looks like to design a Bitcoin product for people who will never read a whitepaper, in a country where most software is still designed elsewhere, for someone else.

§The state of the art is hostile

If you have used a Bitcoin wallet, you know the rough shape of the experience. There is a 12-word seed phrase you must write down on paper because there is no recovery if you lose it. There are addresses that look like dental codes. There are fees you might over-pay if you do not know which fee tier to pick. There are confusing concepts — UTXOs, change addresses, derivation paths — that leak through the UI in a way no other consumer software does.

Power users tolerate this because the alternative is a custodial wallet, where someone else holds the keys and can lose your money on your behalf. We have learned this lesson several times in the last fifteen years. We will probably learn it again.

But “tolerable for power users” is not the same as “usable for an eight-year-old who wants to send her grandmother a thank-you for a birthday gift.”

The wallets that try to be friendlier — the colourful ones with cartoon mascots — usually achieve friendliness by becoming custodial. They hold the keys. They can freeze the account. They can be acquired by a company with very different priorities than the founders had. They can run out of money. They are not Bitcoin wallets. They are fintech apps with Bitcoin-flavoured skin.

I want a Bitcoin wallet for my children that is not custodial, does not require them to memorise twelve words at age eight, does not freeze, cannot be confiscated by a startup that ran out of runway, and does not stop working when I die.

That sentence is the entire product brief.

§The bigger frame — for the families who come after us

This is not really only about my kids.

In twenty years, the children growing up in middle-class Indian homes today will have grown up with the rupee silently shaving away their parents’ savings, the way it has shaved away ours. They will inherit Bitcoin from us — a generation of parents who took loans, took risks, and bought it. The infrastructure they will need to use that inheritance does not yet exist in a form a non-technical family can adopt.

That is the real timeline. Not the next product cycle. Not the next funding round. Twenty years, and the next generation, and the question of whether the software they need is going to be built by people who care about families like theirs — or by venture-backed wallets that will be acquired and shut down before our children turn eighteen.

I am building it because someone has to, and because waiting for someone else to build it is not a strategy I have any more.

§Three modes, not one app

The first thing we got wrong on paper was assuming “a wallet is a wallet.”

A Bitcoin wallet for a 45-year-old parent is fundamentally different from a wallet for an 8-year-old who is just learning what saving means. They are different products. Forcing them into one app means one of them gets a bad experience.

So we split the design into three modes that a family member moves through, not into.

Observer mode is for kids old enough to receive Bitcoin but not old enough to control it. They can see their balance. They can see their transactions. They can ask for sats. They cannot send anything. The keys to their wallet are held — not by us, not by a company, but by their parent’s signer device. The child has a real Bitcoin wallet. The child does not have the keys for it.

Spender mode is the next stage. The child has their own daily wallet — a separate, small, intentionally limited wallet — that they can spend from. They cannot accidentally drain the savings wallet, because the savings wallet’s keys are still held by the parent. They learn how to send a transaction, how fees work, how to wait for a confirmation. They make small mistakes with small amounts. They learn.

Self-custodian mode is graduation. At an age the family decides — sixteen, eighteen, twenty-five, whenever the parent is ready — the child receives the full custody of their own wallet. New keys, generated on their own device, backed up by them, owned by them. The parent steps out. The child is now responsible for their own Bitcoin in the same way they are responsible for their own driver’s licence.

Most Bitcoin wallets give you mode three on day one and treat the other two modes as a UI problem. They are not a UI problem. They are different products with different security models, and the transitions between them are themselves products.

§Six small apps, not one large one

The other thing we got wrong on paper was assuming that all of this should live in a single application.

A daily spending wallet has very different security and UX needs from a multisig family savings vault. A signer device — the thing that holds the keys offline — should not be the same surface that browses transaction history. An inheritance plan, by definition, has to keep working after the user is no longer there to operate it. A “shared partner wallet” for two adults running a household together is yet another shape.

We landed on six small applications, each with one job:

• A signer — the thing that holds the keys. Airplane-mode-gated. Stateless if you want it to be. Optional persistent mode for users who would rather have a stays-logged-in experience.
• A daily wallet — the small spending wallet, used for everyday transactions, designed to feel like a payment app.
• A family wallet — for kids, with the three modes (observer, spender, graduation) baked in.
• A shared partner wallet — joint household finances, with both adults able to sign.
• A savings wallet — multisig, slow, for long-term storage. Designed to be hard to spend from on impulse.
• An inheritance wallet — the contingency plan. Has to work in scenarios where the original key-holder is no longer available.

Each app has a separate domain. Each app has a separate security model. Each app does one thing well.

A family does not see them as separate apps in the way a developer does. From the family’s perspective, they are using “the family wallet” — but that is a wrapper that knows how to talk to the underlying signer, how to coordinate with the shared wallet, how to read balances from the savings vault. Each surface stays simple because each surface refuses to grow into a god-object.

§The hard problems we do not get to skip

The reason most family-focused Bitcoin products either do not exist or are bad is that the hard problems are really hard. Here are the ones we cannot skip.

Recovery. If a parent loses their key, the family’s money does not disappear. The current best answer is SLIP-39 Shamir secret sharing — the master seed is split into N shares, M of which are needed to reconstruct it. Shares can live with relatives, in a safety deposit box, with a lawyer, on hardware. Three-of-five with five trusted humans is a fundamentally different security model than a single 12-word phrase you wrote down once and lost. We picked SLIP-39 because losing a key is not a power-user mistake — it is a foreseeable life event.

Inheritance. The wallet has to keep working after the original holder is no longer able to operate it. This is not a feature you bolt on; it has to be designed in from day one. The inheritance app is a separate surface, with its own security model, that lets a designated beneficiary recover access on a delay — long enough to confirm the original holder is actually unreachable, short enough that funds are not stranded for years.

Kid graduation. When a child becomes a self-custodian, their old wallet does not just hand them keys. The wallet transitions. New keys are generated on the child’s device. Funds are migrated from the parent-controlled wallet to the child’s new one in a series of transactions the child confirms. The parent’s signer is then removed from the child’s setup. This entire process has to happen smoothly enough that a sixteen-year-old can do it without their parent’s IT-friend on speed-dial.

Identity. Bitcoin addresses are unmemorable. We layered on Nostr public keys with NIP-05 aliases that double as Lightning addresses. So a daughter’s identity inside the system is something like alice.ross@onbitcoinstandard.com — not a 64-character address she has to copy-paste from a QR code. The identity is portable, the alias is human, and the underlying cryptography is uncompromised.

No fiat ramps. This is a deliberate choice. We are not building a place to convert rupees into Bitcoin. We are building a place for families that already hold Bitcoin to use it. Fiat ramps require KYC, require licensing, require partnerships that can be unwound by regulators. The product stays clean by staying out of that conversation entirely. If you do not have Bitcoin yet, this product is not for you. There are other places for that.

§What ships, and when

The roadmap is published. Six quarters from now, here is where we should be:

• This quarter: the signer plus the daily wallet. The two foundations.
• Next: the family wallet, with all three custody modes.
• Q4: the shared partner wallet.
• Q1 next year: multisig savings plus inheritance. The hardest two.

Eighteen architecture decision records sit in a public repository, each one explaining a single choice — why the signer is split-mode, why the identity layer is Nostr, why we use SLIP-39 instead of multisig for recovery, why the daily wallet uses Arkade and not Lightning channels, why the desktop shell is a PWA and not Tauri.

These ADRs are load-bearing on purpose. It is harder to abandon a product whose design rationale is published than one that lives only in your head. The ADRs are commitment devices. They are also an invitation — anyone reading them is welcome to argue, contribute, fork, or improve.

§Why I am doing this in public

I am not the first person to think about a family Bitcoin product. I will not be the last. Several thoughtful people have built pieces of this — wallets that handle kids, wallets that handle inheritance, signers that handle airplane mode. Almost no one has integrated the pieces. The few who have are early, incomplete, or proprietary in a way that makes me nervous about long-term commitment.

So I am building it. In public. With every architectural decision documented. With a domain my children will be able to use without me explaining what NIP-05 means.

Some of the design will turn out to be wrong. Some of the priorities will shift. The roadmap will slip — it is already slipping. None of that is a problem if the design rationale is in public, because the rationale is what survives. The implementation can change.

What I want, ten years from now, is for my children to use a Bitcoin wallet that does not depend on a company being still alive, on a phone OS being still supported, on a third party being still trustworthy. I want them to be able to send money to their grandmother and have the transaction work — the same way it works today, and the same way it will work in 2050.

That product does not exist. So I am building it. Slowly. In public. With my own children in mind.

If you are reading this and you have been waiting for the same product, you are welcome to wait for it. You are also welcome to follow along, criticise the ADRs, contribute to the design, or fork it and make a better version. Bitcoin works best when more than one of us is building.

The ADRs are at the repository linked from the OnBitcoinStandard family-wallet page. The roadmap is there too. The first two apps ship this quarter.

By the time my children are old enough to need this, it will be ready.

That is the only deadline that matters.