Popular science from @BobBodily, as always quoted in full without modification.
First, a brief summary of BRC-20:
BRC-20 is by far the most successful fungible token protocol on Bitcoin. Transaction volume last year was in the hundreds of millions, if not billions. It's not perfect (uses inefficient encoding, bloats the UTXO set, and currently has limited functionality), but it's incredibly easy to deploy and mint tokens, and has inspired inscriptions across the crypto world on nearly every chain.
Next up is a quick technical primer:
BRC-20 is a meta-protocol built on the Ordinals meta-protocol, which in turn is built on Bitcoin. This means Ordinals uses Bitcoin as a full data availability layer and an off-chain indexer to determine the meta-protocol state. BRC-20 uses the Ordinals protocol as a complete data availability layer with an off-chain indexer to determine meta-protocol status. This means that BRC-20 is actually a meta-meta protocol since it is built on top of Ordinals.
Complexity of building BRC-20 on Ord:
The Ordinals protocol technical specifications have been changing over the last year. Ord is a completely new protocol, so it has changed a lot. When you build a token standard on top of Ord, your protocol adds additional risk because you have a transfer protocol as a dependency. This is what happened with Ord 0.8.0 and Ord 0.9.0. Different versions of Ord track inscriptions slightly differently, meaning the BRC-20 indexer will report incorrect balances depending on whether they are built on 0.8.0 and 0.9.0. Of course, this is not desired.
L1F solution
Layer 1 Foundation @L1Fxyz's solution is to freeze the Ord protocol version to 0.9.0 to prevent similar issues from occurring in the future. So even though we have other classes of Cursed Glyphs, you avoid any cross-version incompatibilities by building all indexers on version 0.9.0. This is not a permanent solution, but for now it works very well in keeping the BRC-20 stable.
Unisat hopes to push the agreement forward
Unisat first introduced the black and white module system. This enables people building on BRC-20 (like Unisat) to introduce new features in black modules (temporary locations not indexed in the main protocol). You can put tokens into black modules, but you can't take them out until they are approved, essentially like Bitcoin Spacechain (one-way bridge). Then yesterday, Unisat announced that they want to upgrade the version of Ord under the BRC-20 indexer to the latest version after Jubilee. Jubilee is the official version of Ord and we will no longer curse Ordinals (all inscriptions will always have positive numbers).
The bone of contention: How to upgrade the BRC-20
Upgrading the Ord version under the BRC-20 indexer is actually a very good idea. The Ord protocol will be more stable, we won't curse Ordinals anymore, we won't have to worry about balance mismatches, etc.
Unisat wants to launch this service as soon as possible, which makes sense since Unisat is a startup. Startups don’t have time to sit around and wait. You have to work hard to find product market fit and build it for your users.
L1F wants to delay the upgrade because if we rush the upgrade, we might get more bugs. Best in slot and others have discovered some of these protocol bugs. This makes sense since L1F is designed to protect the foundation of the protocol, so they can accept upgrades from slower moving, more purposeful protocol paths.
Some believe this is a power play by the Unisat team to try to control the protocol. Others believe that L1F is simply trying to control the protocol, which should be more market-driven.
Bob's view
Because of the incredible success of the BRC-20 agreement, we cannot move any faster. The launch days of BRC-20 are over. BRC-20 is an absolutely massive protocol (TVL, users, infrastructure, wallets, market) and nothing should be done quickly anymore. I like the approach from L1F. Domo has always recognized the importance of protocol stability (BRC-20 hasn't really changed since its inception), which is a strength. Easier to integrate. Easier to build on.etc. We need decentralization, thoughtfulness, and a slow process of consensus and compromise to drive changes to the BRC-20 protocol forward.
