A wallet labels a Bitcoin payment “RBF off.” The recipient reads that as a promise that the unconfirmed transaction cannot be replaced. A single label does not support that conclusion. First establish which property the wallet is displaying: an explicit BIP125 signal, the availability of a wallet action, or a node’s evaluation.
One nSequence field has several roles
Each input carries its own nSequence value; there is not just one value for the entire transaction. The field has historically been used for explicit opt-in replacement signaling, participates in relative lock-time conditions, and affects the separate nLockTime field. These rules share numbers but answer different questions.
- Explicit BIP125 signaling
- One input with nSequence below 0xfffffffe is enough. This is a property of the supplied fields, not the outcome of all replacement checks.
- BIP68 relative lock-time
- For the positive transaction versions considered here, it applies from version 2 when the input’s disable flag, bit 31, is unset. A separate mask extracts the value.
- Effect on nLockTime
- If every input uses the FINAL constant, 0xffffffff, nLockTime is bypassed. A different input removes that particular bypass; this does not establish that the lock-time condition has been satisfied.
Four easily confused values
| nSequence | Explicit BIP125 | BIP68 relative lock-time | Equals the FINAL constant |
|---|---|---|---|
| 0xffffffff | No | Disabled by bit 31 | Yes |
| 0xfffffffe | No | Disabled by bit 31 | No |
| 0xfffffffd | Yes | Disabled by bit 31 | No |
| 0x00400002 | Yes | Two units of 512 seconds: 1,024 seconds | No |
FINAL is the name of a constant. It does not mean block confirmation, payment irreversibility, or a service’s final decision. If one input is 0xffffffff and another is 0xfffffffe, the all-input bypass of nLockTime does not apply. The second value still does not provide an explicit BIP125 signal.
Why “no signal” does not mean “replacement prohibited”
BIP125 describes an opt-in policy with explicit and inherited signaling. However, particular implementations have changed their rules. In the inspected Bitcoin Core 31 policy documentation, signaling is not a replacement requirement; other conditions include fees and improvement of the feerate diagram. An older opt-in indicator therefore cannot serve as a universal guarantee about network behavior.
This does not mean that every proposed replacement will be accepted. Nodes check other conditions, and wallets may impose their own interface or transaction-construction constraints. The article’s tool does not model replacement, select a fee, or inspect unconfirmed ancestors. Inherited BIP125 signaling likewise cannot be established from one transaction’s nSequence list alone.
Decoding the relative value
When the BIP68 model applies, the lowest sixteen bits encode a number of units. Bit 22 selects the unit: when set, each unit is 512 seconds; otherwise the value is in blocks. Thus 0x00400002 encodes 2 × 512 = 1,024 seconds, whereas the ordinary value 2 means two blocks under the same applicability conditions.
This is not a countdown from the time the wallet broadcasts. Checking a relative lock requires information about the spent outputs and the relevant block history, including median-time-past for the time-based case. The form does not obtain that information and therefore does not predict an unlocking date. A zero low-bit value can represent an applicable rule with zero duration.
The version and disable flag affect interpretation
Change the version from 2 to 1: BIP68 decoding no longer applies, even though the numeric bits remain unchanged. Set the input’s disable flag, bit 31: the low-bit value must again not be interpreted as a relative delay. Other bits are shown for reference and are excluded from BIP68’s sixteen-bit magnitude.
Test the nLockTime bypass separately
Keep the illustrative nLockTime at 900000 and enter only I1;0xffffffff. The form reports the all-input bypass. Replace the sequence with 0xfffffffe: the bypass disappears, explicit BIP125 remains absent, and BIP68 remains disabled. These are three distinct results. With nLockTime = 0, this check has no absolute lock-time requested.
What to enter and how to use the result
Supply a positive transaction version, nLockTime, and an “input label;sequence” list. I1–I4 are invented labels, not transaction hashes. Decimal uint32 values and hexadecimal values prefixed with 0x are accepted. The limit is one hundred ordinary inputs; coinbase is excluded. Versions are limited to 1 through 2,147,483,647 without checking whether node policy accepts a particular version.
Do not enter seed phrases, private keys, or signatures. The form neither constructs nor broadcasts anything. It reports an explicit signal, relative-lock fields, and the nLockTime bypass; it does not execute scripts or check output ages, the current block, the mempool, signatures, or replacement eligibility.
A downloaded result can help you ask wallet support a precise question: what does its label mean, and why is a particular action available or unavailable? Confirmation waiting and swap conditions remain separate checks. For the overall order process, use KOT.CASH’s exchange explanation rather than drawing a payment conclusion from a few numeric fields.
Inspect ordinary input nSequence values
Educational inspection of ordinary non-coinbase inputs: FINAL, explicit BIP125 and BIP68. No nLockTime satisfaction test, script execution or block history. No inherited signaling, fees, mempool, confirmations, signing or broadcasting. Absence of a signal does not prohibit replacement under node policy. The calculation runs on your device; nothing you enter is sent anywhere.