Replay and wallet safety

This is safety information, not advice. It is not financial, custody, tax, or investment advice, it does not recommend any wallet, exchange, service, or course of action, and it takes no position on whether to hold, split, or transact any coins. If you need advice for your own situation, consult a qualified professional. The site's job is to describe the mechanics so you are not surprised by them.

There is no native replay protection

BIP-110 introduces none of the mechanisms that normally separate two transaction domains. Specifically, it adds:

• no fork identifier in the signature hash
• no chain ID
• no new transaction serialization or marker
• no new address or Bech32 human-readable prefix
• no new P2P magic or default port
• no rule that makes an otherwise ordinary BIP-valid payment invalid on the permissive branch

The existing signature messages (BIP 143 for SegWit v0, BIP 341 for Taproot) commit to the transaction and its prevout data, not to which post-split ancestry the signer intended. So an identical transaction that is valid on both branches has the same signatures, the same txid, and the same wtxid on both. Anyone who obtains that transaction can rebroadcast it to the other branch. Peer-to-peer isolation, a wallet label, a fresh receiving address, or an exchange ticker is not cryptographic replay protection.

Figure slot safety-basics replay overview figure pending

Why a shared coin is spendable on both sides

The same pre-split spending authorization, whether a private key, a multisignature policy, or another script condition, applies to the corresponding UTXO on both ledgers. A split does not create extra keys or alter the original outpoint. It creates two branch histories in which that same outpoint can be spent independently.

If an ordinary payment spends a shared outpoint:

1. It can enter mempools on both sides if it satisfies both policies.
2. It can confirm on either or both branches.
3. If it confirms on both, the recipient controls the resulting output on both.
4. If it confirms on only one, it may still be replayed later, unless a conflicting spend becomes confirmed on the other.

Different receiving addresses do not change this, because the signed transaction itself authorizes the shared input and can be copied unchanged. Adding an OP_RETURN output that names one branch does not establish a replay domain either: if the whole transaction stays valid under both rule sets, the label and the transaction replay together.

Grandfathering does not separate coins

It is tempting to think the per-input grandfathering rule (see What the seven rules restrict) could be used to pin a coin to one branch. It cannot, in the direction people expect.

• A pre-activation UTXO cannot be made BIP-only or permissive-only merely by spending it with a witness construction that rules 2 through 7 forbid. Its input is grandfathered, so the construction is simply exempt on both sides.
• Because BIP-110 is restrictive, a BIP-valid transaction is normally also valid under the permissive rules. The new rules do not provide a symmetric "BIP-only" transaction form.

What the rules can provide, after activation, is a permissive-only form: a transaction spending a shared grandfathered UTXO and creating a non-OP_RETURN output larger than 34 bytes is valid under permissive rules and invalid in an active BIP block (output rule 1 does not grandfather). If a permissive miner confirms that transaction, the original shared outpoint stays unspent on the BIP branch, where a conflicting BIP-compliant spend can then confirm. The descendants of the two confirmed outputs are branch-specific. This is an analytical construction, not a standardized or automatically safe procedure. The permissive-only transaction may be nonstandard under relay policy and may need direct miner coordination, and a reorganization can undo the apparent separation.

Reliable separation needs branch-specific state

The strongest general primitive is an input that exists on only one branch. A transaction that consumes a branch-specific input is invalid on the other branch, because that input is missing there. Examples of branch-specific inputs:

• a matured coinbase output from a block that exists only on one branch
• an output descended from a transaction already confirmed on only one branch
• an outpoint whose conflicting spend is already confirmed on the other branch

Combining such an input with shared inputs can carry the separation forward. During the mandatory-signalling split but before activation, the body rules are still identical on both sides, so an RDTS-violating transaction is not yet a branch discriminator; separation at that stage needs a branch-specific coinbase, another chain-only input, or deliberately confirmed conflicting spends.

Figure slot safety-basics branch-specific input figure pending

Containment basics, if a persistent split occurs

The following are the operational safeguards the technical walkthrough describes. They are containment measures, not replay protection, and none of them is a recommendation to take any action. They are listed so you understand what careful separation involves and why it is harder than it looks.

• Use separate data directories, wallet instances, RPC endpoints, and broadcast paths for the two histories. Do not run the same wallet database concurrently against both nodes.
• Use explicit coin control, and assume every unsplit input is replayable.
• Record the block hash and ruleset for each confirmation. Height and txid alone can be ambiguous across two histories.
• Treat replace-by-fee, child-pays-for-parent, conflict state, and fee estimation as branch-local. Mempools and fee markets diverge.
• Remember that a reorganization can reinsert a disconnected transaction into a mempool and rebroadcast it. A transaction thought to be confined to one branch can reappear automatically.
• Wait for work-based finality appropriate to the branch. A fixed confirmation count is misleading when block intervals and hash rates differ sharply between branches. Six confirmations on a slow minority branch can represent far less accumulated work than six pre-split confirmations.
• Keep backups made before any manipulation of split coins.

Timelocks (nLockTime, CSV) can temporarily make a transaction non-final on a slower branch, but the other branch may eventually reach the required height or median time. These are coordination aids, not durable replay protection.

Light clients, servers, and Lightning

A few cases behave in ways worth knowing about:

• SPV and compact-filter clients validate proof-of-work headers but do not validate every transaction against RDTS. Such a client normally follows the most-work header chain even if BIP full nodes reject a block body. An old light client has no rule telling it to reject a non-signalling mandatory-window header.
• Server-backed wallets inherit the chain their Electrum server, API provider, or full-node backend selected. Switching servers can rewrite the wallet's apparent history. Each backend must be evaluated separately.
• Lightning gets no BIP-110-specific replay protection. A pre-activation funding UTXO is grandfathered for the new input rules, but a force-close transaction spending it can still be replayed if it is otherwise valid on both histories. Divergent height and median-time-past also change when CSV and CLTV paths become spendable in wall time. Grandfathering alone does not resolve replay, liquidity, or timelock hazards.

What to watch

On the Live dashboard, replay exposure is not a single panel, it is a way of reading several:

• Chain tips: whether two histories actually exist yet. Replay risk is only live once a split is.
• Mempool divergence: whether a given transaction is present on one side, the other, or both. Absence is not rejection, and presence on both is exactly the replay case.
• Split telemetry: if a split materialises, the confirmed-and-conflicting state that determines whether a coin is separated. The same txid can have different confirmation and conflict states on the two histories.

For an important coin, the walkthrough suggests maintaining a two-branch ledger per outpoint: does it exist and is it unspent on each branch, is there a spending txid in each mempool, what block hash and height confirmed it on each side, is there a conflicting spend, and do descendants rely on a split input. Different wallet balances alone do not prove safe separation.

Sources

This page restates the BIP-110 technical walkthrough sections Replay protection and transacting on separate chains (no native replay protection, what happens to coins at a split, branch-specific separation, the one-way RDTS discriminator, operational wallet rules, wallet backends and SPV, Lightning considerations) and the mempool and replay-exposure part of What to monitor in each phase. It presents mechanics as safety information only. It contains no financial, custody, or investment advice and recommends no product.