Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating future unminted issuance on a stake-by-stake basis #20

Open
arjunhassard opened this issue Mar 19, 2021 · 1 comment
Open

Comments

@arjunhassard
Copy link
Member

At a given snapshot in time (e.g. right this moment), the future unminted supply can be thought of as having two distinct segments:

(1) A sum of tokens that is currently ‘reserved’ for all active sub-stakes. 

(2) A sum of tokens which is ‘unclaimed’ because no current sub-stakes have an unlock duration stretching enough into the future to reserve the issuance scheduled to be distributed on those future periods.

One can even calculate, for each sub-stake, the sum of tokens reserved for it on each forthcoming period until it unlocks, based on the current snapshot of all other sub-stakes' sizes and unlock dates, and the maximum period-to-period issuance – itself based on the combination of kappa coefficients on relevant future periods, also calculated in this current moment.



It is therefore possible, in theory, to port future, reserved issuance over to a new network/protocol/contract with sub-stake level granularity. In thisscenario, stakers migrate over at their own discretion, bringing their subsidies – all taken from supply segment (1) above.

If each sub-stake initialized on the new network is forced to have the exact same unlock date as it did on the old network, its harder to game. It doesn't matter how many sub-stakes are migrated over, each sub-stake’s individual issuance rate/schedule doesn't change, relative to the old network [1]. Similarly, the issuance rate/schedule of sub-stakes remaining on the old network shouldn’t change, because only the portion of future issuance that was already reserved for the departing staker has gone with them.

Because NuCypher doesn’t allow you to decrease an unlock duration, only extend it, one can make some sort of claim to unminted tokens. Of course, receiving an exact sum calculated today relies on the breakdown of sub-stake size and unlock duration not changing, which is unrealistic. However, if both the old and new networks have very similar rules with respect to the divvying up of tokens on a given period, and both disallow decreasing unlock durations, then the main difference is that the new network doesn't have segment (2) above.

[1] However, once any sub-stake parameters are configured, it could change the issuance rate/schedule. For example, if sub-stake A unlocks 100 days into the future, and sub-stake B in 200 days, then if A decides to prolong, it could eat into sub-stake B's future issuance – depending on the rules. Arguably, one shouldn't be able to touch issuance one didn't bring. However, this means brand new stakers (who buy tokens on the market, for example), would only be able to earn fees on the new network. This isn't definitely terrible, but it would create a big pull factor to the new network, because your future issuance wouldn't be dilutable (unlike in the old network). However, you wouldn't have access to supply segment (2), unless some part of it was also migrated over based on DAO consensus. Whether these incentives balance out, needs more thinking.

A system like this would also allow for a staker to return to the old network unilaterally, bringing their unminted future issuance with them. It reduces the issuance-based dilution pressure on old network non-stakers, while preserving optionality on an individual staker level.

@jMyles
Copy link

jMyles commented Mar 29, 2021

However, this means brand new stakers (who buy tokens on the market, for example), would only be able to earn fees on the new network.

What are the possible ways to reckon the sum of tokens reserved for unstaked NU? As you point out, one of them is to regard it as zero. Are there others?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants