1. Request and review
The owner first submits information about the wallet and the password history. The public request form does not upload a wallet. Distribrute reviews ownership evidence, wallet format, likely search scope, and whether the case is suitable before any sensitive material is requested.
An accepted case is not a guarantee of recovery. It means the format and proposed search are technically reasonable.
2. Secure intake
The intake path depends on custody:
- Custodial: the encrypted wallet is submitted through a sealed high-trust intake path.
- Non-custodial: the full wallet remains on the owner’s computer; only the derived safe test piece enters the distributed system.
For direct uploads, supported case material is sealed before storage. Some Blockchain.com cases can begin from a wallet identifier rather than a local file; in that path, the encrypted backup must be retrieved before it can be sealed. It is still never distributed to operators.
3. Create the safe test piece
The wallet engine validates the file and derives the minimum material needed to test a password. That material is different for each wallet family:
- Bitcoin Core uses the password-encrypted wallet encryption key (
mkey) without encrypted private keys or public keys. This is not an HD master private key. - Blockchain.com uses exactly one encrypted block, its IV, and the wallet’s derivation settings.
The output is called a safe test piece. Its machine-readable form is also referred to as the safe extract. Read Safe test pieces for the security boundary.
4. Authorize and divide the search
A high-trust workflow creates a signed case manifest, pins the approved recovery tool, binds the safe test piece by hash, and defines bounded search chunks. A chunk may represent part of a wordlist or part of a password mask.
The coordinator leases one chunk to one approved operator device for a limited period. It can reassign expired work, but it cannot rewrite signed work without detection.
5. Test passwords
The operator agent verifies the manifest, chunk, and tool signatures before starting. The local runner tests only the assigned candidates against the safe test piece. It never receives the full wallet or the owner’s identity.
If no match is found, the agent reports completion and requests more work. If it finds a possible match, the candidate and its exact lease context are sealed for Verify.
6. Verify the result
The coordinator relays the sealed result but cannot read it. Verify decrypts the candidate, checks the signatures and assignment, and confirms that the candidate actually belongs to the leased search chunk.
It then applies wallet-specific ground truth:
- For a custodial Bitcoin Core case, Verify decrypts a real encrypted key and re-derives its stored public key.
- For a custodial Blockchain.com case, Verify decrypts the available wallet payload and checks the wallet structure.
- For a non-custodial case, the fleet match is confirmed against the safe test piece, but the owner’s full wallet remains the final wallet-side proof.
This distinction matters because a minimal test can have a false positive. An operator report alone never authorizes recovery or settlement.
7. Recover and settle
In a custodial case, Distribrute performs the wallet-side recovery inside the high-trust workflow. In a non-custodial case, the owner completes that stage during a guided session on the owner-controlled computer.
The intended settlement transaction pays the wallet owner, the specific operator who found the accepted password, and Distribrute. There is no operator pool. Today this stage is manually coordinated; automatic transaction construction and settlement are still planned.
For wallet formats that do not expose usable public addresses before decryption, transaction construction necessarily happens after the password is confirmed.
What each party receives
| Party | Receives | Does not receive |
|---|---|---|
| Wallet owner | Case guidance and final wallet-side recovery | Other operators’ identities or work |
| Finding operator | Safe test piece and assigned search chunk | Full wallet, owner identity, or spending keys |
| Coordinator | Signed work, leases, and sealed reports | Full wallet or plaintext reported password |
| Verify | Candidate and the wallet evidence allowed by custody mode | Authority to silently change the signed job |
If the search does not succeed
A search can exhaust the agreed candidate space without finding the password. Distribrute can then review assumptions and decide with the owner whether another targeted search is worthwhile. A compatible wallet remains locked if its correct password is outside every candidate space that was tested. Missing key material and unsupported wallet formats are different problems; see What we cannot recover.