Where the secret lives: Bitcoin preimages, XRPL key recovery and Solana's signed bytes

Victoria Shinder04 October 2026, 13:002 min read

Three pieces of work on three different chains this week are, underneath, about the same thing: the secrets a user holds, and what happens to them at the edges.

Bitcoin: one backup for every secret. A proposal on Delving Bitcoin would let output descriptors carry the preimage behind a miniscript hash lock, written as sha256(preimage(HEX)), the way they already carry private keys. Today Bitcoin Core's wallet cannot accept such a secret at all except through PSBT fields set by another tool. The argument is that a preimage known in advance is a long-lived secret tied only to the script, exactly like a key, so it belongs in the same encrypted store and the same backup.

XRP Ledger: recovery as a designed feature. rippled has merged a ConfidentialMPTHolderKeyUpdate transaction for confidential token balances, which are encrypted under the holder's ElGamal key. A holder who still has the key can rotate it alone. A holder who has lost it can only register a new public key and wait for the issuer to complete recovery. The design accepts that confidentiality without a recovery path would make lost keys equal to lost funds, and chooses the issuer as the party who can restore access.

Solana: making sure what you sign is what gets sent. solana-web3.js 3.0 moves the classic JavaScript library onto Solana Kit and makes key generation and serialisation asynchronous. Among its fixes, the message header is now copied when a transaction is built so that later changes by the caller cannot alter the bytes that were signed, and the new wallet adapter refuses wallet output that drops the caller's signatures.

The common thread. Each change narrows a gap between what a user believes is protected and what actually is. In Bitcoin the gap is a secret stored outside the backup. On the XRP Ledger it is an encrypted balance nobody could reach after a lost key. In the Solana library it is a signed object that could still change in memory. None is a vulnerability disclosure; all three are the kind of detail that decides whether a loss is recoverable.

The trade-offs. Each fix moves risk rather than removing it. A descriptor that carries preimages becomes as sensitive as a seed phrase. Issuer-assisted recovery gives the issuer a role over a balance it otherwise cannot see. An async, stricter library breaks existing code, which its own notes call broad mechanical migration work.

What it means

For people running wallets and token programmes, the question to ask of each design is the same: where does every secret live, who can restore it, and is the thing signed the thing sent? This week three projects answered it explicitly. Teams building on any of them should check that their backups, recovery agreements and signing code match those answers.