The core separation
Distribrute does not send an encrypted wallet to operator machines. It derives a wallet-specific safe test piece containing only the minimum material needed to test a password. The operator fleet receives that piece, signed work instructions, and an assigned search range.
The full wallet stays either in Distribrute’s high-trust storage for a custodial case or with the wallet owner for a non-custodial case. See Custodial vs non-custodial.
Components and boundaries
| Component | Main job | What it can see |
|---|---|---|
| Secure intake | Accept and seal case material | Contact details and the material the owner deliberately submits |
| Customer wallet extractor | Create the safe test piece on the owner’s computer for a non-custodial case | The local wallet file; the opt-in Blockchain.com path also handles the remotely retrieved encrypted backup in process memory |
| High-trust authoring | Create or validate the safe test piece and sign authorized work | The wallet material required by the selected custody mode |
| Coordinator | Break work into leases and collect reports | Opaque case IDs, safe test pieces, signed work, and sealed results |
| Operator agent | Run approved password-search tools | A safe test piece, one assigned search range, and every candidate tested locally—including a password it finds |
| Verify | Classify and confirm reported matches | The recovered candidate and the available wallet ground truth |
| Recovery workflow | Complete wallet-side recovery and settlement | Depends on the custody mode |
| Contribution and payout accounting | Record verified work and compute the signed operator-pool split | Opaque operator IDs, work units, audit standing, and payout ratios—not wallet value |
The coordinator is deliberately treated as semi-trusted. It moves work and ciphertext, but it does not need the full wallet or plaintext candidate results. Operator machines are treated as untrusted.
Data flow
- The owner submits a recovery request. No wallet is uploaded through the public contact form.
- After ownership and compatibility review, a custodial wallet enters secure intake. For a non-custodial case, the owner-side extractor derives the safe test piece locally and the complete wallet stays on the owner’s machine.
- High-trust authoring validates an owner-created safe test piece or derives one from custodial material, then signs the case manifest, approved tool, and search chunks.
- The coordinator leases one signed chunk at a time to an approved operator device.
- The agent verifies the signatures and tool hash before testing passwords.
- A possible match is sealed for Verify and relayed as ciphertext. The operator controlling the machine may already have inspected that candidate locally.
- Verify checks the signed context and the strongest available wallet evidence. A definitive full-wallet result can proceed; a non-custodial minimal-extract result remains a probable match.
- A probable match is confirmed or rejected against the owner’s real wallet before it can mark the case recovered or activate finder credit.
- Spendable value is discovered, the operator-pool split is computed under the signed policy, and settlement is coordinated using the selected custody workflow.
For the detailed path, read End-to-end recovery.
Protocol controls
Signed work
Case manifests, search chunks, and approved tool catalogs are signed with Ed25519. The safe test piece’s SHA-256 digest is part of the signed context, so a coordinator cannot silently substitute a different target. The agent rejects work whose signatures, hashes, or assignment do not match.
Sealed results
A possible password is encrypted for Verify using an ephemeral X25519 key agreement, HKDF-SHA-256, and ChaCha20-Poly1305. The lease context is authenticated as associated data. The coordinator relays the resulting ciphertext but cannot decrypt it.
This sealing protects the network and coordinator path. It cannot hide a candidate from the owner of the operator machine on which that candidate is tested.
Ground-truth verification
An operator-side match is never the final authority. Verify checks that the candidate belongs to the assigned work and then applies wallet-specific confirmation. Bitcoin Core can be confirmed against a real encrypted private-key record. Custodial Blockchain.com can be checked against the stored full wallet. Electrum legacy candidates can be checked by deriving the wallet’s stored public reference, while a custodial BIE1 candidate is confirmed by the full-file HMAC. Custodial MultiBit checks use the full backup to validate a complete WIF or the expected wallet structure. A non-custodial Bitcoin Core, Blockchain.com, Electrum, or MultiBit safe-piece match becomes a review candidate and requires owner-wallet ground truth before recovery and finder credit are activated.
Current operating model
The customer extractor, signed protocol, coordinator, operator agent, wallet engines, custody-aware
verification, probable-match review, contribution accounting, proportional payout calculation, and
audit controls are implemented. The extractor includes network-free CLI and GUI paths plus a separate
opt-in Blockchain.com transport that contacts only blockchain.info. No public tagged extractor
release or general self-service extract-submission field exists yet.
Availability is controlled, and case authoring and settlement still include high-trust manual operations. Absolute payouts are coordinated manually. A standalone self-service authorizer, automated settlement, and the Recovery Room desktop application remain planned.
See Implementation status for the feature-by-feature distinction between live and planned work, Customer wallet extractor for owner-side safe-piece creation, and Operator agent for the software that runs on operator hardware.
Security invariants
- The operator fleet never receives the full wallet.
- A safe test piece does not contain spendable private-key material.
- Each operator receives only an assigned, signed portion of the search.
- A reported match is independently verified before recovery proceeds.
- Direct customer identity and contact fields are not part of operator work, although password candidates can themselves contain personal information.
- Password correctness does not prove that the decrypted wallet contains spendable value.
- Non-custodial means the wallet stays with the owner; it does not mean the workflow is completely trustless.
The detailed assumptions and limits are documented in Trust model and Operator rewards and settlement.