What participants can see — and what they can't.

Threat model

The defense target is a financially-motivated participant attempting to monetize a recovered wallet rather than report it. Concretely:

• Theft of recovered private keys before settlement.
• Theft of recovered passwords for credential reuse against other services.
• Exfiltration of customer identity for downstream fraud.
• Silent withholding of a hit while pretending to keep working.

Out of scope: nation-state hardware attacks, NVIDIA / Intel / AMD root-of-trust compromise, novel published side channels we have not had time to patch around. We track those, but they are not what the participant agreement defends against.

The compute tier ships a ~40-byte verifier to each worker, never the wallet itself. Every supported wallet format has a structural property that lets us strip the encrypted payload down to a tiny non-sensitive header decryption plus the KDF parameters needed to verify a password attempt. Specifically:

• Bitcoin Core, Litecoin Core, Dogecoin Core — extract the encrypted master key only. The encrypted private keys live in wallet.dat, encrypted under the master key. Worker can derive the master key with the password, but can’t apply it to anything.
• Blockchain.com, MetaMask, MultiBit HD, Electrum 2.x, Dogechain.info — extract the IV plus the first 16-byte ciphertext block. Decryption yields a known plaintext header ("guid", xprv, \x0a?org.bitcoin.) which verifies the password but contains zero key material. The seed lives in subsequent blocks that are simply absent from the payload.
• Electrum 1.x — extract half the encrypted seed plus the IV. The full seed cannot be reconstructed from one half.
• Bither, mSIGNA — extract the last half of the encrypted private key plus 16 bytes of encrypted padding. Padding has predictable structure, verifies the password; half a private key is unrecoverable.
• Armory, Coinomi — same family: a minimal verifier plus the memory-hard KDF parameters, no recoverable key bits.

BIP39 partial seed recovery has no extract analogue. The PBKDF2 output of a candidate mnemonic is the BIP39 seed, and the seed alone is sufficient to derive every private key in the wallet. There is no construction that lets a worker test candidates without computing the seed itself. So for this class of recovery — and for password recoveries above a value threshold — we route work to NVIDIA Confidential Computing GPUs (H100, H200, B200) and rely on hardware-rooted attestation.

The attestation handshake proves four things before any work payload is sent:

1. The GPU is a genuine NVIDIA Confidential Computing SKU (signed by NVIDIA’s PKI).
2. CC mode is enabled in firmware.
3. The firmware version is on our policy allow-list.
4. The public key used to encrypt the work channel was generated inside the attested enclave.

If any check fails, work is refused. The handshake includes a fresh server nonce to prevent quote replay.

Inside the enclave, candidates, derived seeds, and any recovered key material live in encrypted VRAM. The host operating system — including a malicious host with root — cannot read them. Egress travels back over the same encrypted channel.

We don’t claim:

• Defense against side-channel attacks. Published cache, timing, and power side channels exist against CC and SEV-SNP. They typically require local access and known vulnerabilities; we track research and update attestation policy as new findings warrant. They are real, they are not in the participant-agreement threat model.
• Defense against vendor compromise. If NVIDIA’s attestation root is compromised or compelled by legal process, forged quotes would verify. This is the irreducible trust assumption at the bottom of any TEE system.
• Defense against bugs in our enclave code. Attestation proves the right binary is loaded; it doesn’t prove the binary is bug-free. Small TCB, public reproducible builds, third-party review.
• Anonymity for participants. The compute tier is not cryptographically theft-proof on its own. Real-name KYC and a binding participant agreement complete the defense. Anonymous participation is not offered.

The short answer is nothing.

• Case IDs displayed to participants are reshuffled per participant; an ID assigned to one participant for a chunk is not the same ID used internally or for another participant.
• Wallet addresses, customer names, contact information, jurisdiction — none of these are part of the work payload at any tier.
• Wallet value range is published only at aggregated, anonymized granularity.
• Match results are reported to Brute Brothers, not published to the fleet. Settlement happens off the fleet’s view.

The participant agreement prohibits attempts to deanonymize cases or correlate them across participants.

If you find a vulnerability in the agent, the extract format, the attestation flow, or anywhere else in the protocol, email security@distribrute.io. We publish a coordinated disclosure timeline. Bug bounty schedule will be published prior to mainnet onboarding.