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