SNS-1/DKP Tokenomics Announcement

[osman]

I saw a discussion on Twitter. It is said that the IC-X DAO treasury (150,000ICP) created under the SNS DAO was emptied through a proposal put to the vote. Is the SNS dao representative aware of this issue? Is there such a thing. Also, can any DAO treasury be emptied by voting? I’m curious about the explanations on this subject

[Jabberwocky]

Yeah the dragginz team showed that if you control 51% then you have control of the community fund. But instead of selling it they locked it for 888 years so they are guaranteed control of the DAO. ICX saw this same opportunity but did it to rug. I wonder how much they had to invest to get that $500k

[plsak]

Hi, as this is not doable (so easily - without help of the SNS team) I’m pointing out another suggestion - not sure how much work would it mean, but I believe it would be secure, transparent and elegant solution which might advance whole ICP ecosystem by new functionality:

Dragginz DKP (SNS-1) Tokenomics

Actually minting a new token would be much simpler (and cleaner) than changing tokenomics of the existing one. We already have ckBTC - BTC twin, on the way is ckETH - ETH twin + ckERC20 - <any>ERC20 twin… - which are twins of tokens from other blockchains. I think it would be much easier to use same logic/code (where relevant…) to create SNS1 twin on the same blockchain/network (ICP) - called DKP, while changing 1:1 ratio to 1:100000000 (for example, ). that would basically mean…

[levi]

For an sns to be able to set the ledger parameters: transfer_fee, token_symbol, token_decimals, etc, the sns-governance canister needs a new proposal action type that can upgrade the ledger with the new parameters. The ledger already supports upgrading most parameters through the post_upgrade arg on the ledger, so the sns-governance can use that to set the parameters. Here is the code: SNS governance proposal action: ManageLedgerParameters by levifeldman · Pull Request #1 · levifeldman/ic · GitHub.

Proposal post for this sns capability:

Proposal: New SNS governance proposal action: ManageLedgerParameters

This change creates a new sns governance proposal action: ManageLedgerParameters. This proposal action lets an sns set the ledger parameters: transfer_fee, and fee_collector. Whereas before this change there was no way for an sns to update these parameters. Here is the code for this feature: SNS governance proposal action: ManageLedgerParameters by levifeldman · Pull Request #1 · levifeldman/ic · GitHub. If the reviews and testing goes good, I plan on making a proposal on the nns to upgrade t…

[infu]

I hope increasing decimals is a one-off thing we can do for DKP, but then it shouldn’t be done ever again. The amount of patching(upgrades) it will require only makes sense now when there aren’t that many things using these tokens. At some point, it will be impossible.

• SNS patch like what @levi has made
• each dex:
  • patch canister memory to increase balances or order amounts
  • patch its trade history and chart data
• ledger:
  • patch user balances, cancel approvals
  • patch transaction history changing transaction values
• patch all stats sites, browsers & data analytics, and whatever memory they have collected
• patch other unknown DeFi contracts & offline trading scripts (arbitrage bots)

[blush]

I don’t quite agree with this improvement. This is DKP applying for privileges. If this precedent is set, it will have a bad impact. Please refer to other methods to remedy it. @plsak

[ishaaqziyan]

Hi @Thyassa
I have a question for the dragginz team.
So, When should we expect the token to land on TIer-1 Exchanges👀

[plsak]

@levi

The ledger already supports upgrading most parameters through the post_upgrade arg on the ledger, so the sns-governance can use that to set the parameters.

Thinking if already has been tested what are (all) possible consequences for holders of such token (liquid/staked/in LP/…) which went though the post_upgrade update process, eventually if such testing can be conducted (real-life scenario rather than dry-run) before it will be applied to SNS1 - considering the SNS1 release troubles and current growth I believe that the community is very sensitive in this matter.

[Thyassa]

Oh it would only be something we do once. I am not even sure that changing the decimals would update on exchanges unless each exchange manually did something either.

It turns out this is a bigger headache than we originally thought. There are a couple of options we can do to get the same outcome. We are just waiting to hear from SNS team if we can take snapshots of all holders at a certain time or not to decide which way option to go ahead with.

We aim to be as transparent as possible and aren’t trying to screw anybody over here.

As soon as we know either way, we will let everyone know.

Sorry…

[Thyassa]

Not until we have sorted out how many DKP/SNS-1 there are.

[infu]

Yeah, I meant that ‘ManageLedgerParameters’ can’t be something that stays in the SNS long-term available for all SNSes. It’s like a self-destruct button. I doubt anyone will mind patching a few things for Dragginz, since it’s pretty much 80+% of IC DeFI volume (post SNS launch) so far.

[ishaaqziyan]

I see.
Look forward to see some major announcements in the near future

[levi]

@infu

• each dex:
• patch canister memory to increase balances or order amounts
• patch its trade history and chart data
• ledger:
• patch user balances, cancel approvals
• patch transaction history changing transaction values

There is no need for most of that.
The ledger stores token amounts as token-quantums. There is no notion of decimals in the ledger canisters’ bookkeeping. The dexs’ frontends need updating and if the dexs have implementations of calculations that depend on the decimals number then those need updating too.

[infu]

Yes, some of that won’t be needed. I got confused because the previous post mentioned an increase in tokens, not just decimal movement. But still, some of that will be needed.
ICPSwap getPool function result:

Notice all of these floats. Makes you wonder if all of them are being calculated on the fly or if some of them are being stored. When these get calculated, do contracts fetch fresh ‘decimals’ from the ledger, or is it cached?
Unless everyone stores prices/rates as two Nats and not one Float, things will need fixing.
A quick search of ‘Float’ in ICDex shows few hits

Actually, there is a better rule of thumb. If a contract uses decimals to calculate something and stores it in memory, or uses another canister that provides such value, that will be something that will cause problems.

[File]

@Thyassa

We have decided to move the decimal place for DKP so that there are a total of 1,000,000,000.000 tokens. Moving the decimal point does not alter anyone’s holdings, it just really changes the way the total is displayed. This should give us enough runway so that when you buy items in game, you will not be dealing with tiny fractions.

@infu

I got confused because the previous post mentioned an increase in tokens, not just decimal movement. But still, some of that will be will be needed.

Many facts indicate that not increasing the supply of SNS1 can maintain the value,price, scarcity and rareness of SNS1, which is quite important for token economics. After increase the Total Supply(or even Total Supply * N), will have a negative impact on coin price, project, community, and more.The is not FUD!
We need to solve the problem without increasing the total supply of SNS1(to maintain the value，price, scarcity and rareness of SNS1),Although the frontend and backend requires some update and annotation!,

[Jabberwocky]

You ever heard of a stock split? That’s exactly what’s going to happen. Nothing will change, you will own the same exact percentage of DKP compared to the total supply and the market cap will be the same. This needs to happen for the in-game functionality of the token. Nobody would be gettinf screwed here it would all be a visual change and the transaction fees will be lower in order to trade these smaller quantities

[Chloros88]

This isn’t an increase in supply this is a decimal change. I suggest you do more research next time before posting your opinion

[infinite]

To avoid misunderstandings and ambiguities and so on, I think the proposal fromm @levi is a better way and explanation to solve one of the problems in SNS1

Proposal: New SNS governance proposal action: ManageLedgerParameters

Current SNS-1 total supply is 999671422000 token-quantums. Canister: Dragginz Ledger - ICP Dashboard click icrc1_total_supply and click call. Current SNS-1 icrc1_decimals = 8, so the frontend shows 9996.71422000 (rounded to 9997) total supply. If the SNS-1 icrc1_decimals changes to = 3, then the total supply will still be 999671422000 token-quantums, but the frontend will show 999671422.000 (rounded to 999671422) total supply.

Proposal: New SNS governance proposal action: ManageLedgerParameters

Thank you very much for your patient and detailed explanation! If your code does not change token-quantums(Real SNS1 Total Supply), so I think parameter icrc1_decimals is feasible for SNS1’s one of problems(As @Thyassa said,you will not be dealing with tiny fractions.) After all,Many facts indicate that after chage the Real Total Supply, will have a negative impact on coin price, project, community, and more. As for the other parameters in your code, as @msumme said, Other stakeholder and …

Proposal: New SNS governance proposal action: ManageLedgerParameters

You are very welcome. 100%. For changing the token_decimals parameter, every frontend out there that accepts a user’s input for an amount of the sns-tokens will need to prepare and then switch to the new decimals parameter at the same time. Being negligent with the token_decimals setting can lead to chaos. @File That sounds like a great plan and path forward. Thank you sir. Thank you @msumme and @File for your feedback on this proposal. Taking both your feedbacks into account, I am now updat…

We should treat this proposal positively, this kind of code contribution from the community is very important(and in the future when facing with increasingly complex situations,collaborations and more, it will become more and more important), we need to learn, try to reduce the dependence on DFINITY( This is what DFINITY should expect to some extent)，so I expect that this proposal will be one of the good start or demonstration of the community contributing code and more

which is not only good for decentralization, but also good for long-term sustainable application, development, innovation, and more!

There may be some difficulties in adopting this proposal, and I hope to pass the proposal after a series of collaborations, preparations, improvements, and more!

[plsak]

Thanks for the explanation @levi @infinite
I’m mentioning below comment which summarizes my worries - for example I can image FE (DEX, Wallet,…) which doesn’t get the parameters dynamically, has separated variables (or hardcoded value) for icrc1_decimals per operation, updates it for reads/displaying and leaves old values for writes/sending - causing discrepancy in SNS1 token-quantums which would be processed.

I mean I’m supportive for any solution which will be chosen, just would like to express need for throughout (ecosystem-wide) testing in case of change to current SNS1 parameters/tokenomics

Proposal: New SNS governance proposal action: ManageLedgerParameters

@levi Thanks for implementing this. This is a really clever solution to the problem of how to change parameters in the ledger, even though ledger doesn’t expose an API directly. We (DFINITY engineers) are discussing this, but I wanted to give a quick thought. The risk in making these changes is not so much internal to the ledger or SNS as it is the ecosystems outside of the SNS. Token symbols, decimals, and names are often widely distributed. What happens everywhere else in the ecosystem wh…

[levi]

@infu My above comment made an assumption about the dexs’ implementations. My mistake. I have no knowledge of the dexs’ implementations or how they calculate their values. Thanks for double checking my comment. I updated my comment above removing assumptions about the dexs’ implementations.

@levi

The ledger stores token amounts as token-quantums. There is no notion of decimals in the ledger canisters’ bookkeeping. The dexs’ frontends need updating and if the dexs have implementations of calculations that depend on the decimals number then those need updating too.