Cake Wallet currently has no on-device threshold/secret-sharing backup for the seed itself — RecoverBull is an encrypted cloud backup, which is a different (and complementary) thing. I'd like to propose adding a true n-of-m threshold split of the BIP39 seed, and I have a tested core ready.
The idea: split a seed into m shares such that any n of them reconstruct it, and any n−1 reveal nothing (perfect, information-theoretic confidentiality up to the threshold). For example 2-of-3 or 3-of-5: hand shares to different people/locations, lose some, still recover — but anyone holding fewer than the threshold learns nothing about the seed.
Two properties make this user-friendly compared to SLIP-39 / Shamir:
- Each share is a standard BIP39 mnemonic of the same word count as the seed (not a separate wordlist). It looks and stores like any other seed.
- Recovery is plain XOR — no finite-field arithmetic beyond GF(2). A user can reconstruct from a backup by hand if they ever need to, with pen and paper.
This is the Kurihara et al. ideal (k,n) XOR scheme (ISC 2008, eprint.iacr.org/2008/409). I wrote up the BIP39 adaptation, pen-and-paper templates and the security properties here: https://doi.org/10.5281/zenodo.20734041 (CC BY 4.0). It already ships in Krux (selfcustody/krux#883) and I've proposed it to SeedSigner (SeedSigner/seedsigner#43) and BlueWallet (BlueWallet/BlueWallet#8697).
What I have ready for Cake Wallet:
- A pure-logic Dart core —
cw_core/lib/kurihara.dart — with no new dependency (only the bundled bip39 package).
- Off-device tests —
cw_core/test/kurihara_test.dart, 19 tests incl. a 3-of-5 split→restore round-trip that returns the identical mnemonic. Passes dart format -l 100 and dart analyze clean against your analysis_options.yaml (lints/recommended + strict-casts).
- Branch: https://github.com/CaverneCrypto/cake_wallet/tree/add/kurihara-threshold-backup
- No UI wiring yet — I didn't want to presume on UX. If you're interested, I'd follow up with the split flow (on wallet create/backup) and a restore-from-shares flow, modeled on the existing seed entry screens.
A note on thresholds: the valid m depends on the seed length, because the scheme splits the secret into (prime−1) byte-aligned fragments. Rather than hardcode a single cap, the core exposes validThresholds(numBits) so the UI can offer the right options per seed: 12/24-word seeds give m ∈ {2..5}, and since Cake Wallet's restore accepts any standard length, an imported 18-word seed reaches up to 7-of-7. m is capped at 7 to avoid impractically large splits.
Would a BIP39-native, pen-and-paper-recoverable threshold backup be something you'd want in Cake Wallet? Happy to open a PR with just the core for you to run first, and to build the UI on top if there's interest. Thanks!
Cake Wallet currently has no on-device threshold/secret-sharing backup for the seed itself — RecoverBull is an encrypted cloud backup, which is a different (and complementary) thing. I'd like to propose adding a true n-of-m threshold split of the BIP39 seed, and I have a tested core ready.
The idea: split a seed into m shares such that any n of them reconstruct it, and any n−1 reveal nothing (perfect, information-theoretic confidentiality up to the threshold). For example 2-of-3 or 3-of-5: hand shares to different people/locations, lose some, still recover — but anyone holding fewer than the threshold learns nothing about the seed.
Two properties make this user-friendly compared to SLIP-39 / Shamir:
This is the Kurihara et al. ideal (k,n) XOR scheme (ISC 2008, eprint.iacr.org/2008/409). I wrote up the BIP39 adaptation, pen-and-paper templates and the security properties here: https://doi.org/10.5281/zenodo.20734041 (CC BY 4.0). It already ships in Krux (selfcustody/krux#883) and I've proposed it to SeedSigner (SeedSigner/seedsigner#43) and BlueWallet (BlueWallet/BlueWallet#8697).
What I have ready for Cake Wallet:
cw_core/lib/kurihara.dart— with no new dependency (only the bundledbip39package).cw_core/test/kurihara_test.dart, 19 tests incl. a 3-of-5 split→restore round-trip that returns the identical mnemonic. Passesdart format -l 100anddart analyzeclean against youranalysis_options.yaml(lints/recommended + strict-casts).A note on thresholds: the valid m depends on the seed length, because the scheme splits the secret into (prime−1) byte-aligned fragments. Rather than hardcode a single cap, the core exposes
validThresholds(numBits)so the UI can offer the right options per seed: 12/24-word seeds give m ∈ {2..5}, and since Cake Wallet's restore accepts any standard length, an imported 18-word seed reaches up to 7-of-7. m is capped at 7 to avoid impractically large splits.Would a BIP39-native, pen-and-paper-recoverable threshold backup be something you'd want in Cake Wallet? Happy to open a PR with just the core for you to run first, and to build the UI on top if there's interest. Thanks!