Seed XOR
Split a seed into valid seeds
Splits one BIP39 seed into parts that are each an ordinary seed in their own right, and puts a set back together. Every part is required: N of N, with no threshold and no spare.
Overview and the all-parts rule
Overview
An implementation of the Seed XOR scheme on Passport Prime, an open standard that invites other implementations. Load a seed, choose two, three or four parts, and get that many seeds back, each a valid BIP39 seed that can be written down as words or transcribed as a SeedQR. Combining reverses it: say how many parts you have, load them in any order, and the original comes back. The same screens also make a new wallet, since XOR-ing seeds you already hold derives a fresh seed without changing anything about the originals.
This is an internal proof of concept rather than a production release. It runs as an SDK app, so it cannot read the device master key or the seed held in Seed Vault: the seed has to come in from outside by scan or by typing. Nothing is stored. Seeds and parts live in memory for a single session, the app holds no filesystem write permission so it cannot persist them even by mistake, and the mnemonic types scrub themselves when dropped.
What it does
- Split one seed into two, three or four parts, each of which is an ordinary BIP39 seed.
- Combine parts in any order to recover the original, or XOR seeds you already hold to derive a new wallet.
- N of N by design: every part is required, there is no threshold and no spare.
- A missing part does not fail loudly, it opens a different empty wallet, so the app states the all-parts requirement three times before generating anything.
- Entering the same part twice is refused, because a value XOR-ed with itself cancels to the all-zero seed.
- The optional checksum word is offered where the choice is made, with the trade-off stated: it confirms a correct set, and reveals three bits of the real seed.
- Parts are drawn from the hardware TRNG. The spec’s deterministic mode is deliberately not implemented.
- Nothing is written to disk: no filesystem write permission, and mnemonics are zeroed on drop.
Technical breakdown
How the proof-of-concept is built, for developers evaluating the platform.
The algorithm
Combining XOR-es the entropy byte arrays and recomputes the checksum. The specification describes XOR-ing 11-bit word indices while excluding the checksum bits, which is the same operation said differently, since the entropy is exactly the non-checksum bits. Working in bytes means there is no bit shuffling to get wrong. Splitting generates N-1 random parts and sets the last to the original XOR-ed with all of them.
Designing around the quiet failure
The risk in an N of N scheme is not a loud error, it is a silent one. Combining a subset does not fail: it produces a different valid seed that opens a real but empty wallet, and nothing on screen distinguishes that from success. The app therefore repeats the all-parts requirement before it will generate anything, and a test asserts that every proper subset of a split lands somewhere other than the original.
What it is allowed to touch
The signed manifest grants read-only filesystem access, the GUI template, theme-only settings, and the security permission narrowed to GetRandom alone. GetSeed is Foundation-only and deliberately absent, so the app cannot read seeds. The camera is never touched: scanning goes through the system QR scanner as a modal, which the build itself proves the permission for. Word lengths are limited to 12 and 24 because the SDK seed type accepts only 16 or 32 byte entropy.
Dig into the source
README, architecture notes, and the wire protocol live in the repo.