[brc-20] Proposal for Issuance and Burn Enhancements, BRC20 - IP 1


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.

7 Likes

These are great proposals. Would the idea be to start off with 5-byte tickers for self issuance and then eventually open it to 4-byte tickers as well?

2 Likes

Looks good, You already have the code for self mint, good job ~

I can see arguments for both, standard consistency vs. clear mint method distinction by ticker. Fortunately this can be decided at a later date but community feedback would be useful in guiding this decision.

1 Like

The Arrival of Stablecoin Liquidity in the Inscription Dimension

This stablecoin is still built on the underlying architecture of Inscription #insc, so, ponder upon it, and ponder deeply.

In the future, all layer-one assets on the Bitcoin chain will rely on Inscription to operate, right? The quantity of inscriptions on the #insc chain will rely on the Self-Minting Proposal and Burning Proposal, directly connecting the liquidity of layer-one inscription assets on the Bitcoin chain.

The biggest beneficiaries, apart from all layer-one BRC20 inscription assets and the Ordinals small picture collection, are undoubtedly #insc, which possesses the future attributes of MEME, culture, technology, and consensus. The pace of inscription serial number reaching over one hundred million will definitely accelerate due to the issuance of stablecoin inscriptions! Accelerate! Accelerate!
(62,648,335 Total Inscriptions To Date)

As for the future imagination of inscription, I leave it to you.

#insc
#inscribe #inscription
#X言Y语 #TheBTCEcosystem
@Port3Network #Port3 #P3
#Bitcoin #Ordinals #Brc20 #UniSat #Brc20Swap

1 Like

This is definitely a good start in expanding the BRC-20 protocol. Any plans on adding the ability to do a multi transfer for airdrops?

The self-issuance mechanism introduction is a significant stride, enabling tighter control over asset minting. Permitting unlimited issuance when max=0 for self-mint assets provides valuable flexibility. These enhancements align well with stablecoin and other use cases, reflecting a keen understanding of the digital asset ecosystem’s diverse needs. Kudos to @domo and the community for the diligent work on these impactful proposals.

My rough back-of-the-envelope estimation for block 837,090 would have been estimated to be mined around March 31st. Correct me if I am wrong.

You are aware that Tap explicitly excluded 4 ticker symbols to be able to merge with BRC20, and also has 5 digit tickers that would clash with this proposal, right?

I think this represents a very short sighted solution to a plethora of opportunity. If you’re going to introduce change, then start at the basic level and make it impactful down the line:

Instead of a single additional action that you’re trading by introducing a new line, create a new field instead

{
“p”: “brc-20”,
“op”: “deploy”,
“meta” : “self_mint”: “74727565”,
“tick”: “ordi”,
“max”: “21000000”,
“lim”: “1000”
}

If you also force the “meta”: to be a hexadecimal field you can input both integer and text values to return things like true/false or numerical values, for the example self_mint function.
This would further allow any variation of function to be proposed to not only the deploy, but the mint and transfer function. I.e. you could create a “meta”: “group” function for “op”: transfers that would drop a pre-registered Group of wallets each the amount of ticker when sent to any one of those wallets from the creator.

Or any other function that people may come up with, you could easily add them to their respective DMT op after consensus without having to keep introducing new lines or ops.

As well, allow the “lim” line to be removed to auto deploy directly to a self_mint wallet the full allocation of “max”

from Bard A.I

Absolutely! Given today’s Bitcoin block height of 835,308 and a 10-minute block generation time, here’s how long it would take to reach block height 837,090:

Number of blocks remaining:

837,090 (target height) - 835,308 (current height) = 1,782 blocks

Estimated time to reach target block height:

1,782 blocks * 10 minutes/block = 17,820 minutes

Time in days:

17,820 minutes / (24 hours/day * 60 minutes/hour) = 12.38 days (approximately)

Therefore, it would take roughly 12.38 days to reach block height 837,090 from today, assuming a constant 10-minute block generation time.

Important note:

The actual time may vary slightly due to fluctuations in the Bitcoin network’s hashrate, which can affect block generation speed.

1 Like

This seems like a straightforward, somewhat uncontroversial proposal to add to the BRC-20 standard, I like this compared to other proposals I’ve seen.

Clarification: does this operation require the 330+ sat UTXO to also be burnt permanently?

1 Like

(in reference to Proposal 2, Consensus on Burn Method)

I personally think you should remain with the 4 ticker.

CBRC-20 is the only other protocol that is exclusively 4 ticker and index based. They also operate on the envelope, not in the content field and thus can do both operations on a single inscription. Anyways…

4 digit tickers are a comfortable standard. Being the first you’ve become the standard and what people from outside bitcoin feel safe with. You are already shaking up the world by adding more to BRC than just straight forward DMT; do you want to also confuse them by adding in action specific ticker lengths? Where would that stop, each new action gets another byte cuz indexers can’t keep up?

Degens will degen, with or without indexing. If a creator changes the rules with community consensus then the score keepers have to keep score by the new rules of the game, not continue playing by the old rules

1 Like

Excuse me, teachers. I didn’t understand if the original inscription would have a burn deflation function after modification, or if a new 5-byte inscription with a deflation mechanism should be recast

Clarification: does this operation require the 330+ sat UTXO to also be burnt permanently?

No, just burn only 1 sat.

1 Like

Cannot agree more on this.

Meanwhile, to better the issuance and burn issues.
Why not create “ins” section for deploy and add “to” section for transfer.

{
“p”: “brc-20”,
“op”: “deploy”,
“ins” : “xxxxxx(inscription_id)”,
“tick”: “USDT”,
“max”: “21000000”,
“lim”: “1000”
}

{
“p”: “brc-20”,
“ins” : “xxxxxx(inscription_id)”,
“op”: “transfer”,
“to”: “btc_address”,
“tick”: “USDT”,
“amt”: “100”
}

It will help solve the ticker issue as well. We can have different “USDT” based on different inscription_id

I think Both of you Have not Understand why the changes to 5 Tickers, to put it simple its because many indexers will not update their ordinals to reflect the changes.

IF we followed what you saying it will create massive confusion. IMO, we can Have it like this


"p": "brc-20",

"op": "deploy",

"self_mint": "true",

"tick": "$USDT",

"max": "21000000",

"lim": "1000"

}

We can Add Simple before the stablecoin or we can use , there is many different way to make this looks acceptable for international standards.

The Idea of all of this is to make it much easier for indexes to not feel confused.

As we are still discussing here, why there is already a PROPOSED BLOCK ACTIVATION HEIGHT: 837090?

Who will have the right to decide this proposal will be executed?
I noticed that we don’t really have the Consensus process for executing the proposal yet.

1 Like

How do you deploy something with its own inscription id, and what problem does this solve?

For the transfer, what is the point of adding the to address?

You’re causing more confusion by changing the standard imo. Not only are you going from 4 tickers to 5, but the sole reason is because of the introduction of a new action. Adding a symbol by default doesn’t make it any different than a TAP token that starts with the same symbol. The 4 byte was paramount to BRC branding imo.

I don’t understand how keeping the same 4 bytes is confusing?
Or how adding a new line that allows alteration to any of the base DMT function is confusing. All it would do in my eyes is open up each of the base functions to modifications that allow BRC20 to update and stay relevant.

We’re in this situation currently because of the lack of willingness to update to new functions. Adding 1 simple “meta” line would open up limitless possibilities. Including the self_mint Deploy function

I think there might be some confusion here. BRC20 is separate from TAP or BRC420.

Bitcoin’s built-in scripting language is limited (Turing incomplete), so it can’t directly understand Brc20 token functionality. Instead, BRC20 relies on external indexers to interpret Bitcoin transactions and track token movements.

Brc20 indexers need to interpret Bitcoin transactions containing BRC20 data and translate them into meaningful information about token transfers and balances. There's a strong incentive for indexers to maintain consistency, as any discrepancies would cause confusion and hinder the proper functioning of the Brc20 ecosystem.

Adding 5 Tickers make most of the senses for the stability of Brc20

one more thing " The problem is off-chain indexer communication, not necessarily the Json format or Brc20 functionality itself. "