The project in one minute
Distribrute helps owners search for a forgotten password to a supported encrypted crypto wallet. The expensive search is divided among independent compute operators, but those operators do not receive the complete wallet. They receive a wallet-specific safe test piece and one signed, bounded range of password candidates at a time.
A possible password is not treated as a completed recovery. It is checked against the strongest wallet evidence available, the wallet is opened in the selected custody workflow, spendable value is confirmed, and settlement must complete before any success-funded fee or operator reward exists.
- 01
Request and review
Confirm the wallet format, ownership evidence, and a realistic password search.
- 02
Prepare safely
Keep the wallet in its custody boundary and derive a small, non-spendable test piece.
- 03
Distribute the search
Send signed, bounded password ranges—not the wallet—to approved operator devices.
- 04
Confirm and recover
Check a reported match against the real wallet before completing wallet-side recovery.
- 05
Settle if funded
Confirm spendable value and complete settlement before any success-funded reward exists.
The search is targeted rather than arbitrary. What the owner remembers about the password is turned into explicit wordlists or masks, divided into auditable chunks, and signed before distribution. The operator agent checks those signatures and its approved recovery tool before doing any work.
One search, two custody modes
Both custody modes use the same operator-side idea: send the safe test piece and assigned candidates, not the complete wallet. They differ in where the wallet lives and where final confirmation happens.
| Custodial recovery | Non-custodial recovery | |
|---|---|---|
| Complete encrypted wallet | Sent through secure intake and held inside Distribrute’s high-trust boundary | Remains on the owner’s computer |
| Safe test piece | Created during secure intake | Created locally with the customer wallet extractor or guided assistance |
| Operator work package | Safe test piece and signed candidate range | Safe test piece and signed candidate range |
| Final wallet confirmation | Against the securely stored wallet | Against the owner’s wallet during a guided session |
| Wallet-side recovery | Coordinated by Distribrute | Completed on the owner-controlled computer |
Non-custodial means the wallet stays with the owner. It does not mean no trust is involved: a guided recovery still handles a reported password, and the owner’s computer becomes part of the security boundary. The detailed tradeoffs are covered in Custodial vs non-custodial.
The customer extractor has separate offline CLI and GUI interfaces for local wallet files. Its
opt-in Blockchain.com GUID build contacts only blockchain.info to retrieve the owner’s encrypted
backup and still requires the owner to hand off the resulting safe extract deliberately. The public
recovery-request form does not accept an extract directly.
Who can see what
The system separates roles so the machines doing the bulk password search do not also receive the material needed to spend the wallet. That boundary has one important, explicit limit: an operator controls its own machine and can inspect every password candidate tested there, including the exact password if that machine finds it.
Controls the recovery
Can access
- The original wallet and recovery context
- The final wallet-side recovery
- The recovered value and destinations
In non-custodial recovery, the full wallet stays on the owner's computer. Custodial recovery sends the encrypted wallet through high-trust intake.
Coordinates and verifies
Can access
- Submitted case and ownership information
- Safe test pieces and signed work
- Reported candidates inside high-trust Verify
The fleet-facing coordinator cannot open sealed reports. It does not need the complete wallet; high-trust services receive only what the selected custody mode requires.
Tests assigned passwords
Can access
- The wallet-specific safe test piece
- Its assigned candidate range
- Every candidate tested locally, including a password it finds
No complete wallet, direct owner fields, balance, transaction history, or complete spendable key material is sent to the operator.
Sealing protects a reported candidate while it travels through the coordinator. It does not hide that candidate from the operator host where it was tested. The recovered password may contain personal information chosen by the owner, but without the complete wallet or complete spendable key material it does not by itself grant control of the funds. See the Trust model for the complete assumptions and limits.
When a recovery becomes payable
Password correctness and financial success are separate facts. Many encrypted wallet formats do not expose a dependable set of public addresses before decryption. The correct password can therefore open a wallet whose addresses have a zero balance, whose funds were already spent, or whose remaining value cannot support settlement.
The operator controlling that device may already have inspected it locally.
A minimal check can be a false positive.
The wallet can now be opened.
The password can be correct while the operator reward is zero.
Value, destinations, fees, and eligibility are checked.
No completed funded recovery and settlement means no success fee or operator payout.
For a funded recovery that completes settlement, the owner receives 85% of recovered value, the signed operator pool receives 10%, and Distribrute receives 5%. The operator pool is not necessarily a winner-takes-all bounty: the current default gives half of the pool to the finder and divides the other half among eligible non-finding operators by verified work. Read Operator rewards and settlement for the conditions, audit rules, and current manual settlement boundary.
Supported wallets
| Wallet family | Currently reviewed encrypted formats |
|---|---|
| Bitcoin Core | Supported encrypted wallet.dat files |
| Blockchain.com | Supported historical Blockchain.info and Blockchain.com backups |
| Electrum | Legacy v1/v2 and Electrum 2.8+ BIE1 wallet files |
| MultiBit | Classic .key, Classic .wallet, and HD mbhd.wallet.aes backups |
Exact compatibility is reviewed before a case is accepted. Unsupported formats, missing private-key material, partial seed phrases, and raw private-key discovery are outside the distributed recovery model. See What we cannot recover.
Where to go next
- Follow a case step by step: End-to-end recovery.
- Understand the software and trust tiers: System architecture.
- Create a safe test piece locally: Customer wallet extractor.
- Inspect what operators actually receive: Safe test pieces.
- Compare current code with planned work: Implementation status.
- Review the security assumptions: Trust model.
- Understand compute work and rewards: Operator agent and Operator rewards and settlement.