Flag to restrict minting rights

[HubertusVIE]

For Bitcredit Protocol, we need a "serious" digital asset to represent guarantee capital which secures Bitcoin Credit Money redemption by permissionless Wildcat mints (based on Cashu). It does nothing, apart from existing positively to be verifiable and tradable. Think of it like a bond. It must sit on Bitcoin mainchain to inherit its security, so Runes would be great.

It is also necessary that the issuance extends over approximately 130 years, similar to Bitcoin itself. Issuance is a certain number of new guarantee tokens per quarter, declining by a certain percentage each time. Only the project's Governance should have the right to mint the token, it handles further distribution according to work and contributions, not unlike BISQ's coloured coins.

At the moment, we could only do 130x4 declining mints immediately after deployment. Problem is: the total supply would immediately exist from a regulatory / legal / tax PoV, which triggers a rat's tail of real world risks and complications in some countries with overreaching securities regulators.

Solution:

1. Add a flag for the etching governance yes/no.
2. When minting, first check if flag is set and only allow minting by the original deployer.

We'd be most grateful for your help with this requirement for Bitcredit project. Any chance?

[cryptoni9n]

I'm not sure I understand the specific use case presented, but I think I can see general uses for such a feature.

It could be sort of a ticketing system rune - with governance, maybe a mechanism is created that watches an address for payments, and that triggers a mint with destination to the payee. Concert ticket runes could maybe replace something like ticketmaster this way? Am I off on a tangent?

[HubertusVIE]

watches an address for payments, and that triggers a mint with destination to the payee. Am I off on a tangent?

Agree that ticketing is another "serious" use case, just without the regulatory urgency.

Bitcredit Protocol plans BISQ like decentralised governance, votes decide number and recipient and automatically trigger a mint.

[casey]

At the moment, we could only do 130x4 declining mints immediately after deployment. Problem is: the total supply would immediately exist from a regulatory / legal / tax PoV, which triggers a rat's tail of real world risks and complications in some countries with overreaching securities regulators.

Can you give a little color on the regulatory / legal / tax problems that creating the supply in advance would cause? I want to make sure that I understand the motivation for this, and that it can't be solved through some other mechanism. If the tokens don't have a guaranteed, fixed value, can't they sit on the books without a tax / legal / whatever event happening on issuance?

If this is absolutely necessary, I think a better mechanism would be to have a flag which allows mint transactions only when the parent inscription created in the etching transaction is in the inputs of the mint transaction. This allows a similar mechanism, but doesn't tie it to a fixed address. Unlike using a fixed address, the parent inscription can be moved to a new address, which allows changing custody setup, using a new address type, etcetera.

[casey]

Also, what is the specific issuance schedule want to implement? I'm curious if it's deterministic or discretionary.

[vforvilela]

Following from #3680, where I make a more general case for all type central entity backed instruments:

I want to make sure that I understand the motivation for this, and that it can't be solved through some other mechanism.

Let's say I'm Tether, a company going public, or maybe a state issuing bonds.

In neither case can I know in advance how many USDT, stocks, or bonds I will issue. Moreover, I cannot afford to leave the cap open to someone else to mint.

I guess I could make one etching for each issuance event, but then the instruments of each etching round wouldn't be fungible. Or I could make huge mint upfront and just release tokens as needed, but it would display wrong numbers for supply and market cap in marketplaces.

If this is absolutely necessary, I think a better mechanism would be to have a flag which allows mint transactions only when the parent inscription created in the etching transaction is in the inputs of the mint transaction.

Perfect.

[HubertusVIE]

Can you give a little color on the regulatory / legal / tax problems that creating the supply in advance would cause?

One example is that pre-issued tokens sitting in some treasury, e.g. overstate actual supply, distorting numbers like ridiculous market caps. Pre-issued tokens can get you in trouble with SEC, they are 'fine' (simplifying) with Bitcoin which is issued only upon-proof of-work. Valuation rules would create tax risks with the entity holding these non-existing yet already existing tokens. Can of worms.

If this is absolutely necessary, I think a better mechanism would be to have a flag which allows mint transactions only when the parent inscription created in the etching transaction is in the inputs of the mint transaction.

Yes, that sounds advantageous and works for our use case. Appreciated, thanks.

[HubertusVIE]

I'm curious if it's deterministic or discretionary.

Deterministic, declining by epoch similar to Bitcoin block rewards. The distribution to outputs will be according to a vote, similar to how Manfred K. organised it for BISQ. (Link) In combination with a burn, it is a perpetual way to reward contributors in a decentralised fashion, forever.

[HubertusVIE]

In neither case can I know in advance how many USDT, stocks, or bonds I will issue.

In our specific requirement, the schedule is pre-determined. But yes, if the 'governance flag = yes' it would give more use cases if max supply is not set.

Moreover, I cannot afford to leave the cap open to someone else to mint.

That's indeed a key problem for such 'serious' applications in the real economy.

[starbackr-dev]

I was searching for this and found this issue. Definitely require this to solve many use cases where the etcher should be the only minter. i like the idea of "only allow when etching transaction is in the inputs of the mint transaction"

+1

[xffa]

I have a similar use case. I want to etch real estate backed tokens (runes). As more RE is added to the pool of managed estates more runes shall be minted. As runes are bought back it shall be burned. Burning does not need to be restricted but it is a stopper if anyone can just mint ownership pegged tokens, as it’s a stopper to premine due to market dynamics. I hope this change feature will find their way into existence. Also, Casey’s solution to allow governance handout to another address is useful and elegant. +1

[HubertusVIE]

I hope this change feature will find their way into existence.

I do, too. Unfortunately I am an economist so cannot build the needful. We can do a bounty, though.

[HubertusVIE]

I just learned that BRC-20 has something like this feature now, standard for newly inscribed 5-byte BRC-20's. The parameter is "self-mint". Unfortunately, not upwards compatible for existing BRC-20s, but that won't matter if we swap to Runes. See: https://l1f.discourse.group/t/brc-20-proposal-for-issuance-and-burn-enhancements-brc20-ip-1/621

[casey]

I think I'm going to close this for now. The best way I can think of to do this would be require that, if a rune has the "self-mint" flag set, the parent inscription of the rune must be in the inputs of a future mint transaction. However, this would represent a substantial increase in the complexity of the runes protocol, because the runes protocol would then have a hard dependency on the ordinals and inscriptions protocols. We've tried to keep runes as simple as possible, and this would make it much harder for complete 3rd party implementations to be written, since they would now also need to implement all of ordinals and runes.

I continue to think that, although a bit sloppy, minting out a massive amount of tokens up front is a technically fine solution, legal issues notwithstanding.

BRC-20 has this feature, so if this continues to be highly demanded and widely used on BRC-20, we'll reconsider it in the future.

Thanks all for the discussion and feedback!

[HubertusVIE]

I argue that a decision to close this proposed improvement warrants reconsideration.

BRC-20 has this feature, so if this continues to be highly demanded

I agree that there will likely not be a "massive" demand, you always said that 99.9% of Runes only serve degens. This sounds fatalistic, so maybe we agree it's not to the best for Runes.

Self-Mint will be for that 0.1% serious demand, for the few applications which are truly useful in the real world, the real mission of bitcoin. SoV does not change anything in what's happening with inflation, asset bubbles, distortions, economic inequality. One such application is absolutely needed from an Austrian Economics perspective, for bitcoin to monetise as a MoE in the real economy, and to contradict detractors like Mrs. Warren who defame Bitcoin as a useless ponzi.

The self-mint function will generate (1) massive value for Bitcoin and (2) sustainable demand for Runes transactions beyond degen shenanigans.

Yes, we could move Bitcredit Protocol from BRC-20 4-byte to the new 5-byte method but BRC-20 has a bad rep so we don't really want that.

a substantial increase in the complexity of the runes protocol, because the runes protocol would then have a hard dependency on the ordinals and inscriptions protocols

There may be some simplification? Like with BRC-20 5-byte vs. 4 byte there could be some convention to distinguish self-mint Runes, e.g. a $ prefix, a certain length, whatever. All other mints could proceed as is. Such a distinction would also be very useful to distinguish the two very different Rune types, actually indispensable.

Admittedly, I am not sure what "the hard dependency on the ordinals and inscriptions protocols" implies. BRC-20 5-byte could point the way to the simpler implementation.

Maybe @raphjaph has an idea?

[casey]

I think the main issue is just that the workaround of premining reserve 2**128 tokens provides excellent flexibility and requires zero changes to the underlying protocol. You can custody those tokens however you like, you don't need to worry about custodying an inscription (which you would if the self-mint solution were inscription-based) or a special key (which you would if the solution was not). You can move tokens out of the reserve at any pace, split them, custody parts separately, etc. The only real advantage of self-mint is accounting, and it feels like there are probably good workarounds for that.

[HubertusVIE]

custody those tokens however you like, you don't need to worry about custodying an inscription

The project had lots of discussions around this, and unfortunately most people have reservations to this logical approach. Psychologically the effect of these tokens already in existence is different.

What if Satoshi had pre-mined all 21 million Bitcoin and asked people to trust him do the needful?

it feels like there are probably good workarounds for that.

What is the actual difficulty for implementing a solid solution instead of a flimsy workaround? I think there must be options to do this quite elegantly and focused. You came up with a different (more powerful?) idea in your first post but is that really necessary?

[xffa]

I think the main issue is just that the workaround of premining reserve 2**128 tokens provides excellent flexibility and requires zero changes to the underlying protocol. You can custody those tokens however you like, you don't need to worry about custodying an inscription (which you would if the self-mint solution were inscription-based) or a special key (which you would if the solution was not). You can move tokens out of the reserve at any pace, split them, custody parts separately, etc. The only real advantage of self-mint is accounting, and it feels like there are probably good workarounds for that.

Hello, for my use case it's also not possible to deal it this way as accountability demands circulating supply to be verifiable. It's a typical use case when minting and burning shall occur on-demand accorting to the avaiability of an economic good. It's the case for most stablecoin, credit and debit flows, also for several lottery approaches. If one token means a silver once than the number of tokens must be equal to how many silver onces exists pegged to the circulating. Same goes for swiss franc pegged token, for Penrose Tiles to fill up a plan (if the ceramic factory has made 10 units of a limited-edition Penrose Tiles the equal number of tokens shall exist, if one is bougbt back it should be burned, if 30M where made 30M shall be mint, it's not the case to mint upfront and keep a stock and mark it "non-circulating" and if more tiles were made than premint - the mane makes it sound as bad as the approach... premint ha... hello Vitalik - we can not "fraction" previously existing tokens because one token still means 1 tile, not 1 token 2 tiles).

The fact is, if it's not implemented in Runes, it's a NO-GO for several projects within Bitcoin blockchain for now as the reasons to not doing it using BRC-20 way is not directly related to popularity of the feature but to reasons to also consider BRC-20 a NO-GO.

Hope you reconsider.

[HubertusVIE]

Hope you reconsider.

That sentence triggered me.

We are f*ing cypherpunks. @0xffa @vforvilela @starbackr-dev @cryptoni9n

A possible solution would be a fork, then there'll be "Degenerate Runes" and "Serious Runes". Most public appearances about Runes so far have an "It's Just for Degens" embarrassed vibe. Quite defensive.

[vforvilela]

Just watched Casey with Peter McCormack discussing Runes. https://youtu.be/_nvNTR5_IX4?si=jpwNK-OUSk4MIN40&t=3174

All the cool things they discussed, including issuing equity for Bedford FC, depend on this request.

With this, we could have Tether issuing USDT, MicroStrategy issuing equity, and El Salvador issuing debt. In other words, this could be the foundation of a new financial structure.

Without it, all we have are dog coins.

Make your choice. :)

[eksffa]

Without it, all we have are dog coins.

And here we are. Maybe this feature is not needed to break btc? lmao

[HubertusVIE]

Without it, all we have are dog coins.

That's the point, totally undesirable. Can sb technical expand on the difficulty mentioned by @casey?

"The Runes protocol would then have a hard dependency on the ordinals and inscriptions protocols."

I'd need to understand this hindrance better. If BRC-20 can do 'self-mint', why not Runes? It's supposedly better.

[cryptoni9n]

Without it, all we have are dog coins.

That's the point, totally undesirable. Can sb technical expand on the difficulty mentioned by @casey?

"The Runes protocol would then have a hard dependency on the ordinals and inscriptions protocols."

I'd need to understand this hindrance better. If BRC-20 can do 'self-mint', why not Runes? It's supposedly better.

I believe what he means is that this change, if implemented in the way he has suggested, would require the minting of the rune to have the parent inscription from the etching involved in each mint tx. Due to that dependency of requiring a Rune mint to include an inscription, the change is deemed undesirable.

[HubertusVIE]

require the minting of the rune to have the parent inscription from the etching involved in each mint tx.

1. I understand this so far, and BRC-20 does not seem to suffer from that. So where's the difference?

2. How could we take this forward the cypherpunk way?

• [ ] Analyse how BRC-20 5-Byte implemented
• [ ] Brainstorm minimal ways for verifiable governance supply on Runes
• [ ] Create a fork for 'Serious Runes'. ('Honest Runes'?)
• [ ] Talk to Unisat & Co. who offer BRC-20 5-Byte

[cryptoni9n]

require the minting of the rune to have the parent inscription from the etching involved in each mint tx.

1. I understand this so far, and BRC-20 does not seem to suffer from that. So where's the difference?

2. How could we take this forward the cypherpunk way?

* [ ]  Analyse how BRC-20 5-Byte implemented

* [ ]  Brainstorm minimal ways for verifiable governance supply on Runes

* [ ]  Create a fork for 'Serious Runes'. ('Honest Runes'?)

* [ ]  Talk to Unisat & Co. who offer BRC-20 5-Byte

I was thinking about the original proposal, of allowing the mint only from the original deployer. I don't see why it couldn't be address based. Yes, it's more of a dependency on the actual wallet, and if you lost that seed phrase and wallet access, no one would be able to mint it again. I understand why this would be undesirable and why the method Casey suggested would be more versatile, but this way would remove the rune dependency on ordinals.

The way I imagine it, the mint function would 1) need to know the etching address for any flagged 'self-mint' rune, and 2) be able to authorize/verify that the minting address matched. Currently, ord stores the etching address in the genesis transaction of the rune, but not as an attribute of the rune itself. I would think that if you set the self-mint flag at etch time, then the etching address would get written to a new rune field called 'self-mint', (which would require a new db schema). Then, the mint function would somehow need to verify that the mint request was being submitted by the etching address in order to be successful. Any attempt at a self-mint from the non-etching address that made it to the mempool should then fail and become a cenotaph.

It could even be possible to apply this to previously etched runes retroactively if they have the turbo flag checked, since the etching address could be looked up from the ord index.

As Casey mentioned above, it does complicate the runes protocol quite a bit, but it would no longer be dependent upon ordinals.

[vforvilela]

... BRC-20 does not seem to suffer from that. So where's the difference?

That BRC-20 fully depends on ordinals and that's undesirable (and unacceptable to @casey).

I don't see why it couldn't be address based. Yes, it's more of a dependency on the actual wallet, and if you lost that seed phrase and wallet access, no one would be able to mint it again. I understand why this would be undesirable and why the method Casey suggested would be more versatile, but this way would remove the rune dependency on ordinals.

We lose the ability to transfer the etching rights, but we eliminate the ordinals dependency. Sounds like an acceptable compromise to me.

What do you say, @casey ?

PS: With this solution implemented, we can think of other options for etching rights transfer ...like a new runestone specifically for this ...or maybe each etching could optionally (with a flag) change the etching rights to the new destination address or not.

We have plenty of options without ordinals.

[HubertusVIE]

We lose the ability to transfer the etching rights, but we eliminate the ordinals dependency.

I agree that this is an acceptable compromise.

Even in the unlikely event of imbeciles losing the governance address, the project could create a new rune as it is all about governance in first place.

BTW: The tax and legal implications of no self-mint capability are very nasty, as this is for real business, not just some useless meme-coins for degens. Keeping existing treasury tokens could land people in prison in evil jurisdictions. Not funny.

[HubertusVIE]

Serious question: What's an appropriate grant/bounty to offer as a reward to build the simple variation? @0xffa @vforvilela @starbackr-dev @cryptoni9n

PS: Instead of a Byte-lenght we could also work with a prefix.

[cmdruid]

Throwing in my vote for this sorely needed feature.

Minting all runes at once seems like a hack. It makes accounting needlessly difficult versus a much simpler mint-in, burn-out method for regulating supply.

There should be an option to restrict minting to ownership of a particular utxo or set of utxos. How about when the rune is etched, restrict minting to owners of the utxos that were also created with that etching?

Since you have to track utxo ownership for runes, it seems like you could re-use the same code for tracking minting rights.

Using ordinals or inscriptions would be a better way to track it, but if you wanted to avoid co-mingling the two (which I don't understand, ord covers everything), maybe use the utxo crawling logic to link a utxo back to the original etching?

[zk-bits]

Hey @casey, throwing my proverbial hat in the ring:

I think the main issue is just that the workaround of pre-mining reserve 2^128 tokens provides excellent flexibility and requires zero changes to the underlying protocol.

There’s no change to the ethos of runes as a protocol by offering functionality like time-based minting. Whether you fill a glass by dropping a bucket of water into it or using a dripper, you still end up with a full glass.

I understand the reluctance to modify or add to the protocol for frivolous reasons, but I struggle to identify any improvement to runes with as significant a use-case impact as permissioned minting, while keeping the level of programmability intact.

Quite frankly, the current pre-mine amount is a workaround—this is the solution. Pre-mines are an interesting feature that should definitely stay in the protocol, but we also need some flexibility on how the runes are distributed.

The only real advantage of self-mint is accounting, and it feels like there are probably good workarounds for that.

The advantage is huge, and if I'm interpreting other comments correctly, it’s the very reason we’re considering this in the first place. But beyond accounting, we gain additional benefits:

• Enhanced Ownership Transparency: Facilitates better visibility over ownership percentages.
• Realistic User Interactions: Mimics real-world interactions with digital commodities more closely, allowing for issuance as needed rather than through centralised planning.

There’s a way to solve this that:

• Doesn’t tie ordinals to runes irredeemably.
• Creates no MEV.
• Sustains the ethos.
• Can be made backwards compatible.

My main ask from you is to help me understand what is holding you back here:

• Is this an Ideological Problem?
  What core tenet is this proposal jeopardizing?

• Is this an Engineering Problem?
  What limitations are your red lines—complexity, coupling, etc.?

• Is this a Dismissal of the Problem?
  Do you think this is just not worth the overhead? What would make you change your mind?

Bonus: More mints more fees!

[casey]

I'm simply not convinced that the complexity to benefit ratio is there.

Enhanced Ownership Transparency: Facilitates better visibility over ownership percentages.

Just publish the reserve where un-issued runes are held. We could even add a rule that any runes held in the same address as the rune parent inscription is reported as "reserved" on the website.

Realistic User Interactions: Mimics real-world interactions with digital commodities more closely, allowing for issuance as needed rather than through centralised planning.

Minting rights are centralized planning.

Also, creating all the runes you might need up front has real benefits:

• You can time lock them, split them up however you want, whatever the base chain allows. Anything like this would had to be explicitly added as a runes-specific feature. Like, for example, you'd have to set how often you can issue new runes, the amount you can issue each time, some way of supporting a multisig, and on and on. These are all things that you don't need to add specifically if you just mint up front and hold in reserve.

• It's also more transparent. Users can plainly see that a ton of runes have been issued and are held in reserve, instead of just seeing that the creator of the rune holds minting rights.

So yeah, just not convinced that there's real benefit which outweighs the complexity.

[zk-bits]

Thats fair, and a great starting point.

Just publish the reserve where un-issued runes are held.

I think the importance of the restricted minting, in the context of this conversation, comes from a desire to have the basics, etch, mint, and transfer, be native and consistent with the protocol, while having the flexibility to adapt to more complex use-cases. Doing the above would defeat the point

Minting rights are centralised planning.

Minting rights are not centralised planning, minting rights allow us to, for example interface with a system using FROST to blind sign transactions for minting.

There is a point of centralisation, sure, but the supply expansion and deflation responds to a user need/want, not to a central planners idea of the necessary supply.

Also, creating all the runes you might need up front has real benefits:

No ones is arguing against the benefits of a pre-mine, it plays an important role.

just not convinced that there's real benefit which outweighs the complexity.

The benefits of a rune that can be minted on demand lay on how it helps mimic real world use cases, you can suddenly represent: Synthetic Money, Bonds, Ticketing systems, Governance.. and thats just the ideas that came up in this thread!

I think the benefits exist and they enable a significant and interesting set of use cases. When it comes to the complexity I don't think there is anything I could write that would speak louder than a PR, so as long as you are not ideologically opposed to the idea of permissioned minting, Ill just go ahead and create one so we can actually look at the complexity in real time.

[casey]

Doing the above would defeat the point.

Why?

Minting rights are not centralised planning, minting rights allow us to, for example interface with a system using FROST to blind sign transactions for minting.

Minting rights are the right to create more runes, held by some key. A pre-mined supply of runes held in reserve are also held by some key. They are both central planning. They key holding a pre-mined supply of runes held in reserve could also be used with a system which used FROST which blind signs transactions.

There is a point of centralisation, sure, but the supply expansion and deflation responds to a user need/want, not to a central planners idea of the necessary supply.

Since there is a key in both cases which can bring more runes into circulation, they are not responding to user need/want, they are central planning.

No ones is arguing against the benefits of a pre-mine, it plays an important role.

I mention premines because they are the alternative to minting rights.

The benefits of a rune that can be minted on demand lay on how it helps mimic real world use cases, you can suddenly represent: Synthetic Money, Bonds, Ticketing systems, Governance.. and thats just the ideas that came up in this thread!

These things are all web3 / crypto rube goldberg machine pipe dreams. Plus, you can do all these things with a pre-mined reserve.

I think the benefits exist and they enable a significant and interesting set of use cases. When it comes to the complexity I don't think there is anything I could write that would speak louder than a PR, so as long as you are not ideologically opposed to the idea of permissioned minting, Ill just go ahead and create one so we can actually look at the complexity in real time.

I am not ideologically opposed. I am opposed on practical grounds, since I am not convinced they solve a real problem.

[zk-bits]

I can break down my counter-argument into three parts:

1. Protocol Consistency and Scalability If we have to generate these controls off-band, as you've suggested, they’re not part of the protocol. This makes it a lot harder—maybe even impossible—to get these changes recognized by third parties, which is a big reason why people use runes in the first place, my suspicions is you view this as an application specific decision, how to manage your runes, instead of viewing it as a core part of the protocol which is how do this runes come into existence. I think providing flexibility here is sorely needed.

2. Perception and User Trust As for centralized planning versus decentralised control, I think this is more about optics. Whether we call it centralized planning or not, the perception matters:

   • Dropping a massive supply upfront can skew how users view the project. It can come off as artificial and might turn people off.
   • Minting on Demand: Letting the etcher issue runes as the project evolves keeps the supply in line with what’s actually needed. This approach feels more natural and is more likely to gain user trust than just having 100 trillion runes minted and sitting in reserve. The key point here is that minting on demand from a single user ensures that the supply reflects the current state of the tokens in circulation.

3. Issues with Reserve-Based Solutions Your idea of adding another flag to mark runes as being in reserve could work, but it’s more of a patch than a real fix. Here’s why:

   • You’ve got one UTXO, and now you have to break it down based on application needs and then send it over. If you don’t reorganize the UTXOs, you could end up with a bottleneck for transfers from the reserve, making the whole process even more complicated. Simplified Minting: With permissioned minting, you could just mint directly to another address without dealing with UTXO management. It’s simpler and avoids unnecessary hassle.

My overall take, directly addressing your practicality concerns is that this proposal might not introduce use-cases that a pre-mine can’t already handle, but it does make things a lot cleaner and more straightforward for

• Treasury Management
• Supply Management
• Ownership
• Less Fragmentation in How People Handle Reserves
• Smoother Integration with Third-Party Services Plus, it makes rune minting more accessible for people looking to build on top of them. This isn’t just about doing the same thing a different way—it’s about evolving the protocol to make it better and streamlined,

The contention here is that minting runes into existence should have a middle ground between pre-mining absolutely all of them, and having people have a free for all. But more importantly that there should be protocol-level consensus on how this middle ground is achieved.

[casey]

1. Protocol Consistency and Scalability If we have to generate these controls off-band, as you've suggested, they’re not part of the protocol. This makes it a lot harder—maybe even impossible—to get these changes recognized by third parties, which is a big reason why people use runes in the first place, my suspicions is you view this as an application specific decision, how to manage your runes, instead of viewing it as a core part of the protocol which is how do this runes come into existence. I think providing flexibility here is sorely needed.

I don't really think this is a problem. I can add to the docs that if you want to hold runes "in reserve" you should hold them in the same address as the parent inscription. This is pretty easy for anyone to implement.

2. Perception and User Trust As for centralized planning versus decentralised control, I think this is more about optics. Whether we call it centralized planning or not, the perception matters:

In my opinion, this is a feature, not a bug. Both supply-up-front and mint-on-demand have the same practical effect: Central issuer can dilute circulating supply arbitrarily and at-will. It is good if users are aware of this and it makes them nervous. It is an argument against adding mint-on-demand that it makes users more comfortable with the same possibility of circulating supply dilution.

3. Issues with Reserve-Based Solutions Your idea of adding another flag to mark runes as being in reserve could work, but it’s more of a patch than a real fix. Here’s why:

• You’ve got one UTXO, and now you have to break it down based on application needs and then send it over. If you don’t reorganize the UTXOs, you could end up with a bottleneck for transfers from the reserve, making the whole process even more complicated. Simplified Minting: With permissioned minting, you could just mint directly to another address without dealing with UTXO management. It’s simpler and avoids unnecessary hassle.

UTXO management is simple. Every time you want to mint, you create a transaction with the reserve UTXO and any UTXOs needed to pay fees. As outputs, it has the new reserve UTXO, any new UTXOs which are receiving runes, and any UTXOs needed to receive change. If you keep your reserve UTXO with enough BTC to pay any fees, it becomes even simpler.

My overall take, directly addressing your practicality concerns is that this proposal might not introduce use-cases that a pre-mine can’t already handle, but it does make things a lot cleaner and more straightforward for

• Treasury Management
• Supply Management
• Ownership
• Less Fragmentation in How People Handle Reserves
• Smoother Integration with Third-Party Services

I do not see how any of these are any harder with the reserve strategy The reserve strategy can be implemented today, with no protocol changes, and can accommodate all of these use-cases. In fact, it is even more flexible than any mint-on-demand protocol, because you can split up reserve UTXOs, encumber them with any timelocks or scripts, etc.

[casey]

See #3895 for the issue tracking display of reserved runes held in the same address as the parent inscription.

[zk-bits]

I can likely live with the above with out committing seppuku I guess 🫡