BRC-20 Fork War Imminent: How to Quickly Understand Everything Happening?
TechFlow Selected TechFlow Selected
BRC-20 Fork War Imminent: How to Quickly Understand Everything Happening?
We need decentralization, deliberation, slow consensus, and compromise to move the BRC-20 protocol forward.
Navigating Web3 tides with focused insightsAuthor: Bob Bodily
Translation: TechFlow
Recently, BRC-20 creator @domodata took to Twitter to criticize UniSat, accusing it of forking BRC-20 by upgrading the Ordinals protocol used to index BRC-20 tokens to a new version.
Behind the technical changes and version updates appears to be an even deeper struggle over control of the protocol.
Subsequently, this so-called "fork" incident involving UniSat sparked widespread discussion in the community, with mixed market reactions. Bob Bodily, CEO of BioniqMarket, shared his commentary, offering valuable insights into the technical background and full context of the event. Below is the full translation.
First, a quick summary of BRC-20:
To date, BRC-20 is the most successful fungible token protocol on Bitcoin. Last year, its trading volume reached hundreds of millions, possibly even billions of dollars. It’s not perfect (it uses inefficient encoding, increases the burden on the UTXO set, and has limited functionality), but it is extremely easy to deploy and mint tokens, sparking the inscriptions wave across nearly every blockchain in the crypto world.
Next, a quick technical primer:
BRC-20 is a meta-protocol built on top of Bitcoin's Ordinals meta-protocol, which itself is built on Bitcoin. This means Ordinals uses Bitcoin as a complete data availability layer and relies on off-chain indexers to determine the state of the meta-protocol. BRC-20 uses the Ordinals protocol as its full data availability layer and also depends on off-chain indexers to determine its own protocol state. This makes BRC-20 effectively a meta-meta-protocol—a protocol built atop another meta-protocol.
The complexity of building BRC-20 on Ordinals:
Over the past year, the technical specifications of the Ordinals protocol have continuously evolved. Ordinals is a brand-new protocol, so frequent changes are expected. When you build a token standard on top of Ordinals, your protocol inherits additional risk because you're depending on a constantly changing foundation. This is exactly what happened between Ordinals 0.8.0 and 0.9.0. Different versions of Ordinals track inscriptions slightly differently, meaning BRC-20 indexers may report incorrect balances depending on whether they are built on 0.8.0 or 0.9.0. Of course, this is undesirable.
L1F's solution
Layer 1 Foundation @L1Fxyz (editor’s note: the organization is Domo’s foundation, the creator of BRC-20) proposed freezing the Ordinals protocol at version 0.9.0 to prevent similar issues in the future. Thus, even though we might have cursed inscriptions under other categories, by ensuring all indexers are built on version 0.9.0, cross-version incompatibilities can be avoided. This isn’t a permanent fix, but for now, it works very well in maintaining BRC-20 stability.
Unisat wants to push the protocol forward
Unisat wants to advance the protocol. First, Unisat introduced a black/white module system. This allows builders on BRC-20 (like Unisat itself) to introduce new features in the black module—a temporary space not indexed in the main protocol. You can move your tokens into the black module, but cannot withdraw them until approved—essentially functioning like a Bitcoin sidechain (a one-way bridge). Then yesterday, Unisat announced plans to upgrade the version of Ordinals under its BRC-20 indexer to the latest post-Jubilee version. Jubilee is the official release of Ordinals after which cursed inscriptions will no longer exist—all inscriptions will permanently be positive.
The core debate: How should BRC-20 be upgraded?
Upgrading the Ordinals version beneath the BRC-20 indexer is actually a very good idea. The Ordinals protocol would become more stable, we’d eliminate cursed Ordinals, and we wouldn’t have to worry about account mismatches anymore.
It makes sense that Unisat wants to roll this out quickly—after all, Unisat is a startup. Startups don’t have the luxury of waiting around. They must actively search for product-market fit and deliver services to users.
L1F prefers to delay the upgrade because rushing could introduce more bugs. Best in slot and others have already identified some protocol-level flaws. This is understandable—L1F’s role is to safeguard the protocol, so it can afford to take a slower, more deliberate path toward upgrades.
Some see this as a power struggle, with the Unisat team attempting to seize control of the protocol. Others argue that L1F is merely trying to maintain control, while the protocol should instead be driven more by market forces.
My take
Given the incredible success of the BRC-20 protocol, we can no longer afford to move recklessly as we did in the early days. The startup phase of BRC-20 is over—today, BRC-20 is an absolutely massive protocol (in terms of TVL, users, infrastructure, wallets, markets), and nothing can move fast anymore. I appreciate L1F’s approach. Domo has always recognized the importance of protocol stability (BRC-20 hasn't truly changed since its inception), which is an advantage—making integration and development easier. We need decentralization, deliberation, slow consensus, and compromise to move the BRC-20 protocol forward.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@BobBodily
