Bring Your Seed to the Device
Multisig should diversify how your keys are born, not just the logos printed on the boxes that hold them.
Bitcoiners love buying hardware wallets.
Buy one from Company A. Buy another from Company B. Add a third from Company C. Put them into a two-of-three multisig setup and congratulate yourself for eliminating vendor risk.
That is better than trusting one device.
But there is a hole in the ceremony that almost nobody talks about.
Where did the seeds come from?
In most setups, every seed was generated by the hardware wallet itself. Different manufacturers, different cases, different screens, different firmware, but the same basic ritual. Turn on the device, let the device produce the secret, write down the words it gives you, and trust that the little box did everything correctly.
That is not eliminating trust. That is distributing trust among three black boxes.
We have spent years telling people, “Not your keys, not your coins.”
Fine.
But if a manufacturer created the key and handed it to you, was it ever completely yours?
The manufacturer should not create your secret
The signing device has an important job. It should protect key material, derive addresses, display transaction details, and sign only after you verify what is on its screen.
Creating your original secret does not have to be one of those jobs.
I want to bring my seed to the device.
That means generating the entropy independently, offline, through a process I can observe and reproduce. Then I want to convert that entropy into a BIP39 mnemonic, import the mnemonic into the signing device, and compare what the device derives against an independent calculator.
The device does not get to tell me both the question and the answer.
It receives a secret I created, derives the wallet, and proves that it reached the same result.
That separation matters.
Multisig needs entropy diversity
The standard multisig pitch focuses on vendor diversity.
One Coldcard. One SeedSigner. One Jade. One Trezor. Pick your combination.
There is value in that. Different firmware, chips, secure elements, transaction parsers, and signing implementations reduce the chance that one failure compromises every signer.
But hardware diversity and entropy diversity are not the same thing.
If three devices each generate their own seed internally, you still have three ceremonies built around the same assumption: the manufacturer’s random number generation process did what it claimed to do.
My preferred setup is different.
Seed one might come from coin flips.
Seed two might come from dice rolls.
Seed three might come from hexadecimal entropy produced through a separate offline process.
The exact combination can change. The principle does not.
Each key should have a different origin story.
Now a failure in one entropy method does not automatically contaminate the others. A biased die, a bad coin-flip transcript, a broken implementation, or a flawed procedure remains a serious problem, but it is no longer the single hidden assumption beneath the entire quorum.
That is actual defense in depth.
The logos on the devices become secondary. At seed creation, the process matters more than the manufacturer.
Why I forked EntropyLab for the ESP32-P4
That is the thinking behind my unofficial EntropyLab ESP32-P4 fork.
It is not a hardware wallet. It does not sign transactions. It is an offline educational seed, mnemonic, fingerprint, and derivation calculator built for a touchscreen ESP32-P4 board.
The project accepts entropy supplied by the user instead of pretending entropy is magic happening somewhere inside a sealed box.
The current public project supports multiple input families, including hexadecimal entropy, raw coin flips, dice methods, BIP39 words, numbered word-list input, card-based methods, and externally generated values represented through several bases. Each method carries its own assumptions and warnings.
That last part is important.
A BIP39 checksum does not prove that a seed is random.
Hashing bad dice rolls does not manufacture missing entropy.
Two hundred fifty-six bits displayed on a screen does not mean you created 256 bits of unpredictability.
Software can verify conversion and derivation. It cannot reach backward through the screen and prove that your coin was fair, your die was unbiased, your deck was shuffled properly, or your procedure was not predictable.
Entropy still requires human discipline.
The fork’s job is narrower. Take user-supplied input, apply an explicit method, produce the mnemonic, and derive outputs that can be checked elsewhere. The current pipeline can show the BIP32 master fingerprint and a first BIP84 receive address. Those give you something concrete to compare when the mnemonic is imported into a signing device.
If the fingerprint or address does not match, stop.
Do not fund the wallet. Do not assume the prettier screen is right. Find the disagreement.
Create, verify, import
The ceremony I want is simple in concept:
- Create the entropy offline. Use a documented physical or external method. Record the procedure carefully enough to avoid transcription mistakes, but never photograph, upload, or type the secret into a connected computer.
- Convert and derive on an independent offline calculator. Generate the BIP39 words, fingerprint, and verification address.
- Import the mnemonic into the signing device. The signer receives the seed. It does not create it.
- Compare the results. Confirm the master fingerprint and derived address on both devices before funding anything.
- Repeat with a different entropy method for each multisig key. Different creation method, separate backup, separate signer, separate location.
This does not eliminate every risk.
The calculator could be compromised. The signing device could be compromised. The physical entropy could be weak. The person performing the ceremony could make a mistake. The ESP32-P4 board itself includes an ESP32-C6 wireless coprocessor, so offline application behavior should not be marketed as a mathematically proven air gap.
There is no honest setup where trust goes to zero.
The goal is to stop allowing one device to own the entire chain of custody from randomness to signature.
Stop outsourcing the beginning
Hardware-wallet companies have trained us to treat seed generation as a feature of the product.
I think that is backward.
The seed is not a feature of the device. The device is a tool that serves the seed.
Your signing device should be replaceable. Your manufacturer should be replaceable. Your coordinator should be replaceable. The secret at the root of the wallet should come from a ceremony you control, using assumptions you understand.
Multisig is supposed to protect us from a single point of failure.
So why would we create every key through the same kind of black box?
Use different signing devices if you want. That still has value.
But go one level deeper.
Use different forms of entropy. Create each seed independently. Verify each result on a second device. Make every key earn its place in the quorum.
Do not ask the hardware wallet to create your sovereignty for you.
Bring your seed to the device.
FF2K