THE UNIVERSAL QUANTUM SEED
UQS addresses a different part of the long-term security model: generation, transcription, and recovery of the wallet's root seed.
The 36-word UQS format encodes 272 bits of entropy and includes a 16-bit checksum.
It is more secure than the current 12-word BIP system; however the 36-word UQS visual icon format implies that the seed backup must be stored digitally. Is there any way to write it down on a piece of paper, or must it be kept in digital form?
I really don't think we'll be able to write visual representation down by ourselves, but I know that since there's an option of using it as a cold storage setup, then it means there would be a provision to back it up, a quick guess should be exporting it in QR code format, then print and store offline. so when you want to reimport, it's scanned by the wallet and the keys retrieved to set it up. It would be good if madebylock clears the air on this as well.
Yep, you can absolutely back UQS up on paper. The visual icons are not a requirement for digital storage, and you do not need to keep a screenshot or QR code.
The intended recovery model is still the familiar one: record the seed phrase in order, store it offline, and re-enter it later if you need to recover. For the 36-word UQS format that means writing down all 36 words in the correct order, including the final two checksum words.
The icons are an additional recognition layer. Each of the 256 words has a corresponding icon, and the same icon is mapped across 42 language tables. So the visual representation is there to make recognition and cross-language recovery easier, not to force a digital backup.
If you prefer something printed rather than handwritten, Treasury also supports explicit seed export/print flows. But that is optional, and we would treat any generated PDF/file/print job as sensitive secret material.
And if you use the optional seed passphrase, that needs to be preserved as part of your recovery plan too.
So the short version is:
paper backup is fully supported; QR is not required.
It's not something that will make me switch my existing setup but its other features are worth checking out.
That is a reasonable position. We are not expecting someone with a working offline Electrum setup to replace it simply because another wallet has more features.
“Modular” captures part of the design, but the important distinction is separation of authority rather than just reducing the size of each binary.
Treasury owns the seed-dependent operations. Node handles public-chain connectivity. Wallet handles the everyday presentation and orchestration. Requests cross explicit authenticated boundaries rather than those roles sharing unrestricted access to the same private state.
That is not a claim that Treasury contains nothing except a tiny signing function. It has supporting services and domain handlers, and those still need review. Equally, the presence of additional code in an Electrum binary is not, by itself, evidence of a security weakness.
The comparison we think matters is what each running component can access, which inputs it accepts, and what a compromise would authorise.
For your existing Bitcoin setup, the practical benefit may be limited. The broader use case is making isolated signing available across other supported assets and workflows without putting the seed into the everyday online interface.
I understand the architecture, but I hope the final product is simple enough that a non-technical person can actually use it
That is the goal. Someone should not need to understand key encapsulation, process isolation or a Lightning state machine to use the wallet.
The technical explanation is for people who want to examine the security model. The everyday experience should make a much smaller set of things clear: which device holds the keys, what you are authorising, whether the signing device is available, and how to back up and recover.
There is a real trade-off we should make visible, though. The high-security setup uses a dedicated Treasury device, so it involves more setup than installing a conventional wallet on one phone. We will make that process understandable rather than hide the difference.
For us, useful usability feedback is whether someone can set it up, pair their devices, understand a transaction and complete a recovery without having to read the whitepaper.
That has to be demonstrated through the product. A clear architecture diagram is not the same thing as a clear user experience.
Which part feels least intuitive to you at the moment: the separate signing device, pairing, or the backup process?
