Symbol Tokenomics Update

Announcements
#1

Discussion - Original Tokenomics Proposal Needs Updating

Summary
In December 2019, a community vote approved the Final Tokenomics Proposal. This was written with a few assumptions and the best information known at the time.

https://forum.nem.io/t/catapult-migration-and-tokenomics-proposal-for-nem-community-poi-vote/24033

Since that time, a few things have changed which make it appropriate to revisit the proposal - the basic model will remain the same, but there are a few factors to update:

Finality has now been added, which includes 5% of total block rewards to be paid to Voting nodes
Other fees sinks should also be included (eg Namespace and Mosiac rental fees)
Configuration has also changed the block time from 15 secs to 30 secs on Testnet as part of config changes for finality, this needs to be worked in

A launch date assumption was used in the modelling of Feb 2020, this needs to be changed which impacts:

  • Starting supply
  • Rate of inflation
  • SuperNode rewards token usage from Feb 2020 to Jan 2021

This post is intended to act as the start of a discussion to understand what people’s preferences are in how we approach these changes, whether they are major enough to require another vote or are similar enough that we should consider them an update etc.

Update Model to Correct Launch Date
The new scheduled launch date is 14th January 2021 which potentially affects the Tokenomics in the following ways :

Rate of Supply Inflation: Was set to match BTC’s supply inflation rate with quarterly instead of 4 yearly step downs, to maintain this we now need to adjust the rate of inflation to be further along the inflation curve.
Starting Supply: To use the inflation rate above, the starting supply would need to be higher than previously planned, to ensure we match the total supply distributed at that point on the graph
SuperNode Programme: The original model used the current NEM NIS1 SuperNode balance as at Feb as the start point, moving this assumption to Jan 2021 means we need to update the balance left and check how much (if any) is required from Core funds to ensure the programme runs for 6 years on Symbol as planned, or reduce length of it.
Rate of Supply Inflation & Starting Supply
The inflation function in Symbol is being used to increase total supply via block rewards to node operators and delegated harvesters. This incentivises node hosting, staking and therefore contributes to network stability and security.

The original proposal was based on launching prior to the most recent BTC halving, as a result some of the early block rewards were higher in order to bring the supply inflation curves into synchronisation. The model also (due to maths functions) paid out slightly more in the first 2 years and slightly less in the last 2 years, relative to BTC, in order to match the distribution curve. Anyone interested in the model and graphs can see them in the original proposal. The revised launch is now several months after the BTC halving (May 2020), this has two impacts:

The need to “catch up” to the BTC halving is no longer a requirement and could be removed or altered
The distributions that should have happened between the halving and now could be added to the early years block rewards or we could just start with the correct start supply from the curve and adjust future inflation to match it.

The decision to change these or not, alters block rewards that are available for incentivisation via block rewards. By way of example the numbers are approximately as below

Total Block Rewards XYM Produced
Original Launch Date on Tokenomics Proposal = 1,167,024,439
New Launch Date on existing Tokenmics Proposal = 999,977,380
Difference In Inflation between original and new = (167,047,060)

see Config File New Sheet for details

Start Supply and Supply Inflation (Node Rewards)
The original proposal smoothed the BTC halving steps from 4 years to quarterly reductions. This allowed a relatively high inflation rate during year 1 and year 2. Joining the profile later reduces
the incentives to node operators. The figures below illustrate the Total % supply paid out in Block Rewards for the first 2 years (including stub date)

Original Launch Date Yr1 + Yr2 Total Block Rewards as % of Final Supply = 4.16% (374,724,359 XYM)

New Launch Date Yr1 + Yr2 Total Block Rewards as % of Final Supply = 3.39% (305,287,320 XYM)

There appear to be the following approaches we could adopt in response to this, they are essentially two options, but one has multiple sub-options:

Stick to the Plan: Follow the currently approved tokenomics plan as a valid incentive structure for the next 100+ years and accept that we start ~9 months behind the BTC inflation curve and stay behind it until we reach max supply.

Adjust the start supply: Follow the current tokenomics approach but assume that the planned inflation has already occurred - set max supply to what it would have been in the original plan, this requires allocation of the ~167m tokens that were not paid out in block rewards between May and launch. There are three ideas below (B1, B2, B3).

Option A: No change but start tokenomics 10 months later
Adopt the original tokenomics proposal but move the start date to Jan 2021. This would leave incentives unchanged from the original proposal. The block rewards configuration file produced initially would be replicated with an adjustment for block times. The Net effect would be to push our supply schedule behind the BTC halvenings possibly reducing marketing value.

Option B.1 Join the planned curve, add 167m tokens of extra block rewards in first year.
Adopt the original Tokenomics proposal with the same start supply, but increase the early block rewards for next 12 months to catch up with the curve in the proposal. This will give higher inflation and rewards for the first year. However this would also create additional supply inflation and there is always some risk of liquidation etc impacting sell volume.

Option B.2: Join the planned curve, allocate 167m tokens less from Core Funds
Adopt the original Tokenomics proposal and sync with the reduced Jan 2021 Block Reward. Accept a lower inflation rate and therefore a reduced Node Incentive. Essentially Core would optin more of the core funds which would remain as core funds. Initial Supply would be higher. At the margin this may reduce the number of nodes at the outset particularly as Staking Returns in other POS Blockchain Protocols as well as Ethereum Defi tend to be higher.

Option B.3 - Join the planned curve, allocate the 167m to SuperNode Fund
Increase the total start supply and allocate the additional ~167m XYM to the supernode fund, this would then either extend the duration or increase the early payouts via the existing layer 2 solution. The SuperNode payments are not shared by non-supernodes explicitly so benefit is less democratised, however it may be that the risk of liquidation is lower with supernode holders generally, it may not be.

This would essentially mean Core would opt in a bit more of the existing NEM NIS1 core funds and then allocate them to the supernode fund for NGL to distribute, rather than excluding them from total start supply

Finality Changes & Other Sink Addresses
At the time the Tokenomics Models were created, Finality had not been fully implemented. Additionally an opportunity was missed in the models to make use of sink addresses in the config files for example for namespace and mosaic network fees.

Finality Changes
The voting approach used in finality is such that 5% of total block rewards are retained in a “sink” address, to be paid to Voting nodes via a layer 2 solution. To be a voting node the node must be a full supernode (3m+ tokens, Peer and API node).

This 5% therefore needs to be reduced from the modelling for non full supernodes and needs to be added to supernode returns. It means that the modelled returns from each type of node will alter slightly.

Other Sink Addresses
The configuration file allows, similarly to the Voting sink address, the fees for things like namespace and mosaic rental to be sent to a sink address. This also exists on NEM NIS1.

The current modelling ignored these fees and it is very difficult to estimate what kind of volumes they will entail. However, it is possible for example to divert these into the below (or something else):

  • SuperNode fund (sub-optimal because it will be hard to retire in 6 years if continually topped up)
  • Voting fund sink address as above to top up the voting rewards ongoing
  • NEM Hub
  • Returns to Core Funds
  • Burn account (reduce total supply)
  • Something else

None of these is a right or wrong answer, they are all personal preferences. The more logical ones from an NGL perspective appear to be either the Voting Fund, NEM Hub or Core Funds. However we are interested in the community’s opinion on this

Conclusion
There is a lot of information in this text, because there is a lot of detail behind the subject, it boils down really to:
Does the Community want to go with Option A “NO CHANGE TO THE TOKENOMICS PROPOSAL / INCENTIVES BUT MOVE THE START DATE 10 MONTHS FORWARD” ?
Finality changes to be added to update the models, are there any comments on this?
What is your preference on the Other Sink Address fund usage?

7 Likes
[PoI Vote Open] Symbol Tokenomics - Launch Date Impacts
[PoI Vote Open] Symbol Tokenomics - Network Fee Usage
Core team wallet transfers
#2

Option A
Optionaly, go even a little further: Increase initial rewards during the first year a little.
Fund it by limitting the duration in time. 30 to 50 years would already be very ambitious. 100 years is unnecessary long.

1 Like
#3

The original proposal used a non linear regression which pushed the bulk of the rewards into the earlier years (to mimic the BTC halvening every 4 years). The table below gives an illustration of outstanding supply over time. The result is that block rewards start high and taper off significantly.

					Total Supply Outstanding in the form of block rewards

After 4y 6.25%
After 8y 3.125%
After 12y 1.5625%
After 16y 0.78125%
After 20y 0.390625%

2 Likes
#4

I would prefer Option A. My preference on the “other sink address” would be either voting fund or core funds.

I have yet to read more about finality to be able to join that discussion

1 Like
#5

I’d want to point at:

The voting approach used in finality is such that 5% of total block rewards are retained in a “sink” address

Is it possible to make this more distributed? Because from what I get here, it’s that voting payouts would need to be implemented the same as the NIS supernode payouts, which is suboptimal.

Currently, the sink address is basically managed by whom sets up the network. We have experienced with NIS the “non-usage” of sink funds and maybe should try to avoid doing the same here.

Given a planned distribution of said voting funds, I would consider Option B1 and B2.

Note that with 5% block rewards sinked for voters, supernode owners have another way to get rewards - as such, I am not voting against SNs getting the parts of this, I am voting against a manually paid out voters fund because of the cumbersome process and centralization involved in such processes.

Also, I want to question Option A: How is it possible that inflation rates can be left the same, if there is 5% of block rewards awarded to voters (sink) ?

Thank you for opening this topic :+1:

5 Likes
#6

Option A would be preferrable

1 Like
#7

The question is: Is that really important point to have the same inflation as BTC at the same time? Because I am not sure if that is really that important for marketing. Maybe it is enought that Symbol has same inflation rate (smoothed) as BTC but not at the same moment.

So, I think option A is good. Also as @gevs stated, could we have more decentralised solution for finality voters pay (5% of block fees)? I do not like the sink address at all. Are we able to do it more automatically without human interaction?

1 Like
#8

Option A would be good.
There is no need to worry, because even if the marketing value goes down there would be fairly minor or no impact at all. BTC is BTC, XYM is XYM.

3 Likes
#9

I think the mosaic and namespace fees should go to voting nodes. It helps for them to be slightly more sustainable.

I do also agree that a centralized and manually operated sink fund is not ideal.

For me, it would be neat to look at some kind of 2nd or 1.5 layer trustless payout solution, if even such a thing is possible. Of course, the best would be figuring out how voting nodes could be a part of consensus like how running a node has been made trustlessly rewarded. As far as I’m concerned, this can’t be done at launch, but if some efforts could be put into making it more trustless over the next couple of years, I think that is realistic.

2 Likes
#10

Let’s vote with the NEM voting feature.

3 Likes
#11

i agree

#12

Rounding Up Points made :

There is broad agreement that this approach is suboptimal. To recap the 5% of block rewards are generated as a result of the finalization gadget layered on top of PoS+. Future development on finalization may bring improvements however at this point we need to work with the code we have at launch. The CTO has the remit to explore options in this area. During the work on finalization there were broadly two paths. The chosen path gave us a predictable outcome at the expense of working with subsets of nodes. A more ambitious path may be possible with future research.

Also, I want to question Option A: How is it possible that inflation rates can be left the same, if there is 5% of block rewards awarded to voters (sink) ?

Whilst the inflation on the network will remain unchanged the distribution of incentives for Supernodes, Nodes and Delegated Harvesters will change.

Other Sink Addresses
The configuration file allows, similarly to the Voting sink address, the fees for things like namespace and mosaic rental to be sent to a sink address. This also exists on NEM NIS1.

It has been pointed out by @gevs that on NIS1 we have experienced “non-usage”. A decision needs to be made therefore following @GodTanu @Stinghe_Dorian we propose to hold a Vote.

4 Likes
#13

Just an update on this one, the changes needed for the voting module to work on Nano wallet have been made and are going through final testing, a separate release note will be posted when it has been fixed.

We will try and get the vote for this up early next week assuming the above all works ok.

8 Likes
#14

Hi @Iain_Wilson

As regards to Network Fee Usage PoI vote announcement, have you considered an option of simply adding the fees to a block where the transaction occurs as Bitcoin or Ethereum do?

For me, that is the most sensible option.

2 Likes
#15

Currently with Symbol you have a Transaction FEE accruing to a block harvester and a Rental FEE accruing to a Network Sink Address. If you changed this setup in the future you would have to consider whether it is correct that a Rental Fee should accrue to the Block Harvester or whether they belonged to the wider network. On the surface it seems likely that this change would require a change in the code base which doesn’t rule it out on a future upgrade but does preclude it from the current mainnet version.

2 Likes
#16

Thanks for the explanation.
As all the proposed for the vote options are layer2 solutions that will be managed manually, I think that in the same way, there can be a solution to accrue Rental Fee to the Block Harvester.

1 Like
#17

Not for launch it cant (no time to implement and/or test reliably). The other options exist for day 1 already, this is new. The contribution needed to be brought up before the vote was called so it could be decided, it came up 1 day after unfortunately.

The thread was started 27 days ago and 10d ago said it was going to a vote.

The vote is binding and the contribution came after it started so we will implement what is voted as stated

Post launch it can be revisited but its not an option prelaunch without additional delay.

2 Likes
#18

There is an additional practical reason for separation. We expressed namespaces as a scare resource which accrued a network rental fee. If these fees were rolled into a transaction fee an actor who was about to harvest a block could potentially push a huge amount of namespaces into that block and claim for free. Hence a sink address always imposes a cost onto the user.

3 Likes