[brc-20] The Freeze

Proposal: Freeze ord version in brc-20 specs to 0.9


Last Friday, a bug was detected in older versions of Ord. While a detailed technical discussion is available here: Ord 0.9.x inscription numbers different than 0.7.x and 0.8.x · Issue #2569 · ordinals/ord · GitHub, in essence, the bug was resolved in the latest release, version 0.9. However, this fix introduced discrepancies in the definition of valid inscriptions across different versions, a complication mirrored in brc-20, resulting in version-based state inconsistencies.

To illustrate, consider the following: A bug in version 0.8 prevented indexers from recognizing and crediting the 1111 minter (35362715). This allowed the next mint of 111 (35362751) to occur. In contrast, Unisat (below) used version 0.9 and adhered to the proper indexing logic, causing the 111 mint to be unsuccessful since the maximum supply was already reached.

Fortunately, most brc-20 indexers were already aligned with version 0.9 (or pre-0.6). Recognizing the bug’s localization to version 0.6-0.8, a consensus quickly emerged among indexers: version 0.9 should be the reference standard. We emphasize that indexers operating with 0.8 were not at fault, and commend marketplaces such as Magic Eden and OKX for either pausing operations or transitioning to 0.9. We would also like to thank users for being patient during this process.

Ord’s team first proposed retroactively “cursing” the problematic inscriptions in 0.9. While they have the liberty to direct their protocol, this action would have mirrored the effect of the “great renumbering”. Simply put, brc-20’s definition of a valid inscription cannot be mutable retroactively and this fix would have led to a definition dislocation of brc-20 and ord (0.9 vs. 0.9.x). In the face of this, the ultimate decision was to uphold 0.9 as the definitive version. We appreciate the Ord team’s swift response, especially during what appeared to be a travel-intensive weekend.

So, what’s our take-away? Surprisingly, we’re now in a more advantageous position than before the bug’s discovery, with widespread adoption of 0.9. This positions Ord for a seamless transition to “The Jubilee”. As for brc-20, it underscores the urgency to standardize on a fixed Ord version. The events of this weekend have heightened this urgency. Given the consolidated version landscape, the timing is ideal. Solidifying this choice will ward off future issues stemming from undiscovered version mismatches or new inscription type anomalies. Once Ord’s evolutionary phase stabilizes, brc-20 may look to re-establish parity and embrace newer inscription methods.


In Summary: Given past issues in older versions of Ord and in anticipation of significant updates, we propose that indexers standardize on the current reference version (0.9) to ensure consistent inscription validity and state stability in brc-20.


If you see things differently or envision alternative paths for brc-20, we invite you to participate in the discussion below. Absent significant opposition within the 7 days following this post, we’ll designate a specific block_height to formally integrate this resolution into brc-20’s specifications.

11 Likes

ALEX and Bitcoin Oracle are in full support of this proposal.

3 Likes

I support this proposal.

It is particularly relevant given that we continue to discover potentially protocol breaking issues like Inscription ID incongruity: Issue #2590

BRC-20 should not trust the ord client development version to version and should instead ossify until development is stable or the protocol has been sufficiently defined.

4 Likes

[Best in Slot] supports the freeze to 0.9 :saluting_face:

3 Likes

This proposal will officially come into effect in brc-20’s specifications at block height 816000

4 Likes

Congrats.
I witness THE FREEZE :100:

1 Like

Support this protocol!

I’ll repost this thought from another post here:

I really think that it would be better if the jubilee is processed and blessed inscriptions are just ignored. As far as I know, those inscriptions will all get blessed on a block that’s far away from the block they were mined, so it should be relatively easy to identify them. If brc-20 was tied to a specific version of ord, it should be the one after the jubilee. Here are the reasons:

  • brc-20’s biggest criticism is the UTXO mess it creates. With reinscriptions being blessed, multiple operations can exist on a single sat/UTXO, solving this issue.
  • minting costs for brc-20 are big due to the limitations of the old versions of ord. Using batch inscriptions, it would be cheaper to mint and make multiple operations in a single inscription operation.

These benefits would drastically improve the cost and efficiency of the protocol and I don’t think they should be ignored.

While it’s clear that adding both reinscription and batch inscribing could enhance the brc-20 standard, the risks associated with unforeseen outcomes from the Jubilee event should be carefully considered. I hope that in the future, brc-20 might either aim for alignment with an updated version of ORD in maintenance mode or consider integrating these inscription methods directly into its reference implementation.

Support this proposal.

In the Open Protocol Indexer (OPI), it’s mentioned that OPI is based on a fork of ord 0.9.0, but with slight modifications to stay aligned with the foundational layer rules.

This means that the indexer isn’t an exact freeze of 0.9.0, correct? So, does this imply that brc-20 should be regarded as a fork of Ordinals?

Support this proposal. Thank you

We support domo! The risks associated with unforeseen outcomes from the Jubilee event should be carefully considered!