Minting limits - detailed design

Governance SNS Project Governance
,
1

TL;DR: Limit the rate at which an SNS can mint SNS tokens.

The method here is analogous to the one used for limiting treasury transfer proposals, which was described in a previous post.

Background & Motivation

There is an SNS proposal type called MintSnsTokens. This mints SNS tokens (to an account specified in the proposal). As always, this occurs when the proposal is adopted.

Recently, some measures were implemented that raise the bar needed to pass such proposals. See the aforementioned post regarding “critical proposals”. There, minting proposals are considered “critical”. The purpose of those changes was to make sure that when an SNS adopts such proposals, it “really means it”, and that it’s not so easy for a malicious party to make the SNS do things with possibly dramatic negative consequences for the SNS, its dapp, and/or its token.

One of the measures taken earlier was to limit the rate that tokens can be transferred from the SNS treasury. Because minting also decreases the value of the treasury (via inflation), it seems to make sense to also limit minting.

Maximum Minting Rate

Depending on the size of the treasury, the amount of minting within a 7 day window will be limited. The limit will be based on the size of the treasury. The relationship between treasury size and minting limit is the same as the relationship between treasury size and treasury transfer limit.

More precisely, let T be the value of the SNS tokens in the treasury in XDR. (More on valuation in XDR in the “Assessing SNS Tokens in XDR” section.) Then, the 7-day minting limit is determined by this table:

Value of SNS Tokens in the Treasury, T Minting Limit
“small”: T ≤ 100_000 XDR T
“medium”: 100_000 < T ≤ 1_200_000 XDR 25% of T
“large”: T > 1_200_000 300_000 XDR

(Observation: Minting Limit / T is non-increasing: at first, it’s 100%, then 25%, then it decreases inversely proportional to T.)

Graphically, the relationship between T and Minting Limit can be explained like so:

1600×1453 143 KB

Assessing SNS Tokens in XDR

So far, all values have been stated in XDR. This section describes how such valuations are assessed. The method here is the same as the method used to limit the amount in treasury transfer proposals.

For this, two conversion rates are combined:

Valuation Factor Source
XDR per ICP (30 day moving average) Cycles Minting Canister
ICP per SNS token Swap Canister

For now, it is assumed that the current “fair value” of the SNS token is not much different from when the SNS token swap took place.

Next Steps

If there are no objections, implementing will begin soon. After that, this feature would be released in the usual way. We very much welcome your insightful and constructive feedback :pray::innocent:

4 Likes
2

If I am understanding this correctly a Treasury with the value of 99k xdr will be able to mint sns tokens in the equivalent value of 99k xdr?

3

It would be helpful to have a mechanism for a smart contract to control this without limits. If a canister is set as the minting account and it is controlled only by the SNS, could it get around these limits? Maybe another option is to have this take into effect burned tokens? It just seems like this limits the number of potential token use cases if the ability for the token to rebalance itself or have sovereignty over itself is restricted.

4

Does this mean it will take a long time to complete the future SNS token split?

1 Like
5

Hi Mico,

Yes, that is correct.

1 Like
6

Hi skilesare,

In SNS, the governance canister is the designated minter. This is intentional: such critical actions should be highly controlled.

What you can do is on a quarterly basis, propose to mint to another canister, and that canister can handle giving people SNS tokens on an “operational” basis.

Good point. This seems tangential though.

(I assume you are talking about burns that are performed via TransferSnsTreasuryFunds proposals?)

Yes, this is limiting. The point is to protect SNSs.

Can you describe a use case that you are interested in?

1 Like
7

Hi ysyms,

Not sure what “the future SNS token split” refers to.

IIRC, Dragginz did a token split recently. That would not have been allowed if these changes were in effect at that time. IMHO, that use case was a one-off, because Dragginz repurposed an existing SNS, which is a super unusual way to do it.

8

Well, I’ll be a bit blunt here. Most of the SNSs aren’t actually doing anything yet. Lots of great potential, but still building themselves out. I hope in the future, most of these ‘utility tokens’ will have lots and lots of utility. There are currently two ways to ‘utilitize’ tokens 1. Burn them 2. Stake them.

In instances where there is LOTS of utility, I would imagine LOTS of burning. In the right scenarios, even ones targeted at deflation, you may want to incentivize behavior with lots of MINTING. An SNS that burned xdr 5,000,000 per week and minted xdr 4,000,000 a week is certainly in the realm of something we’d want! (Last month ETH minted $178M and burned over $300M).

In January the IC minted 1.1M ICP(about $3m per week) from Maturity and 260,000 ICP(about $780k per week) for node providers. Most networks aren’t going to have their core utility be voting and will need to issue rewards the old-fashioned way - minting. Certainly, we want SNSs as valuable and productive as the NNS today?

If we go with ‘staking’ then most of the staking won’t be for voting rights…it will be for utility purposes. For example, in the various and past iterations of the OGY Network plans there was a method to stake tokens for collateral against the value of an item. These were to be rewarded via minting(Now we’re using a treasury as the token has gone hard capped, but many SNS won’t want to make that choice). My understanding was that the network would need to handle this kind of staking via its own SNS application canister that manages those stakes.

I’m not sure that ‘protecting SNSs’ is worth hamstringing these networks with a max ability to incentivize utility to 1.2M XDR per month. If my math is right, and you give a gracious multiple of 7x, I think you’d be capping the possible valuation of an SNS to 100M XDR(and network participants fighting over trying to corner a max 14M XDR per year in value).

There may be other ways for these networks to incentivize the use of the networks they building in the SNS code, but I just assumed it would be minting…please point me in the right direction if I should be looking for other methods in the code base.

(I assume you are talking about burns that are performed via TransferSnsTreasuryFunds proposals?)

No. I was talking about total burn for the network.

It seems to me that any mint should be percentage-based rather than hard-capped. Something like:

Mintable Amount = (Market Cap * max_percent) + Amount burned since last mint

And further, if the minting account can be set to a smart contract that the network has agreed on as the way the SNS works, I’m not sure it should be capped at all. I know there is only one minting account at the moment, but perhaps it should be an array so that as networks grow in complexity they can have componentized minters that have clear, easy-to-read contract on how minting occurs.

2 Likes
9
10

Thanks, skilesare.

IIUC, your main point is that being able to mint more rapidly could be used in nice ways. That’s probably true. Let’s wait for someone with a concrete use case where they need to mint > 3e5 XDR worth of SNS tokens every week. Then, we can figure out something else that works better. In the meantime, having some kind of basic protection(s) in place against inflation is definitely valuable, even if they more limiting than what we’d eventually want.

IIUC, one of your suggestions is to base minting limits on market capitalization (instead of treasury size). That makes quite a bit of sense. That’s definitely something that should be considered when someone has a more concrete use case that we can evaluate potential alternatives against.

1 Like
11

My concern is that you’re creating an unknown unknown for people who may potentially want to launch on the SNS. When someone sees the limit, but hasn’t seen our particular conversation about it, they’ll assume that they’re going to have to convince the NNS to this. That can be daunting, scary, and confusing to potential users. Why not pick a platform where there’s no limit?(This is a bit rhetorical as I think that most tokens would do best establishing market traction before they go to the SNS, but that’s a different conversation(also, I think there’s been some conversations to grease the skids for this kind of transition)).

2 Likes