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.
