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; the customer wallet extractor derives the safe test piece locally, and only that result enters the distributed system through a controlled post-review handoff.
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. The controlled server-side path retrieves
the encrypted backup before sealing it. A separate owner-side GUID extractor can instead contact
only blockchain.info, retrieve the encrypted backup into the owner’s local process, and emit the
one-block safe extract. In neither path is the complete encrypted wallet distributed to operators.
The public recovery-request form remains contact-only. It accepts neither wallet files nor safe extracts; those steps happen only after case review.
3. Create the safe test piece
For a custodial case, the high-trust wallet engine validates the file and derives the minimum material needed to test a password. For a non-custodial case, the customer extractor reuses those same engines on the owner’s computer. 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.
- Electrum uses one IV and ciphertext block for legacy v1/v2 wallets, or a per-encryption ephemeral public key and 96-byte ciphertext segment for Electrum 2.8+ BIE1.
- MultiBit uses a one-block WIF check for Classic
.key, a bitcoinj header check for HD, or a padding-block check for Classic.wallet.
The output is called a safe test piece. Its machine-readable form is also referred to as the safe extract. The offline extractor does not submit it automatically; the owner deliberately transfers the string into the accepted-case workflow. Read Customer wallet extractor for the local tool and Safe test pieces for the artifact’s 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 direct owner identity fields.
The operator controls the host. A determined machine owner can inspect locally tested candidates, including the exact password if that machine finds it. Sealing protects the result after it leaves the device; it does not make the password secret from the device owner.
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 the strongest wallet-specific ground truth available:
- 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 custodial Electrum case, Verify cross-checks a decrypted legacy secret against the wallet’s public reference or validates a BIE1 candidate against the full-file HMAC.
- For a custodial MultiBit case, Verify checks the full backup for a complete valid WIF or the expected full-wallet structure.
- For a non-custodial Bitcoin Core, Blockchain.com, Electrum, or MultiBit safe-piece case, Verify records a probable match without marking the case recovered or activating finder credit. An authorized human must confirm it against the owner’s full wallet; a rejection returns the search to normal coverage handling.
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.
Many encrypted wallet formats do not reliably expose their usable public addresses before the correct password decrypts the wallet. The current spendable balance may therefore be impossible to confirm before operators commit compute. After decryption, the derived addresses may be empty, the funds may already have been spent, or the remaining value may be insufficient for settlement. A correct password can therefore produce no operator reward.
When funded recovery and settlement do complete, the signed case policy determines how the 10% operator pool is divided. The current default gives half of that pool to the finder and divides the other half among eligible non-finding operators by verified work; a case may instead use a signed winner-takes-all policy. Share calculation is implemented, but absolute payouts and settlement are still coordinated manually. Automatic transaction construction and settlement remain planned.
See Operator rewards and settlement for the full payment conditions and audit controls.
What each party receives
| Party | Receives | Does not receive |
|---|---|---|
| Wallet owner | Case guidance and final wallet-side recovery | Other operators’ identities or work |
| Operator device | Safe test piece, assigned search chunk, and local candidates—including a password it finds | Full wallet, direct owner identity fields, complete address list, balance, transaction history, 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.
A separate outcome is possible when the correct password is found but the decrypted wallet contains no spendable value. That is a correct technical recovery without a funded settlement or operator payout.