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 |
| High-trust authoring | Create 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 and one assigned search range |
| Verify | Confirm a reported match | The recovered candidate and the available wallet ground truth |
| Recovery workflow | Complete wallet-side recovery and settlement | Depends on the custody mode |
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, case material enters secure intake.
- High-trust authoring derives the safe test piece and 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.
- Verify checks the signed context and confirms the result against the strongest available wallet evidence.
- The wallet is recovered and settlement is completed 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.
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. Blockchain.com confirmation depends on whether the full wallet is available; the minimal one-block test is followed by wallet-side ground truth in non-custodial recovery.
Current operating model
The signed protocol, coordinator, operator agent, wallet engines, and verification paths are implemented. Availability is controlled, and case authoring and settlement still include high-trust manual operations. 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, 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.
- Customer identity is not part of operator work.
- 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.