Bitcoin is designed to make its rules difficult to change. Proposals are discussed publicly, translated into software and ultimately adopted (or rejected) by independent participants across the network. This deliberate process is one of Bitcoin’s defining qualities.
Most protocol debates remain largely technical. Occasionally, however, a proposed change has direct implications for asset holders and the firms safeguarding assets on their behalf. BIP 110, formally titled the Reduced Data Temporary Softfork, is one such proposal. It seeks to impose temporary consensus-level restrictions on certain data fields in Bitcoin transactions, with the stated aim of prioritizing Bitcoin’s monetary use.
The relevant question in the case of BIP 110 is simple: could incompatible validity rules sustain two separate histories for long enough to create distinct assets and corresponding operational responsibilities?
For an institutional custodian, answering that question requires more than following the public debate. It requires a precise understanding of when the rules may diverge, how transactions could behave across the resulting chains and what measures are necessary to preserve potential client entitlements.
What BIP 110 proposes and why policy is not consensus
Bitcoin transactions consume previously created, unspent transaction outputs and create new ones. These outputs are primarily used to transfer value, but the Bitcoin blockchain has also long been used to anchor or encode other forms of data.
One mechanism associated with this use is OP_RETURN. It allows a transaction output to be marked as provably unspendable while carrying a limited amount of data. Because nodes can recognize that such an output can never be spent, they do not need to retain it as part of the active set of unspent outputs.
To understand BIP 110, it is important to distinguish between two types of rules applied by Bitcoin nodes.
Consensus rules determine whether a transaction or block is valid. A block that violates the consensus rules recognized by a node is rejected, irrespective of how much proof of work contributed to it. A block is invalid if any of the included transactions are invalid or if the block itself is malformed, e.g., by being too large.
Relay policy, by contrast, influences which unconfirmed transactions a node will forward to its peers. A transaction that falls outside a node’s relay policy is not necessarily invalid. It may still reach a miner through another route (e.g., some miners offer APIs to submit to them directly), be included in a block and subsequently be accepted by that same node if it complies with consensus rules.
This distinction matters because policy can discourage particular transaction formats without prohibiting them. BIP 110 would go further by introducing temporary consensus restrictions on the size and structure of several transaction data fields. Among other provisions, its current specification limits most new output scripts to 34 bytes, permits up to 83 bytes where the first opcode is OP_RETURN, and places additional restrictions on witness, Taproot and data-push structures. The proposed restrictions would apply for approximately one year, with existing outputs created before activation generally grandfathered.
Supporters view these restrictions as a way to constrain non-monetary data use. Critics question whether such restrictions can achieve that objective, given that data may be encoded in multiple ways, and highlight the consequences of changing consensus rules without broad adoption.
For custody purposes, it is not necessary to resolve that debate. The more immediate issue is how the change would be introduced. While BIP 110 is usually described as a soft fork, its activation path is more accurately understood as two successive soft forks.
Two soft forks and the chain split between them
A soft fork tightens consensus rules: it makes some blocks that were previously valid invalid under the new rules. BIP 110 is generally discussed as one such change, with attention focused on when its proposed restrictions on transaction data become active. For custodians, however, that framing misses the more immediate, first event.
BIP 110’s activation mechanism for enforcing the new limitations does not realistically risk a chain-split. The mandatory signaling that predates it does.
The first soft fork: mandatory signaling
BIP 110 uses miner signaling over periods of 2016 blocks. Under Bitcoin’s existing rules, blocks may be produced with or without the relevant activation signal. If the proposal does not reach its threshold through voluntary signaling, nodes enforcing BIP 110 are programmed to enter a mandatory-signaling period at block height 961,632, currently estimated for approximately 8 August 2026.
From that block height, these nodes will reject blocks that do not carry the required signal. The validity rule changes from “signaling and non-signaling blocks are valid” to “only signaling blocks are valid.” This is itself a soft fork because it narrows the set of blocks accepted by participating nodes.
Nodes continuing to follow the existing rules will still accept both types of blocks. With current miner signaling far below the proposal’s 55% threshold, non-signaling blocks are highly likely to continue being produced. The first such block after enforcement begins will be accepted by existing-rule nodes but rejected by BIP 110 nodes. Conversely, BIP 110 miners may continue extending a signaling-only branch. That is the point at which the network histories can separate.
The second soft fork: the substantive restrictions
On the BIP 110 branch, every accepted block during mandatory signaling necessarily carries the required signal. Nodes on that branch will therefore observe sufficient signaling for the proposal to lock in. Following the specified block-based waiting period, the restrictions on transaction data and script structures would become enforceable.
This is the second soft fork: the BIP 110 branch tightens its validity rules again by applying the proposal’s substantive restrictions.
Much public attention has focused on 01 September 2026, or a nearby date, as the “expected” moment of BIP 110 activation. That estimate may shift because activation is determined by blocks produced rather than by the calendar. A branch with a little hash rate could take substantially longer than expected to complete the required periods. Current (pre-enforcement) BIP110 signaling hovers in the low single digit percentage region.
For custodians, however, the larger issue is not whether substantive activation occurs precisely on 1 September or significantly later. By then, the operationally relevant event may already have happened.
The preparation deadline is the beginning of mandatory signaling at block 961,632, currently expected around 8 August. That is when different rule sets may first recognize different chain histories, corresponding asset positions may arise, and transaction controls may need to account for replay across both branches. Custodians therefore need to prepare for the split height, not the more widely discussed date on which BIP 110’s substantive restrictions may eventually activate.
From protocol divergence to custody responsibility
Before a chain split, a set of private keys controls particular Bitcoin outputs. If two branches preserve the same history up to the split, those keys initially control corresponding outputs on both branches.
In practical terms, what was previously one asset position may become two technically distinct positions. Whether the additional position will attract market value, receive infrastructure support or remain viable may initially be unknown. Nevertheless, control of that position may need to be preserved while its status is assessed.
The immediate operational concern is transaction replay.
A transaction signed to spend Bitcoin on one branch may also be valid on the other. Because signed Bitcoin transactions are public once broadcast, another participant can copy a transaction from one network and submit it to the second. If that network applies compatible transaction rules, it may accept the transaction there as well.
A custodian could therefore intend to process a withdrawal on its supported Bitcoin chain while unintentionally transferring the corresponding asset on the other branch. The recipient does not need to compromise the custodian’s systems or obtain its private keys: replaying the already signed transaction may be sufficient to extract value. Historical chain splits have established replay as a genuine operational consideration rather than merely a theoretical possibility.
This creates an important distinction between supporting an asset and preserving it. A custodian may decide not to list, settle or distribute an asset created through a chain split. That product decision does not prevent replay, nor does it necessarily eliminate the possibility that the asset represents a client entitlement.
Custodians generally do not have an obligation to enable access to splits of miniscule value. That would create an undue asymmetry, as the effort to create a fork can be of the order of minutes. The fiduciary duty though requires careful analysis which splits have the potential to carry value and for those preserve the optionality to add support then. For a split as the heavily discussed as BIP 110, the low miner signaling is not a sufficient argument to dismiss it. The mining commercials enter a different game after the availability of two separate coins following the chain split and while two sustained sides are certainly not the base-case, it’s also not as low as the current miner support would suggest.
Preparation therefore begins before the split. It includes identifying the earliest block height at which validity rules may diverge, monitoring the relevant software implementations and both potential chain states, and establishing escalation criteria and transaction controls in advance. It may also require temporary restrictions on routine processing, an assessment of whether replay protection exists, controlled methods for separating assets where appropriate, and an auditable reconciliation of positions across both branches.
The service model matters as well. In a full-custody relationship, the custodian controls the operational environment and can implement protective measures directly. Where a provider supplies infrastructure but the client retains operational control of the keys, the provider can offer analysis, tooling and guidance, but key-dependent actions ultimately remain with the asset owner.
Custody beyond key security
BIP 110 illustrates why institutional crypto custody extends beyond generating and storing private keys securely. Custodians must also understand how proposed consensus changes operate, when different views of blockchain history may emerge and how routine transactions could affect assets across more than one network.
Recognizing BIP 110 as two consecutive soft forks is central to identifying the relevant preparation window. The first tightening may separate the chain histories; the second would activate the substantive restrictions on one of those histories.
The eventual economic relevance of any additional branch may be uncertain. Operational readiness cannot wait for that uncertainty to be resolved. Effective custody combines key security with protocol expertise, transaction discipline, asset reconciliation and measured action to preserve clients’ positions as the network evolves.