Roadmap

Now · A smaller, testable product

What you gain: the same supported wallet journeys with fewer alternate paths and clearer documentation.

Must pass: the real app creates a wallet, receives a payment, reviews and sends it, restores a backup, pays a person, and coordinates shared savings. Advanced features have their own documented journeys. Public feature descriptions and screenshots point to those tests.

Still to resolve: which boundaries, convenience APIs, duplicate tests, and undocumented features can be removed. Keep focused checks for cryptography, hostile inputs, and recovery failures that a successful screen flow cannot establish.

0.7 · An optional P2WSH Safe

What you gain: a separate, opt-in storage choice, explained under Advanced.

Must pass: create → receive → back up → restore on another installation → review and withdraw. The journey must exercise fresh change, exposure tracking, and refusal of damaged or incomplete backups.

Still to resolve: implementation and review of the Safe design and release criteria. Its limitations must be visible before funding. This milestone does not promise full post-quantum signing.

0.8 · Reliability through interruptions

What you gain: understandable recovery when the connection, app, or device interrupts a payment or sync.

Must pass: restart during sync, disconnect during sending, reopen a pending payment, increase its fee, restore a stale backup, switch networks, and recover after a chain reorganization. The screen, persisted wallet, and peer-observed transaction must agree.

Still to resolve: regressions found by those journeys and measured bandwidth, memory, and battery use on supported iPhones.

0.9 · A broader beta

What you gain: a defined feature set with usable recovery instructions and clearly stated limitations.

Must pass: new users complete everyday journeys and recovery using the published instructions. Feedback has a reproducible app scenario; critical regressions become tests of that scenario.

Still to resolve: the beta's supported devices, release blockers, and findings from broader use.

1.0 · A reviewed release

What you gain: a release whose review scope, evidence, and remaining limitations you can inspect.

Must pass: an independent security review, resolution of release-blocking findings, and verification of fixes against the intended release. Publish the exact reviewed revision and the journeys exercised.

Still to resolve: review findings and release readiness. A version target is not a security conclusion.

Signing devices, professional co-signers, and trusts

Potential user outcome: keep the everyday wallet on the phone while another device or an independent party participates in savings withdrawals. Unchained and trust providers are candidates to investigate, not Winnow partners or supported integrations.

Must pass before claiming compatibility: agree on the exact script and key derivation, independently verify receiving addresses, fund a test account, review and complete a real signing exchange, and recover after a device, participant, or coordinator becomes unavailable. Hardware tests must identify the model, firmware, desktop coordinator, and tested revision.

Must define before claiming independent approval: who controls each key and backup, whether any spending path bypasses the provider, who can spend without the owner, and how keys and policies are replaced. Test refusal, delayed or unavailable approval, and recovery. A signed metadata statement authenticates a statement; it cannot enforce these spending rules or certify protection against coercion.

Trust arrangements: qualified legal review must align authority, succession, and key access. Test an authorized successor’s recovery using the agreed process; a trust name in the app is not that process. Provider research and current limits.

Loans against bitcoin: a lending partner could provide stablecoins while bitcoin stays in a wallet shared by the borrower, lender, and an independent key agent. Any two could move it. The signers would apply repayment and liquidation terms; Bitcoin would only check their signatures. No lending partner or loan service is in place.

Tor and I2P · Private transports

Where this stands: versions 0.6 through 0.7.0 shipped an opt-in Tor route through an embedded Arti client. 0.7.1 removed it: the client brought several hundred Rust crates that nobody outside the project had reviewed, and a wallet that promises fail-closed privacy cannot carry an unaudited transport. The removed code, its tests and its license inventory are kept on the archive/tor-0.7.0 branch. Every connection the app makes today comes from the device’s own IP address.

What you would gain: peers, peer-list downloads and explorer lookups that do not reveal your connection’s IP address, and the ability to reach nodes that only exist on an overlay network.

Must pass before Tor returns: an independent review of the transport and its dependency tree, or a transport small enough to review in-house; a fail-closed journey on a real iPhone — Tor on, background, foreground, failure, explicit off — with no silent direct fallback; and measured battery and bandwidth cost of a circuit rebuilt on every foreground.

I2P: an embedded router is out of scope until one spike answers whether a router builds tunnels reliably at a foreground-only wallet’s uptime pattern. The decision record names emissary as the only candidate that builds for iOS today, what the spike must measure, and why i2pd is not it. A delegated router on hardware the owner controls remains the honest alternative.

2.0 direction · Research

Potential user outcome: an explicit, opt-in migration path when future Bitcoin capabilities are ready.

Before this becomes a release plan: establish the relevant network rules, interoperability, recovery behavior, and a complete migration journey. Research and prototypes do not count as shipping support.

Open work: the P2MR investigation and other roadmap proposals. No deployment date or automatic upgrade is implied.