The problem
The case for the verification layer.
When it comes to full self-custody and long-term planning, there are more things that can potentially upset a user than a typical green checkmark on a wallet can cover.
To illustrate why, we have assembled some 12 visual examples on this page.
The mechanism
A closed loop cannot find an error in itself.
One offline device: the closed loop
Same codebase grades its outputs.
The circle never opens. An error introduced at a code change, including one with security consequences, is confirmed by every check that follows and may remain undetected for a number of years. The report still shows a green checkmark.
DEVICE 1 APPLIES THE STANDARDS
its own way
DERIVES OUTPUTS
its own math
CHECKS ITS WORK
same code
REPORTS GREEN
self-verified
RESTORE DAY
Will it? See examples below
SAME CODE
START TO FINISH
THE REPORTS VOUCH FOR THEMSELVES
Concrete examples
How does the verification layer add value?
Picture the same wallet twice: keys made in 2021 on a non-default derivation path, and a perfect plate. The words are right and the master fingerprint matches, because a fingerprint is path-independent. The coins are on a branch the restoring wallet never looks at.
See the eight most common cases below. Click on each to see a typical example.
2021 · new wallet
Keys made on a non-default path. The plate is perfect, and nothing records which branch was used.
Story one: the path is discovered during a restore
Self-check: ✓ fine
Self-check: ✓ fine
Self-check: ✓ fine
Self-check: ✓ fine
✗ Failed recovery. The restore succeeds and shows a zero balance. The fingerprint matches, so the seed looks proven and the money is still missing.
Four green ticks, and the fingerprint matched every time. A matching fingerprint says nothing about which branch holds the coins.
Story two: the path is discovered on a Tuesday
Independent check: all four standards derived at once. ✗ The funded address appears under BIP44, not BIP84.
The right path written on the plate beside the words, re-verified until the first address matches.
Re-checks that mean something: dated records, not reassurance.
✓ uneventful. The restore works. The heir recovers. The proof checks out.
Same flaw. It just never got to hide behind a matching fingerprint.
The verification layer does not make flaws impossible. The issue above is identical both times. Instead, it moves its discovery date from a critical event when it matters to a random Tuesday when it does not. That is the entire case for the Verification layer in a complete self-custody solution.
Twelve examples
What may fail while green checks still pass.
Every case below passes the green mark checks a hardware or software wallet can run. Most of them can only be caught with an independent verification layer.
Twelve cases · open any row
-
01
The derivation path
Seed · xpubThe problem
The plate is perfect and the wallet still restores empty, because the coins sit on a path the restoring wallet does not default to. A master fingerprint is path-independent, so it matches anyway.
Passes on your hardware wallet
- BIP39 checksum
- wallet self-check
- master fingerprint
The verification layer · on the report
BIP84 m/84'/0'/0' — Native SegWit … Receive #0: bc1qcr8te4kr609gc… … BIP44 m/44'/0'/0' — Legacy … Receive #0: 1LqBGSKuX5yYUonj…Every standard path with its first address, so a wrong path is separable from a wrong seed. The record → The two stories →
-
02
The multisig descriptor
Multisig VerificationThe problem
Three keys are backed up safely. The definition that makes them a wallet is not. Key order changes the script hash, the addresses and the checksum, so every fingerprint can match while the wallet is a different wallet.
Passes on your hardware wallet
- every cosigner fingerprint
- each key’s own backup
- wallet self-check
The verification layer · on the report
Multisig Policy: 2-of-3 P2WSH [sortedmulti … … Descriptor Checksum: #arzs0zeh (VALID)
A 2-of-3 has no master fingerprint. The BIP380 checksum is its only identity, and it is on the sheet. The record → The two stories →
-
03
A BIP85 child
BIP85 Child VerificationThe problem
A child seed derived from a parent, backed up on its own. Years later you hold the words and nothing on the plate says which child they are. Read back as an ordinary seed phrase they verify perfectly, under their own fingerprint. An entropy reading cannot help either, because a verification measures how the bits look rather than how good the source was.
Passes on your hardware wallet
- BIP39 checksum
- the derivation table
- master fingerprint
The verification layer · on the report
Derived from master fingerprint: 73C5DA0A Derivation path: m/83696968'/39'/0'/12'/0' BIP85 index: 0 Word count: 12
A child gets its own report shape, naming the parent and the path the words alone cannot. What it still cannot do is prove those were the ones you meant: a wrong one would derive a valid child of a DIFFERENT wallet. The record → The two stories →
-
04
Electrum words
Seed VerificationThe problem
Words that look like any other seed, handed on with a note saying “BIP39 wallet”. An Electrum seed is not a BIP39 mnemonic, and an old/v1 wallet has no BIP32 master fingerprint to compare against at all.
Passes on your hardware wallet
- the words look ordinary
- wallet self-check
- the phrase is written down correctly
The verification layer · on the report
Seed Scheme: Electrum native (segwit) Backup format: Electrum seed phrase (native: NOT BIP39) Recovery path: … will NOT restore in a BIP39-only wallet.The report names the scheme and the wallet that restores it, which is the one thing the words themselves cannot tell you. The record → The two stories →
-
05
PSBT privacy review
PSBT ReviewThe problem
The transaction is correct and still tells a watcher more than you meant. One spend trips three observations at once: a round amount, an address reused inside the PSBT, and two inputs spent together. Privacy loss is not an error state, so no wallet raises it.
Passes on your hardware wallet
- amounts
- fee
- the signature
The verification layer · on the report
Privacy observations (rules of thumb, not guarantees) [round_amount] Output #1 pays a round amount (0.05 BTC). … [address_reuse] Output #1 pays an address (scriptPubKey) also spent as an input in this transaction (address reuse within this PSBT). … [multi_input] This transaction has 2 inputs. Spending them together publicly asserts they share one owner …Read out before a seed is entered, as observations rather than guarantees, so you can still walk away. The record →
-
06
The passphrase
Seed VerificationThe problem
The plate holds the twelve words. The passphrase lives in your head. The words are valid, so nothing refuses them. They simply derive a different, empty wallet.
Passes on your hardware wallet
- BIP39 checksum
- wallet self-check
- every wallet accepts the words
The verification layer · on the report
Passphrase Used: No Master Fingerprint: 73C5DA0A
One line beside the fingerprint. If your funded wallet used a passphrase and the report says No, that is the answer. The record → The two stories →
-
07
Seed XOR parts
Seed VerificationThe problem
Two parts stored apart, read as a threshold scheme. N-of-N means every part is required, and a part from a different split recombines to a valid-looking wrong seed.
Passes on your hardware wallet
- each part looks like a valid phrase
- wallet self-check
The verification layer · on the report
Backup format: Seed XOR 2-of-2 (N-of-N: all parts required)The report names the scheme, because the words alone cannot. The record →
-
08
SLIP-39 shares
SLIP-39 Backup VerificationThe problem
You believe two of three shares open it, and nobody has recombined them to find out. The recovered secret is a BIP32 seed that skips PBKDF2, so fed back as a mnemonic it derives a wrong wallet that works perfectly.
Passes on your hardware wallet
- each share’s own checksum
- share count
- wallet self-check
The verification layer · on the report
Backup format: SLIP-39 Shamir backup Recovery path: … NOTE: the recovered secret is a BIP32 seed: feed it DIRECTLY to the wallet (do not run it through the BIP39 passphrase / seed-stretching step).
Recombination is the only proof. Inspection cannot give it to you. The record →
-
09
A leaking signature
PSBT · nonce auditThe problem
A signer exfiltrates your key through the one field nobody inspects. A signature that leaks your key is a perfectly valid signature, so validity is not the test. The nonce is.
Passes on your hardware wallet
- the signature verifies
- the transaction is valid
- wallet self-check
The verification layer · on the station, at signing time
Verifying signature nonces (Dark Skippy defense)... PSBT nonce verification FAILED: class=dark_skippy ╔══════════════════════════════════════════════════════════╗ ║ SIGNATURE FLAGGED UNSAFE — NOT EXPORTED ║ ║ ║ ║ - Nothing was deleted. The flagged signature was kept ║ ║ on this device and will NOT be exported or broadcast. ║ ║ - A covert channel was attempting to leak your key ║ ║ through the signature. This device keeps no signing ║ ║ history, so it CANNOT tell whether earlier ║ ║ signatures from the same signer were broadcast. ║ ╚══════════════════════════════════════════════════════════╝
On the report
Signature nonce audit (Dark-Skippy) not evaluated (transaction not signed here)
The audit is a signing-time check, so the clean run prints All 1 signatures verified RFC6979/BIP340 deterministic and the review report of a transaction signed elsewhere says so rather than guessing. A signed session also leaves a class-only audit record (signatures checked, deterministic-nonce OK, own signatures audited) with no nonce, seed or key byte in it.
Sign on the station and the nonce is recomputed before the signature leaves it. That covers signatures this station produces. A cosigner signing on their own device is outside the check, and the record says so. The screens →
-
10
The heirs cannot act
Inheritance packageThe problem
Every cryptographic check passes. The folder is correct and nobody knows what to do with it: the one case here where no math fails, and the one that most often loses the coins. An heir imports the first key they find, sees a zero balance, and concludes the estate is empty.
Passes on your hardware wallet
- every derivation
- every checksum
- the whole package
The verification layer · in the package
INSTRUCTIONS.txt · Backup & Inheritance package · written to the heir
1. SEE THE FUNDS (no seed required) Import every extended public key the Confidence Reports list, not just the first. A wallet holds funds under several address types, and importing only one can show a zero balance while the others hold the funds. 2. TO RECOVER (spend) The Confidence Reports that verify a seed backup each carry a "Recovery path:" line naming the scheme and the procedure … (it is not always a BIP39 wallet — an Electrum, SLIP-39 or Codex32 backup restores differently). Not every report is a backup. An xpub, Multisig or Message report carries a "What this is for:" line instead, because those cannot recover or spend on their own.
INSTRUCTIONS.txt · BEFORE YOU TRUST ANY FILE HERE
An enclosed key proves nothing by itself. Anyone able to alter this folder could also replace the key and re-sign, and the check would still say "Good signature". What makes it meaningful is comparing the fingerprint gpg reports against the one the operator gave you through a different channel -- a phone call, a letter, in person. Never compare it against a fingerprint written inside this folder. A signature proves authorship, not device integrity.
The package is written to the person who will open it with no help available: which keys to import and why one is not enough, which line on each report says how to recover, and what a good signature does and does not prove. The package → The two stories →
-
11
Throws that were not random
Seed GenerationThe problem
Twelve words made from 128 coin flips that all came up the same. The words are a valid BIP39 phrase with a valid checksum, and every wallet accepts them. The wallet cannot see the flips, only the words. Randomness is the one property a seed cannot carry with it, so a verification of the words can never score it.
Passes on your hardware wallet
- BIP39 checksum
- wallet self-check
- master fingerprint
The verification layer · on the report
Seed Entropy (est): ~0 of 128 bits (WEAK) from 128 coin flips Assumes the throws were fair and independent. This device checked the numbers the user entered, not the throws behind them.
Scored only on generation, from throws you entered on the station. A seed born elsewhere gets no entropy line at all, because there is nothing honest to measure. The report says what it checked and what it assumed. The record → The two stories →
-
12
One wallet, four spellings
Multisig VerificationThe problem
The descriptor your coordinator exported is correct and half your wallets refuse it. A combined /<0;1>/* multipath descriptor is rejected by Electrum and older Bitcoin Core. A SLIP-132 Zpub key is rejected inside a descriptor by Core, Specter and Ledger. The same wallet re-spelled carries a different checksum, so a paste that fails looks like a wrong wallet, and a paste that succeeds with a different checksum looks like a mismatch.
Passes on your hardware wallet
- the descriptor checksum
- every cosigner key
- the coordinator’s own import
The verification layer · on the report
Multisig Verification · BSMS 2-of-2 · #hlydrcal
FULL DESCRIPTOR wsh(sortedmulti(2,[1cf0bf7e/48'/0'/0'/2']xpub6FL8F… …/<0;1>/*))#ywca8ep6 SINGLE-BRANCH DESCRIPTORS (for Bitcoin Core <=28 / Electrum) The combined descriptor above uses BIP389 /<0;1>/* multipath, which Bitcoin Core >=29, Sparrow and Specter accept. Bitcoin Core <=28 and Electrum reject it; for those, import both descriptors below (into the SAME watch-only wallet). Same wallet, same addresses. RECEIVE (/0/*): generates the addresses you share to receive funds: … #qdsmc9lu CHANGE (/1/*): internal change addresses your wallet uses automatically; import alongside RECEIVE, do NOT hand these out: …Multisig Verification · 2-of-3 with SLIP-132 keys · #2nf544wh
FULL DESCRIPTOR (as entered; its #checksum matches …) wsh(sortedmulti(2,[73c5da0a/48h/0h/0h/2h]Zpub74Jru6… …/*))#2nf544wh CANONICAL DESCRIPTOR (plain xpub — for Bitcoin Core / Specter / Ledger) The descriptor above uses SLIP-132 cosigner keys (a non-xpub form), which Bitcoin Core / Specter / Ledger reject inside a descriptor. Import THIS equivalent plain-xpub form there instead (same wallet, same addresses, different #checksum): wsh(sortedmulti(2,[73c5da0a/48h/0h/0h/2h]xpub6DkFAX…Every form the report prints is the same wallet, and the report says which wallets take which, so a rejected paste is a spelling problem you can see, not a key problem you have to fear. The receive and change branches come separately for the wallets that need them, with the warning that change addresses are never handed out. The record → The two stories →
Across the stack
Verification layer adds value in every aspect of self-custody
Every layer but the first produces something a witness can verify or prepare an independent Confidence Report for.
| Self-custody layer | Function | Tools at this layer | What the witness does in this layer |
|---|---|---|---|
| Buy | Acquisition | Exchanges, P2P | not this layer |
| Generate | Entropy, the seed itself | Dice, coins, a wallet's RNG | Warns about patterns in your own dice or coin throws and estimates their entropy (no hardware RNG in our seed code) throws that were not random |
| Store | Hot / cold custody | Hardware wallets, multisig | Re-derives the wallet definitions, descriptor, checksums, cosigner keys and prepares detailed accompanying reports. the multisig descriptor · one wallet, four spellings · the derivation path |
| Backup | Seed preservation | Steel plates, paper, shares | Proves the backup rebuilds the expected wallet across standards the passphrase · Seed XOR parts · SLIP-39 shares · a BIP85 child · Electrum words |
| Access | Spending, signing | Wallets, PSBT tooling | Audits PSBT files and signatures for privacy and exfiliation. Confirms a key controls an address today. PSBT privacy review · a leaking signature |
| Inherit | Estate transfer | Specialized companies and attorneys | Assembles a secret-free, optionally GPG-signed folder an heir, attorneys or a multisig group can act on. the heirs cannot act |
| Recover | Disaster recovery | Seed restore | Rehearses the restore in advance, singlesig or multisig the derivation path, on the day |
The verification layer
One more derivation in the circle.
The independent record
Two independent derivations, agreeing across standards.
Independent Confidence Reports confirm that the saved backup and its derivations are correct and recoverable. Third parties, attorneys and CPAs, receive a secret-free, signed and timestamped confirmation, and anyone can re-check it offline. Every report type, in the preview →
THE USER
Creates the wallet, descriptors and stores private keys on device 1
THE USER’S
VERIFICATION LAYER
Re-derives on device 2. Different code, offline
HEIRS OR THIRD PARTIES
Receive a secret-free and signed Confidence Report or a Package.
SUCCESSFUL RESTORE
On day X
DIFFERENT CODE
INDEPENDENT VERIFICATION
COMPLETE REPORTS
Keep reading
Who needs a witness?
The same five workflows, from the side of the person who needs them.