How to read the labels
| Label | Meaning |
|---|---|
| Live | The implementation or operating workflow exists |
| Planned | Designed or proposed, but not implemented yet |
Live does not mean generally available, deployed to production, self-service, or free of manual steps. The “Current reality” column states those operational qualifications. These labels are not an uptime commitment or a promise that a particular wallet will be accepted.
Recovery service
| Capability | Status | Current reality |
|---|---|---|
| Public recovery request | Live | The form collects case information; it does not accept wallet files |
| Ownership and compatibility review | Live | A human reviews each case before secure intake |
| Custodial secure intake | Live | Encrypted wallet material is sealed into a high-trust path |
| Non-custodial recovery | Live | The wallet stays with the owner; probable matches require human confirmation against the real wallet, and final recovery is guided manually |
| Offline customer extractor | Live | CLI and GUI source implementations derive safe extracts for Bitcoin Core, Blockchain.com backups, Electrum, and MultiBit without a network dependency; there is no public tagged desktop release yet |
| Blockchain.com GUID extractor | Live | The separate opt-in wreq transport has been validated live on Linux and contacts only blockchain.info; 2FA-code wallets are unsupported and no tagged artifact is published |
| Self-service extract submission | Planned | The public request form does not accept extracts; an owner-created extract currently enters through a controlled post-review handoff |
| Recovery Room desktop app | Planned | The proposed local ceremony application is not implemented |
| Automated payout transaction | Planned | Current settlement requires manual coordination |
Distributed search and verification
| Capability | Status | Current reality |
|---|---|---|
| Signed manifests, chunks, and tool catalog | Live | Implemented; exact extracts, tools, and search assignments are signature-bound |
| High-trust case authoring | Live | Implemented as an admin-operated workflow rather than a standalone service |
| Lease-based coordinator | Live | Assigns bounded search work and relays sealed reports |
| Linux NVIDIA operator agent | Live | Supervisor, runner, enrollment, work loop, idle gating, and reporting are implemented |
| Signed agent packages and installer | Live | Release manifests, package verification, systemd installation, and container deployment paths exist |
| Reproducible agent and hashcat builds | Live | Both binaries can be rebuilt bit-for-bit from pinned inputs and compared with release provenance |
| Extractor build and release evidence | Live | Offline CLI release gates and a two-clean-build reproducibility check exist; CI compiles the opt-in GUID transport, while the defined multi-platform tag workflow has not yet produced a public release |
| Operator web portal | Planned | Operators do not have a self-service portal today |
| Automated identity-verification integration | Planned | Operator review and onboarding are currently controlled manually |
| Windows, macOS, or AMD operator agents | Planned | No supported operator release today |
| Automatic benchmarking and routing | Planned | Work placement is not yet a fully automated marketplace |
| Bitcoin Core wallet engine | Live | Safe test piece and full-wallet ground-truth verification implemented |
| Blockchain.com wallet engine | Live | One-block safe test piece and custody-aware verification implemented |
| Electrum wallet engine | Live | Legacy v1/v2 and 2.8+ BIE1 safe test pieces, operator modes, and custody-aware verification are implemented; exact files remain case-reviewed |
| MultiBit wallet engine | Live | Classic .key, Classic .wallet, and HD safe test pieces, operator modes, and custody-aware verification are implemented; exact files remain case-reviewed |
| Non-custodial probable-match review | Live | Minimal-extract matches remain non-terminal until a human confirms or rejects them against the real wallet |
| Contribution accounting | Live | Signed work units and accepted coverage are recorded for payout-policy calculation |
| Proportional operator-pool calculation | Live | Signed case policy supports a finder allocation plus effort-weighted eligible contributors; absolute settlement remains manual |
The wallet-engine labels mean their implementations exist. They do not mean every historical wallet variant is compatible or that every submitted case will be accepted.
Security and transparency
| Capability | Status | Current reality |
|---|---|---|
| Browser-side sealing for direct uploads | Live | Supported intake material is encrypted before storage |
| Signed device reports and sealed candidate results | Live | Implemented in the agent protocol |
| Supervisor and runner process split | Live | Separate processes and code-level data boundaries exist; both still run as the same service user |
| Signed release verification | Live | The agent verifies release signatures, listed file hashes, and package structure before installation |
| Reproducible binary verification | Live | Pinned build inputs and provenance comparison are implemented for the agent and bundled hashcat |
| Transparency-log implementation | Live | Log, checkpoint, and anchoring code exists; a public production log is not active |
| Canary audit and operator standing | Live | Signed audit jobs, verdicts, holds, disqualification, and payout-finalization gates are implemented; this is not a claim of an open public audit program |
| Strong operator process sandbox | Planned | Supervisor and runner are separate processes today; stronger OS isolation remains future work |
| Hardware-enclave verification | Planned | Not part of the current production trust boundary |
Service scope today
- Distributed recovery supports compatible encrypted Bitcoin Core, Blockchain.com/info, Electrum, and MultiBit wallet files. Electrum and MultiBit are available in custodial and non-custodial recovery.
- The customer extractor can derive a non-custodial safe test piece locally in source builds. Its existence does not turn the contact form into a wallet or extract upload surface.
- The service recovers forgotten passwords for supported encrypted wallets. Missing keys, seed phrases, and other unsupported cases are explained in What we cannot recover.
- Every case is reviewed before acceptance.
- Search success is not guaranteed, even for an accepted case.
- A correct password does not prove that the decrypted wallet has spendable value. Many wallets do not expose usable addresses before decryption, so an empty wallet can produce no operator payout.
- Operator-pool rewards require a funded recovery, eligible work, and completed manual settlement.
- Operators are onboarded through a controlled process rather than an open, anonymous marketplace.
This page is the source of truth when a higher-level page describes a future-state workflow. If a feature is marked planned here, its design may exist but the implementation should not be presented as complete. For live features, consult “Current reality” before inferring deployment or availability.