Establishing a Standardization Process for Ordinals

[HGraphPunks]

Hey All!

There's so much development in this space going at lightning speeds, but the lack of a standardization process is starting to impede understanding between devs and even the community on what is and isn't supported (example: BRC20 & BRC30 update)

Mass adoption is the current mechanism on which a standard is accepted, and twitter threads have been ways to propose updates. Below is my proposal to solidify a structured standardization methodology that pulls a lot from the BIP process, but is it's own, so Ordinals process can adapt and grow as needed over time.

My Intension: I do not and am not trying to dictate anything.

Rather I'm trying to start discussion and solidification of process for Ordinals to be able to easily scale with a strong foundation that all developers can understand what is and isn't a approved format for developing on Ordinals.

A. The Ordinal Improvement Proposal (OIP)

Taking inspiration from the Bitcoin Improvement Proposal (BIP), the Ordinal Improvement Proposal (OIP) can serve as a standardized means of proposing changes to the functionality of the Ordinals solution​. As an open-source project, anyone can propose an OIP. Before formal submission, it's recommended that the idea be discussed in community forums (Discussions page on github) to gauge support​.

B. The Approval Process

An OIP will require a champion who will author the proposal and convert it into detailed technical documentation according to OIP standards. The OIP champion submits the proposal to an OIP editor, an individual responsible for auditing the proposal, ensuring its language, format, and technical feasibility. After the editor approves the proposal, it is given an official number and presented to the community​.

C. Stages of an OIP

An OIP goes through several stages before it can be implemented:

• Draft: The OIP is submitted to the community.
• Proposed: The OIP includes a plan for implementing the change.
• Final: The OIP is accepted and ready to be implemented.

The upgrade must then be merged into code as a branch then main when activated. Not all OIPs that get merged into the code will ultimately be accepted and activated​.

D. Consensus and Implementation

Implementing an OIP can take time as the community discusses the idea, makes changes, and finally reaches a consensus. Since the Ordinals protocol does not have a central authority, developers must agree on the rules and reach a consensus to update the codebase. Nodes / Indexers / etc would decide whether to activate the proposals by agreeing to run the version of the Ordinals code that includes the new changes​.

TODO: Create a method of consensus and project owners that should help direct the standardization process and be the authority of accepting or denying proposed updates through a community driven consensus mechanism.

There are three types of OIPs:

• Consensus OIPs: These OIPs introduce changes that are compatible with the older version of the network. They require a clear majority of core developers to approve the upgrade. Consensus in this context is referring to indexing consensus / updating the main indexer (like v 0.6.0 introducing cursed inscriptions). This process needs focus on how to best create an authority that is decentralized and fair.
• Hard fork OIPs: These are radical upgrades that create a new main branch, rendering the old one invalid. These proposals require universal approval from everyone who participates in the network, including indexers, exchanges, wallet providers, and so on.
• Process OIPs: These introduce new processes and decision-making in the network. They propose rules and processes on how to make rules​.

This process takes inspiration from Bitcoin's BIPs, which have proven to be effective in maintaining and improving the Bitcoin network. The first ever BIP was BIP 001, which described what a Bitcoin Improvement Proposal is. This was followed by BIP 002, which revised the guidelines for BIPs.

By adopting a similar process, Ordinals can ensure a structured approach to improving their solution, allowing for continuous upgrades and improvements while preserving the principles of decentralization and community consensus.

Sample OIP-001 can be found here

[tyjvazum]

I think this is a great initiative. @Psifour is working on something similar at ordocs/oip#4. I'm not sure how much attention this will get here, so you might want to discuss things there too. I'm developing arb, with a focus on higher-level features. I look forward to participating in documentation and standardization efforts like this.

[HGraphPunks]

I'll checkout arb this weekend, thanks for commenting!

I like what @Psifour has started, def need a place of centralized understanding that's official.

[hosir-web3]

Although ordinal relies on bitcoin, it currently has an independent system including positioning sat and inscriptions, and has extended a variety of applications. However, there is no clear consensus on the current ordinal standard. I think it is very important to establish the Ordinal Improvement Proposals (OIP).

[hosir-web3]

I have submit the first OIP at the discussion #2193.