PROPOSED BLOCK ACTIVATION HEIGHT: 837090
Introduction
This proposal aims to introduce enhancements to the BRC-20 protocol to address current limitations and improve its functionality. The proposed changes include the introduction of a self-issuance mechanism, modifications to the deploy inscription, adoption of 5-byte tickers, and establishing a consensus on the burn method for BRC-20 assets.
Objective
We intend to utilize the L1F forums for transparent communication of the intent, potential benefits, and considerations of each proposal. This will invite open discussions and feedback from the broader community, ensuring engagement and understanding of the direction and rationale behind each innovation.
Proposal Part 1: Self Issuance
Self Issuance Mechanism
The default BRC-20 standard uses a public issuance method for the deployment and distribution of assets. We propose a new way that allows only the deployer to participate in minting after the asset deployment.
Changes to Deploy Inscription
A new field called self_mint can be added to the original BRC-20 protocol’s deploy operation. This setting ensures that only the deployer can issue the current asset. Under this mode, when issuing the mint inscription, the deploy inscription must be used as the parent of the mint inscription; otherwise, the mint is invalid.
Example of inscription content for assets with self-issuance:
{
"p": "brc-20",
"op": "deploy",
"self_mint": "true",
"tick": "ordi",
"max": "21000000",
"lim": "1000"
}
When max=0, it is proposed to allow an unlimited maximum issuance for self_mint. For BRC-20, the meaning of max is the total upper limit of all mints (max_uint64 (2 ** 64-1) * (10 ** decimals)). Note that BRC-20 assets do not “disappear” when sent to a burn address; the available space for additional minting does not reopen.
Adopting 5-byte Tickers
We propose self-issuing an asset with a 5-byte ticker to isolate existing assets, based on the suggestion from @SeeSharp. This will ensure that indexers not yet prepared for this change will simply ignore these assets.
Benefits and Considerations
Benefits:
-
Allows for controlled issuance of assets, and prevents unauthorized minting.
-
Provides a more secure and regulated environment for asset deployment.
-
Adopting 5-byte tickers helps mitigate the risk of asset collisions and clarifies the distinction between self-issued and publicly issued assets, enhancing overall asset management and identification.
Considerations:
- Implementing the self-issuance mechanism and expanding the ticker space necessitates extra development effort and could lead to compatibility challenges with systems that have not yet adapted to these modifications.
Source Code
The source code for this part of the proposal can be found at:
GitHub - OPI Commit for Part 1
Proposal Part 2: Consensus on Burn Method
There is no specific consensus on the destruction of BRC-20 assets. We propose a universal method for the destruction of BRC-20 assets: sending the TRANSFER transaction to an OP_RETURN script that contains no data. This method is proven to be unspendable within the Bitcoin protocol and is the least expensive method.
For BRC-20 assets that have been burned, they cannot be minted again. The max value represents the total upper limit of all minted assets.
Benefits and Considerations
Benefits:
-
Provides a clear and standardized method for asset destruction.
-
Ensures that burned assets cannot be reminted, maintaining the integrity of the asset supply.
Considerations:
- Requires community consensus and adoption of the proposed burn method.
Source Code
The source code for this part of the proposal can be found at:
GitHub - OPI Commit for Part 2
Conclusion
The proposed enhancements to the BRC-20 protocol aim to improve its functionality and address current limitations. We invite the community to engage in discussions and provide feedback on these proposals through the L1F forums. Your input is invaluable in shaping the future of the BRC-20 protocol.
Clarifications
- Initially, 5-byte tickers issuance will be restricted to self-minting, with the option for open mint issuance being introduced at a later stage, potentially around April 30th.
- The standard will maintain compatibility with the behavior of Ord version 0.14, which is important for managing parent-child indexing relationships.