Sequence Number (nSequence)

The sequence number (nSequence) is a 32-bit field present on every input of a Bitcoin transaction. Originally imagined by Satoshi as a way to "replace" transactions before confirmation — a mechanism that never worked as intended, since nothing forced miners to honour the newest version — it was repurposed over time into a compact control field that now governs relative timelocks, replace-by-fee signalling, and whether transaction-level locktime is enforced. Four bytes, three jobs, and a lot of history.

The three jobs it does

First, when an input's sequence is set to the maximum value 0xFFFFFFFF, it disables both relative timelocks and locktime for that input — a transaction where every input is maxed is final immediately. Second, under BIP68 (active for version-2 transactions), a non-maximum sequence encodes a relative timelock: an input cannot be spent until a certain number of blocks, or a certain number of 512-second intervals, has elapsed since the output it spends was confirmed. A type flag inside the field selects blocks versus time, and the low bits carry the count. Third, a sequence value below 0xFFFFFFFE signals that the transaction opts in to replace-by-fee under BIP125, telling the network the sender may broadcast a higher-fee replacement.

Relative versus absolute time

It is worth separating sequence-based relative timelocks from locktime's absolute ones. Locktime says "not before this block height or timestamp"; nSequence says "not until this much time has passed since the coin being spent was created." Relative locks are the more composable primitive for protocols, because they start their clock from an event (confirmation of the previous output) rather than a calendar date fixed at signing time. The script opcode OP_CHECKSEQUENCEVERIFY (BIP112) lets a script enforce that the spending input carries at least a given relative lock — without it, nSequence would be a promise the spender makes to themselves rather than a rule the coin imposes.

Why protocol designers lean on it

Relative timelocks are the backbone of the Lightning Network's security model: when a channel closes, the closing party's funds are delayed by a CSV window, buying the counterparty time to publish a penalty transaction if an old state was cheated onto the chain. The same delay-then-claim pattern appears in HTLC scripts, vault designs, and newer off-chain constructions. For everyday wallet users the field is mostly invisible plumbing — your wallet picks values that enable RBF or finality as appropriate — but for anyone building on Bitcoin's UTXO model, the practical takeaway is that the field is deliberately overloaded: the same four bytes can simultaneously toggle RBF, set a maturity delay, and decide whether your locktime even applies. Wallets and protocol implementers pick the value carefully to get exactly the combination they want, because an accidental 0xFFFFFFFF silently switches off protections a script may be counting on.

Reading the field in the wild

Block explorers and wallet debug views expose nSequence per input, and learning to read it pays off during fee troubleshooting. A stuck transaction whose inputs all carry 0xFFFFFFFF did not signal BIP125 replaceability, which historically constrained how it could be bumped — though modern mempool policies and techniques like child-pays-for-parent soften that edge. A value like 0xFFFFFFFD is the everyday "RBF-enabled, no relative lock" setting most wallets now emit by default. And if you ever see small values such as 0x00000090 on a channel-close transaction, you are looking at a CSV delay counted in blocks — the Lightning security window, written in four bytes. The field rewards a moment's literacy: it is one of the few places where Bitcoin's protocol history, fee mechanics, and layer-two security are all visible in a single hex value.