Transaction Input Sequence Number

What Is the Transaction Input Sequence Number?

The transaction input sequence number (often called nSequence) is a 32-bit unsigned integer attached to every input in a Bitcoin transaction. Each input references a previous unspent output and includes this sequence field alongside the outpoint reference and the unlocking script.

Despite its simple structure, the sequence number is one of the most overloaded fields in the Bitcoin protocol. A single 4-byte value now controls three independent behaviors: whether the transaction signals replaceability to miners, whether a relative timelock constrains when the input can be spent, and whether the transaction-level nLockTime field is enforced. Understanding how these three roles interact is essential for anyone building Bitcoin wallets or constructing raw transactions.

How It Works

The sequence number occupies 4 bytes within each serialized transaction input, immediately after the outpoint (the 32-byte txid plus 4-byte output index) and the scriptSig. Its value is interpreted differently depending on context and transaction version.

Sentinel Values

Two specific values have special meaning:

• 0xFFFFFFFF (4,294,967,295): the maximum value. This disables nLockTime enforcement for the transaction (all inputs must use this value for nLockTime to be ignored), disables BIP 125 RBF signaling, and disables BIP 68 relative timelocks.
• 0xFFFFFFFE (4,294,967,294): enables nLockTime enforcement but does not signal RBF. Because bit 31 is set, BIP 68 relative timelocks are also disabled for this input. This is the value wallets use when they need nLockTime (for anti-fee-sniping) but do not want to signal replaceability.

RBF Signaling (BIP 125)

BIP 125 defines opt-in replace-by-fee signaling through the sequence number. Any input with a sequence value below 0xFFFFFFFE (that is, 0x00000000 through 0xFFFFFFFD) signals that the transaction may be replaced by a higher-fee version while it remains unconfirmed. If even one input in a transaction carries a signaling sequence number, the entire transaction is considered replaceable.

As of Bitcoin Core 29.0 (April 2025), full RBF is mandatory: all unconfirmed transactions can be replaced regardless of their sequence values, and the -mempoolfullrbf option has been removed entirely. The opt-in signal still matters for BIP 68 interpretation but no longer gates replacement at the policy level. For more on how fee dynamics interact with replacement, see the Bitcoin fee market dynamics research article.

Relative Timelocks (BIP 68)

BIP 68 repurposes the sequence number to encode relative timelocks: minimum delays between when an output is confirmed and when it can be spent. These rules apply only to transactions with version 2 or higher. The 32 bits are interpreted as follows:

• Bit 31 (0x80000000): the disable flag. If set, no relative lock-time is enforced for this input and the remaining bits are ignored by BIP 68.
• Bit 22 (0x00400000): the type flag. If unset, the lock is measured in blocks. If set, the lock is measured in units of 512 seconds.
• Bits 0 through 15 (masked by 0x0000FFFF): the lock value, representing either a block count or a number of 512-second intervals depending on the type flag.
• Bits 16 through 21 and bits 23 through 30: reserved for future use and should be kept at zero.

Sequence number bit layout (BIP 68):

  31   30 ... 23   22   21 ... 16   15 ... 0
┌────┬───────────┬────┬───────────┬──────────┐
│ D  │ reserved  │ T  │ reserved  │  value   │
└────┴───────────┴────┴───────────┴──────────┘

D = disable flag (1 = no relative lock)
T = type flag (0 = blocks, 1 = 512-second units)
value = lock magnitude (0 to 65,535)

The 512-second granularity for time-based locks was chosen because Bitcoin blocks are produced roughly every 600 seconds, making 512 seconds (2^9) a convenient power-of-two approximation. The maximum relative time lock is 65,535 × 512 seconds, or approximately 388 days.

For block-based locks, the maximum is 65,535 blocks, or roughly 455 days at 10-minute block intervals.

nLockTime Interaction

The sequence number also controls the transaction-level nLockTime field. nLockTime specifies an absolute block height or Unix timestamp before which the transaction cannot be included in a block. However, nLockTime is only enforced when at least one input has a sequence number below 0xFFFFFFFF. If every input uses the maximum sequence value, nLockTime is ignored entirely.

This creates an important interaction: OP_CHECKLOCKTIMEVERIFY (CLTV) requires nLockTime to be active, which means the spending input must not use 0xFFFFFFFF as its sequence number. Wallets constructing CLTV-locked transactions typically use 0xFFFFFFFE to enable nLockTime while avoiding RBF signaling.

Practical Examples

Setting a 144-Block Relative Timelock

To require that an output be at least 144 blocks old (roughly one day) before it can be spent:

# Disable flag off, type flag off (blocks), value = 144
# Binary: 0|000000000|0|000000|0000000010010000
# Hex: 0x00000090

nSequence = 0x00000090  # 144 blocks relative lock

Setting a 24-Hour Time-Based Lock

To require roughly 24 hours to pass (measured in 512-second intervals):

# 24 hours = 86,400 seconds
# 86,400 / 512 = 168.75, round up to 169
# Type flag set (bit 22), value = 169
# Hex: 0x004000A9

nSequence = 0x004000A9  # ~24 hours (169 × 512 = 86,528 seconds)

Signaling RBF Without a Relative Timelock

To signal opt-in RBF while disabling the relative timelock:

# Disable flag on (bit 31), value below 0xFFFFFFFE
# Common default used by Bitcoin Core and other wallets:
nSequence = 0xFFFFFFFD

# Bit 31 is set -> BIP 68 ignores this input (no relative lock)
# Value < 0xFFFFFFFE -> BIP 125 RBF is signaled
# Value < 0xFFFFFFFF -> nLockTime remains active

Use Cases

Replace-by-Fee for Fee Bumping

The most common use of sequence numbers today is RBF signaling for fee bumping. When network congestion drives up fees, users can broadcast a replacement transaction with a higher fee rate. Wallets like Bitcoin Core default to a sequence number of 0xFFFFFFFD, which enables RBF signaling and keeps nLockTime active for anti-fee-sniping protection.

Payment Channel Protocols

Relative timelocks encoded in sequence numbers are critical to payment channel protocols. Lightning Network commitment transactions use OP_CHECKSEQUENCEVERIFY (CSV) to enforce delay periods during channel closures. For example, a revocable output might require the broadcaster to wait 144 blocks before claiming their funds, giving the counterparty time to broadcast a justice transaction if the commitment was revoked.

Vaults and Custody Contracts

Bitcoin vault designs use CSV-enforced relative timelocks to create withdrawal delays. When a user initiates a withdrawal, the sequence number enforces a waiting period during which the transaction can be clawed back if unauthorized. The OP_VAULT proposal builds on this pattern to provide pre-signed recovery paths.

Atomic Swaps and HTLCs

Hash time-locked contracts (HTLCs) combine hash locks with timelocks. Relative timelocks via the sequence number allow refund paths to activate after a specific number of blocks, independent of any absolute timestamp. This is particularly useful in cross-chain atomic swaps where the refund window needs to be relative to the funding transaction's confirmation.

Why It Matters

The sequence number is a foundational building block for Bitcoin's programmable spending conditions. Without it, there would be no relative timelocks, no CSV-enforced channel penalties, and no standardized way to signal transaction replaceability. Every Layer 2 protocol that relies on time-delayed revocation (including the Lightning Network and newer designs like Ark) depends on correct sequence number handling.

For Layer 2 solutions built on Bitcoin, the sequence field is infrastructure. Spark, for example, inherits Bitcoin's UTXO model and leverages its scripting capabilities. As Bitcoin's scripting evolves with proposals like OP_CTV and SIGHASH_ANYPREVOUT, the sequence number will continue to play a central role in how spending conditions are constructed and enforced.

Risks and Considerations

Conflicting Interpretations

The sequence number's triple role creates subtle pitfalls. A developer who sets a low sequence number for RBF signaling may inadvertently impose a relative timelock if the transaction version is 2 or higher. Conversely, setting the disable flag (bit 31) to avoid BIP 68 interpretation still signals RBF as long as the value is below 0xFFFFFFFE.

Wallet Implementation Errors

Incorrect sequence values can cause transactions to be invalid at the consensus level (violating BIP 68 relative timelocks) or rejected by mempool policy (failing CSV script checks). Wallets constructing transactions with version 2 must account for BIP 68 interpretation of every input's sequence number. Using version 1 avoids relative timelock enforcement but also prevents access to BIP 68 features.

Full RBF Policy Changes

With Bitcoin Core 29.0 making full RBF mandatory, the opt-in signaling aspect of the sequence number is less meaningful at the policy level. Merchants and payment processors can no longer rely on the absence of RBF signaling as an indicator that a transaction will not be replaced. However, BIP 68 relative timelocks remain consensus-enforced: the sequence value still has binding consequences for spending conditions.

Reserved Bits and Future Soft Forks

BIP 68 leaves bits 16 through 21 and bits 23 through 30 undefined. Setting these bits to non-zero values is currently permitted at the consensus level, but future soft forks could assign meaning to them. Wallet developers should keep reserved bits at zero when constructing BIP 68 relative timelocks to avoid forward-compatibility issues.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.