Recently, community discussions around the BIP-110 proposal have been intensifying. The proposal suggests temporarily limiting the size of certain data fields at the consensus layer to correct incentive distortions caused by standardized support for arbitrary data, and to refocus priorities on enhancing Bitcoin’s function as a currency.
We believe that such discussions themselves exemplify the strength of Bitcoin as a decentralized consensus system. Over the past decade, the Bitcoin network has always allowed coexistence of different ideas and technical approaches. From the SegWit2x controversy in 2017 to the subsequent Bitcoin Cash fork, the system has demonstrated ongoing evolution despite disagreements.
Currently, the proportion of nodes signaling support for BIP-110 is on the rise. According to public data:
January 25, 2026: 2.98% (729 / 24,482 nodes)
February 23, 2026: 7.99% (1,995 / 24,981 nodes)
BIP-110 Ready Nodes
This indicates an increase of about 5% within a month. Whether this proposal can ultimately reach the activation threshold remains uncertain and requires ongoing observation.
Against this backdrop, we believe that products and services within the Bitcoin ecosystem should be prepared at the technical level for multiple possible outcomes, rather than making judgments based on emotional positions or preset results.
Design Purpose and Role of Fractal
One of the core design goals of Fractal Bitcoin is to provide an environment capable of supporting more complex states and data representations without altering the mainnet’s consensus rules.
If in the future the mainnet adopts stricter restrictions on certain data types at the consensus level, Fractal can serve as a technically compatible extension layer, offering an alternative path for asset state continuity.
As we have discussed before:
For Ordinals, censorship on Bitcoin is always a concrete and clear risk. If one day Bitcoin maintainers decide that “Ordinals are spam and should be blocked in future versions,” Fractal Bitcoin can mirror and preserve all inscriptions from the mainnet with minimal additional data overhead, amounting to only about 1/38 of the data size of the mainnet inscriptions.
It is important to emphasize:
Fractal is not a contentious fork
It is not a confrontational response to mainnet decisions
It does not presuppose any specific governance outcome
Its role is more akin to a “buffer extension layer,” providing continuity assurance for assets during different stages of consensus evolution.
Possible Scenarios for “Temporary Restrictions”
BIP-110 is described as a temporary restriction lasting one year.
In such a scenario, if assets on the mainnet are constrained, Fractal can serve as a temporary hosting environment; if the restriction is lifted after a year, assets can return to the mainnet.
The specific technical implementation path still has room for further research and optimization, but the principles are clear:
Do not disrupt mainnet consensus
Do not force migration
Do not create market panic
Only offer an optional solution
Our Position
As ecosystem participants, we respect the final consensus outcome of Bitcoin.
Regardless of the direction of BIP-110, the healthy development of the ecosystem should not be built on opposition, but on technical preparedness and rational discussion.
The existence of Fractal is not to create division, but to provide a technical buffer space when disagreements arise.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Discussion on the BIP-110 proposal and the potential role of Fractal
Recently, community discussions around the BIP-110 proposal have been intensifying. The proposal suggests temporarily limiting the size of certain data fields at the consensus layer to correct incentive distortions caused by standardized support for arbitrary data, and to refocus priorities on enhancing Bitcoin’s function as a currency.
We believe that such discussions themselves exemplify the strength of Bitcoin as a decentralized consensus system. Over the past decade, the Bitcoin network has always allowed coexistence of different ideas and technical approaches. From the SegWit2x controversy in 2017 to the subsequent Bitcoin Cash fork, the system has demonstrated ongoing evolution despite disagreements.
Currently, the proportion of nodes signaling support for BIP-110 is on the rise. According to public data:
January 25, 2026: 2.98% (729 / 24,482 nodes)
February 23, 2026: 7.99% (1,995 / 24,981 nodes)
BIP-110 Ready Nodes
This indicates an increase of about 5% within a month. Whether this proposal can ultimately reach the activation threshold remains uncertain and requires ongoing observation.
Against this backdrop, we believe that products and services within the Bitcoin ecosystem should be prepared at the technical level for multiple possible outcomes, rather than making judgments based on emotional positions or preset results.
Design Purpose and Role of Fractal
One of the core design goals of Fractal Bitcoin is to provide an environment capable of supporting more complex states and data representations without altering the mainnet’s consensus rules.
If in the future the mainnet adopts stricter restrictions on certain data types at the consensus level, Fractal can serve as a technically compatible extension layer, offering an alternative path for asset state continuity.
As we have discussed before:
For Ordinals, censorship on Bitcoin is always a concrete and clear risk. If one day Bitcoin maintainers decide that “Ordinals are spam and should be blocked in future versions,” Fractal Bitcoin can mirror and preserve all inscriptions from the mainnet with minimal additional data overhead, amounting to only about 1/38 of the data size of the mainnet inscriptions.
It is important to emphasize:
Fractal is not a contentious fork
It is not a confrontational response to mainnet decisions
It does not presuppose any specific governance outcome
Its role is more akin to a “buffer extension layer,” providing continuity assurance for assets during different stages of consensus evolution.
Possible Scenarios for “Temporary Restrictions”
BIP-110 is described as a temporary restriction lasting one year.
In such a scenario, if assets on the mainnet are constrained, Fractal can serve as a temporary hosting environment; if the restriction is lifted after a year, assets can return to the mainnet.
The specific technical implementation path still has room for further research and optimization, but the principles are clear:
Do not disrupt mainnet consensus
Do not force migration
Do not create market panic
Only offer an optional solution
Our Position
As ecosystem participants, we respect the final consensus outcome of Bitcoin.
Regardless of the direction of BIP-110, the healthy development of the ecosystem should not be built on opposition, but on technical preparedness and rational discussion.
The existence of Fractal is not to create division, but to provide a technical buffer space when disagreements arise.