Some wallet backups need more than a seed phraseSome wallet backups need more than a seed phrase

Rewind is a bit of hack at creating a vault. Here's how it works:

A vault-enabled wallet locks funds to a setup-only key and then destroys that key. Before deletion, it pre-signs a small, fixed transaction set, so later spending can only follow those pre-committed ways (covenant-like in effect).

To move funds out, you broadcast a pre-signed trigger (unvault) transaction. The trigger creates an intermediate output where the "normal spend" path is gated by a relative timelock.

If the trigger is unexpected (an attacker got access to your wallet), you (or a delegated person) can broadcast another pre-signed panic (rescue/cancel) transaction that spends the trigger's output immediately to an emergency cold destination, without waiting out the timelock.

In my mind, a true vault does not rely on presigned transactions, but not everyone agrees on the definition.

Whether you are thinking about a vault or just a multisig wallet, it is nonetheless the case that you need to backup more information than just your private key or seed phrase. In the case of a multisig, you need to know how to sign the script that describes your multisig. In the case of something like Rewind, you need to keep a set of presigned transactions (it also needs to keep its descriptors).

So...wouldn't it be cool if you could keep these little bits of extra necessary information somewhere always accessible when you are ready to spend? Somewhere like...in an op_return?

How could saving your wallet backup data onchain actually work?How could saving your wallet backup data onchain actually work?

The goal is that a user can restore a wallet on a fresh device using only the 12-word BIP39 mnemonic, without needing extra digital backups.

Rewind proposes three options:

OP_RETURN + TRUCOP_RETURN + TRUC

TRUC is a newer relay policy (active since Bitcoin Core 28) that lets you submit small 1‑parent‑1‑child packages as a unit, allowing 0‑fee parents when the child pays enough.

This strategy uses a two‑tx package where the vault transaction is the parent and the OP_RETURN backup transaction is the child. It stores the backup payload in a single OP_RETURN transaction and uses TRUC rules to link it to the vault transaction (the one with the to‑be‑deleted setup key). See the flow diagram below.

OP_RETURN + v2 (non-TRUC)OP_RETURN + v2 (non-TRUC)

Same OP_RETURN payload, but using v2 regular transactions. Fee shifting still works, but the vault transaction must pay the static min-relay fee (0.1 sats/vB) and the final backup transaction bumps the effective fee rate via CPFP (Child Pays for Parent).

InscriptionsInscriptions

Inscriptions use a commit+reveal chain with the payload in the reveal transaction witness. Fee shifting uses minimum relay fees on the vault and commit transactions and a higher‑fee reveal transaction for CPFP.

The reveal transaction creates a small OP_RETURN padding output. The padding is just garbage data used to avoid Core's tx-size-small policy (non‑witness size must be >= 65 bytes).

Here's a link to an X thread one of the Rewind developers posted describing this idea:

Backup standards: yes, on-chain? not sure.Backup standards: yes, on-chain? not sure.

As wallet spending policies get more complicated (something I expect to happen as people figure out the best ways to design wallets), we're probably going to have to get used to backing up more than just a seed phrase.

The standardizing process has already begun. Salvatore Ingala proposed a scheme for encrypting this extra backup data with your public key so it could be safely stored in less secure locations (cloud servers and such) and others have been adding to the concept.

I'm not sure what to think about the idea of storing wallet recovery data in Bitcoin transactions. There is a certain elegance to it, but it also seems like it could become a risky move in a high-fee environment.