Browse documentation
Live For wallet owners

Custodial vs non-custodial

How wallet custody changes intake, verification, the guided recovery session, and the trust placed in Distribrute.

Last reviewed Jul 22, 2026

What stays the same

Custody does not change the fleet’s access. In both modes:

  • Operators receive only the safe test piece and signed search work.
  • Operators do not receive the full wallet, direct customer identity fields, or spendable key material.
  • A possible password is sealed to Verify and independently checked, but the operator controlling the machine may inspect that candidate locally.
  • The signed case manifest declares how the success-funded operator pool is divided.

The custody choice changes where the full encrypted wallet lives and where final wallet ground truth is available.

Side-by-side comparison

QuestionCustodialNon-custodial
Who holds the encrypted wallet?Distribrute’s high-trust storageThe wallet owner
Who creates the safe test piece?Distribrute during secure intakeThe owner-side customer wallet extractor, or guided assistance
What does the operator fleet receive?Safe test piece onlySafe test piece only
Where is a match fully verified?Against the stored full walletExtract confirmation first; full-wallet proof on the owner’s computer
Where is wallet recovery completed?Distribrute’s high-trust workflowA guided session on the owner’s computer
When can spendable value be confirmed?After unlock when pre-decryption public records are insufficientAfter local unlock and wallet discovery
Primary additional trustDistribrute’s custody and settlement controlsThe owner computer and guided recovery software
Current operationImplemented with manual stepsImplemented with a manual guided session

Custodial flow

The owner submits the encrypted wallet through secure intake. Distribrute derives the safe test piece and retains the full encrypted wallet inside the high-trust verification boundary. If the fleet finds a candidate, Verify can test it against the complete wallet before the case proceeds.

Full-wallet custody does not guarantee that the wallet is funded. If usable addresses were not available before unlock, Distribrute may discover only after successful decryption that the wallet has no spendable balance.

This offers the strongest server-side confirmation and reduces demands on a non-technical customer. The tradeoff is straightforward: the owner trusts Distribrute to safeguard the encrypted wallet, the recovered password, and the final settlement process.

Non-custodial flow

The wallet remains on the owner’s computer. The customer extractor’s offline CLI or GUI reads a local Bitcoin Core, Blockchain.com backup, Electrum, or MultiBit wallet and emits only the safe extract. A separate opt-in Blockchain.com build can retrieve an encrypted backup by wallet ID while contacting only blockchain.info. Neither tool submits anything automatically to Distribrute.

Distribrute coordinates the search using only the safe test piece. The public contact form does not accept that extract today; it enters through a controlled post-review handoff. After an extract-side match, the complete wallet must be opened locally during a guided session before funds can move.

Non-custodial is trust-minimized, not trustless. Verify handles the reported password candidate, and the guided workflow must use it on an owner-controlled computer. A compromised customer machine could observe the password, private keys, or transaction-signing process and may prevent settlement from completing. No application can prove that a general-purpose host is clean.

The current process manages this risk with a recorded, guided ceremony and a narrowly scoped workflow. It does not eliminate the host risk.

The extractor covers safe-piece creation before the password search. It is not the planned Recovery Room application and does not receive a recovered password, unlock the wallet, construct a transaction, or sign it.

Transaction timing differs by wallet

Some Bitcoin Core wallets expose enough public information in the encrypted file to prepare parts of a transaction before unlock. Blockchain.com backups do not reliably expose the wallet’s usable addresses before decryption. Electrum legacy files vary, while Electrum 2.8+ BIE1 encrypts the wallet contents as a whole. MultiBit backups also do not provide a dependable complete address set before unlock. The recovery workflow therefore cannot assume that every unsigned transaction—or even the current spendable balance—can be established at onboarding.

The safe rule is to treat transaction construction as wallet-specific and to verify all destinations, amounts, and fees after the full wallet information is available.

This creates a success-funding risk for operators: the correct password may decrypt a wallet whose addresses have a zero balance or no spendable outputs. Password correctness alone does not create an operator reward. See Operator rewards and settlement.

Electrum is supported in both custody modes. In a non-custodial Electrum case, operators still receive only the wallet-specific safe test piece and the owner keeps the full wallet. A possible match remains probable until it is confirmed against that wallet during the guided local session.

MultiBit is also supported in both custody modes across the reviewed Classic .key, Classic .wallet, and HD formats. Non-custodial MultiBit matches follow the same probable-match rule and must be confirmed against the owner’s original wallet before recovery or finder credit proceeds.

The extractor also implements local Bitcoin Core and Blockchain.com-backup safe-piece creation. Those formats still require exact-file review and the same full-wallet confirmation after a non-custodial match.

Recovery Room is planned

Recovery Room is the proposed desktop application for the non-custodial ceremony. The design aims to:

  • isolate the wallet operation from the browser and ordinary meeting tools;
  • accept a narrowly scoped, authenticated password delivery;
  • build and display the transaction locally;
  • require the owner to review and approve the transaction;
  • sign locally and return only the signed transaction for verification and broadcast;
  • publish auditable source and reproducible releases.

It is planned and not implemented today. Current non-custodial cases use a manually guided process. See Implementation status whenever a future-state description and current availability need to be distinguished.

Choosing a mode

Custodial recovery is generally simpler for a non-technical owner and enables stronger full-wallet verification within the service. Non-custodial recovery reduces wallet custody by Distribrute but moves more responsibility and host risk to the owner’s computer.

The appropriate choice depends on the wallet format, value at risk, owner capability, and the threats that matter for the case. Distribrute reviews those factors before intake rather than treating one mode as universally safer.