Yes to the first part, and there is a misconception in the second part that is worth untangling, because it changes what you actually end up protected by.
Importing an externally generated seed works
Restoring a seed created elsewhere is ordinary BIP39 import. The device derives keys from whatever seed you hand it, and a defect in its own seed-generation path is bypassed entirely, because that path never runs. So the plan is sound in principle.
But notice what happened: you did not remove the trust requirement, you moved it. Now the other device's entropy is the thing you are relying on, and that is the same class of question you were trying to escape. It only helps if the other source is one you can actually check.
Dice cannot be added on top of an existing seed
This is the part I would push back on. On a Coldcard, dice are an INPUT to generating a seed — the roll digits get hashed and that hash becomes the entropy. They are not a modifier you can apply to a seed you already have. There is no operation that takes an imported seed and mixes dice into it.
So "import a seed, then roll dice on top" is not a thing the device does. Two separate mechanisms are getting merged in the plan:
- Dice: produce the seed in the first place
- Passphrase (the BIP39 extra word): derive a completely different wallet from the same seed
Where a passphrase genuinely helps, and where it quietly does not
A passphrase does protect you against a compromised seed. Same seed plus a different passphrase is a different wallet, so someone who knows your seed but not your passphrase cannot reach those funds. For anyone worried their seed came from a weak keyspace, that is a real property, not a placebo.
The catch is what your security then rests on. If the seed is derivable by an attacker, the passphrase becomes your ONLY secret. And passphrases people can remember carry far less entropy than a 256-bit seed — you have quietly gone from 256 bits to maybe 40 or 60. Against an attacker who already knows the seed and is grinding candidate passphrases, that is a much weaker position than it looks. As a temporary shield while you move funds, fine. As the permanent arrangement, I would not.
The cleaner version of what you are trying to do
Generate the seed on the device from your own dice, then verify the derivation externally: `printf '<your rolls>' | sha256sum` on a separate machine, compared against the entropy hex the device shows. If it matches, the device used your dice and nothing else — you have proven it rather than trusting it, and you did not have to trust a second device's randomness either.
That gets you the property you were reaching for, with one fewer party to trust, and the check is pass/fail rather than a judgement call.
