I wonder what would happen if we made the 30 day burn a higher number, and at the same time lowered the royalty on the marketplace?
to be fair the current 10% royalty on the marketplace is not that high…
2 Likes
To summarize an amendment to this proposal from @dda.pro that we discussed on Discord
We propose to keep the flywheel identical to how it is now, with the user having the ability to claim and burn 50% instantly, or create a lock with the duration of their choosing. The duration of the lock determines how many tokens they receive at unlock, with the burns occuring upfront at lock creation, following a 50% to 0% linear decay curve from lock creation to 365D. Only 1Y (or infinite) locks would be able to keep all tokens at lock creation. Any locks created for shorter periods would have tokens immediately burned.
No changes to veDUST power calculations which decay linearly based on the lock timing, except with infinite which they stay 100% until the owner choses to convert to a 365-day time based.
Anything I missed @dda.pro ?
2 Likes
That looks good to me, it’s a more balanced proposal.
1 Like
Yes. Thx @argsarausrex , that’s exactly it.
It’s basically the same idea that’s been floating around here, with one small change: align the instant burn penalty (currently 50%) with the beginning of the linear lock break scale.
Basically a few of us come to the realization that there is no point offering 8% after 1M if I can get 50% right away. Nobody would ever chose that. We are now saying the linear scalar starts at 50%, and goes to 100% after 1Y.
I believe it simplifies things:
- it completely unifies instant burn and lock breaking
- it gets rid of the current issue of paying no penalty if you lock for 30 days
- it gives people a choice to get out whenever they want (linear 50%-100% - 50% right away, 75% at 6M, 100% at 1Y)
1 Like
Estou 100% de acordo com a sugestão do dda, conforme abordamos no chat de governança, parece ser um caminho mais equilibrado, sem necessidade de incrementar algo mais complexo ao protocolo.
E também, não ser uma mudança tão drástica, que possa afujentar futuras baleias.
1 Like
After receiving extensive feedback, these are the invariants of the design I’m promoting in this proposal.
1. Penalty when claiming rewards
The claim-time penalty to decrease linearly across the available lock range:
claim penalty rate = 50% × (MAXTIME − commitment) / (MAXTIME − MINTIME)
This gives:
| Lock/Claim | Penalty |
|---|---|
| Instant claim | 50% |
| MINTIME lock (4 weeks) | 50% |
| Intermediate lock | Proportionally smaller |
| MAXTIME lock (1 year) | 0% |
| Infinite lock | 0% |
The net amount remaining after this penalty is deposited into a new veDUST.
For additions to an existing decaying veDUST, the calculation should use its actual remaining duration. Infinite lock additions receive no claim-time penalty.
The clamp should start at the same rate as the instant claim to prevent any bypass attempt where someone chooses the minimum lock, immediately exits, and, combined with the changes to the early exit penalty shifting to raw duration calculations, receives more than the 50% instant-claim option.
2. Penalty for exiting a lock early
The early-exit percentage should now depend only on the lock’s remaining duration:
exit penalty rate = 75% × remaining duration / MAXTIME
exit penalty amount = locked amount × exit penalty rate
Therefore:
- A newly created MAXTIME lock starts at 75% exit penalty.
- A newly created 6-months lock starts at 37.5% exit penalty.
- A newly created MINTIME lock starts at 6.25% exit penalty.
- The percentage decreases as its remaining duration decreases.
- An expired lock has no exit penalty.
- An infinite lock has a 75% exit penalty.
The percentage calculation does not depend on the amount locked or on effective start of a lock, but only to its remaining duration.
Important
The maximum early exit penalty should stay above 50% as a hard invariant to avoid the attack vector of a user locking their DUST indefinitely, claiming revenue or voting on a proposal at maximum power, followed by an early exit with the same penalty (50%) as if they had never locked to vote or receive the revenue. Naturally, creating a lock and benefiting from its perks only to exit later should incur a greater penalty than locking for a shorter duration to begin with or choosing the instant claim.
Minimum-lock example
For a claim of 1,000 DUST into a four-week lock:
- The claim-time penalty is 500 DUST.
- The remaining 500 DUST enters the lock.
- An immediate exit charges approximately:
500 × 75% × 28 / 365 = ~28.77 DUST - The user receives approximately 471.23 DUST.
Instant claim penalty will always be a better deal than locking only to early exit later.
The combination of the haircut on the claim itself and the new early exit penalty, which accounts only for the current duration against the maximum time, applies only a small early exit penalty to a position that has already received a haircut by being locked for a month.
✦ The claim clamp and the early exit penalty should be designed in relation to each other. Any misconfiguration or design oversight in either can open opportunities for a user to game the system, exit for a lower penalty, or receive benefits from a lock that are disproportionate to the penalty they pay afterward for exiting.
3 Likes
Only question is – why would anyone pick a 4 week lock to burn the same number of tokens as an instant claim? To gain some veDUST revenue? Should the decay start immediately instead of at 4 weeks?
I’m good with this framework and we should vote on it soon.
They receive some voting power and some revenue every week in exchange for a start of ~6.25% penalty that decays to zero. It’s a small benefit, for a small penalty if you choose to actually create the lock and then exit before the full duration.
It’s important to vote on it soon and move forward, but it’s just as important to make sure the design is not rushed. There are attack vectors to consider and this is a fundamental change to the tokenomics. We can’t commit to any new tokenomics design before we at least have enough eyes on it for review.
1 Like
As Argsaurorex mentioned, having a minimum 4-week lock-up period that carries the same penalty as an instant withdrawal doesn’t seem to make much sense; it would likely be an option rarely used, given that the voting power and proportional rewards associated with a minimum lock-up are quite small.
If the stake were proportional from the moment of locking, one would receive 54.17% instead of 50%.
So, receiving an extra 4.17% for waiting a month might make more sense, in my opinion, than receiving 0%…
I’m not sure if the voting power and the additional rewards for a one-month lock-up constitute a benefit that justifies applying the same penalty to both immediate withdrawal and a 4-week lock-up…
But overall, I agree with the structure and objective of the proposal.
Yes, same question/comment as @argsarausrex and @shadow_hodl . Everything makes perfect sense EXCEPT for this one point about the 4-week lock getting you the exact same % as the instant lock.
I read your response to @argsarausrex, and I still think it complicates things for no meaningful gain.
Also keep in mind that if long time users of neverland are confused, I can only imagine the number of times @hypermassiv will have to explain this over and over again to new users on the #general channel.
I think there is much to gain if we keep it as simple as possible.
The 4-week lock detail is a minor thing for me — I don’t think any users will pick it if the burn is 50% or 46%. The fact it will still exists gives the aura of flexibility. If the reason we are keeping this 50% burn structure at 4 weeks is due to code simplicity or the possibility of manipulation, I have no problem with it.
The exit penalties need to be clearly communicated in the UI at lock creation along with an acknowledgement that creating a lock less than 1Y will result in an immediate burn. Perhaps the user should check a box stating they understand the terms (both how much DUST will be locked and that breaking a lock early will result in a penalty/loss of tokens).
Fair enough. I wouldn’t derail this RFC just for this. Small detail in the grand scheme of things.
exit penalty rate = 75% × remaining duration / MAXTIME
I’m not sure the penalty should be based on “remaining duration”. In my mind, we should always try to nudge users for longer duration locks. All penalties should be structured such that the longer you lock for, the less penalty you receive.
Correct me if I’m misunderstanding, but consider this example:
You said a 1 month lock of 1,000 DUST that immediately exits early would receive ~471 DUST.
Now consider a 6 month lock of 1,000 DUST where the owner waits a full month and then exits early. Following the formula, they would receive:
500 * 0.75 * ~150 / 365= ~154 DUST
By only locking for 1 month and exiting instantly, they receive over 3x more DUST than somebody who locks for 6 months, waits 4-5 weeks, and then decides to exit early. This pushes behavior in the wrong direction.
Am I misunderstanding the formula?
To put it more simply, the longer you wait, the more DUST you should receive, regardless of which lock duration you chose.
1 Like
In re-reading through the formula again, I see the 154 DUST I calculated was the penalty amount, not the received amount. But that still means they would only receive ~350 DUST.
So a 1 month lock that is exited near-instantly receives 471 DUST.
But a 6 month lock where the user waits 4-5 weeks and then exits early only receives ~350 DUST.
This is not in the spirit of what was proposed that rewards appreciate linearly with the amount of time actually locked, regardless of the lock’s initial duration.
Would you consider from 40% for MINTIME to 0% at MAXTIME instead? Would a 10% increase from the instant claim make more sense?
Consider that under this setup, users are already receiving a penalty before they even consider the early exit. The early exit is an additional penalty for breaking their commitment.
If you lock for a month and you instantly early exit.
If you lock for 6 months, you don’t get penalized by 50% to receive 500 DUST, but by 25% to receive 750 DUST. By exiting early after a month, at the 5-month point of the 1-year lock, you’d pay an additional 31.25% early exit penalty, bringing the final amount to 515.62 DUST.
To break it down:
Claim: 1000 - (1000 * 25%[1]) = 750 DUST
Early Exit on 5th month to maturity: 750 - (750 * 31.25%[2]) = 515.63 DUST
This is problematic at first glance, the user locking for 6 months breaking their lock after a month shouldn’t receive more DUST than the user who creates a lock for 1 month and let it expire. I’ll write a few scripts to ensure fairness and circle back with the result.
The user gets a lock of 750 DUST for 6 months, the 25% is the penalty on claim, given the penalty starts from 50% as the minimum and decaying 0% for maximum time locks. ↩︎
The percentage of penalty the user is paying under this early exit flat model for the 5th month if the penalty is starting at 75% decaying to 0%. ↩︎
This is probably because the penalty from 0 to 4 weeks remain the same at 50% but the early exit decays to zero linearly and maybe this is the solution to both issues. To turn the 50% at the zero days, let it decay up to the month for 46.16%. But then again we introduce another problem with the instant claim vs lock for a month and potentially across the year there are more marks that the relation to the claim clamp with the early exit it makes it even more beneficial.
Then we’d have for the one month user:
Claim: 1000 - (1000 * 46.16%) = 538.4 DUST
Instant exit early: 538.4 - (538.4 * 6.25%) = 504.75 DUST
In this case it makes more sense to lock for a month and instantly early exit, which is another gamification of the system.
I would just eliminate MINTIME from the equation. Or use MINTIME=0 if you will (which would be the same as instead claim)
If you really want a MINTIME (so the UI maybe exposes minimum lock time), the math should just be similar to any intermediate lock.
Yes, this is what I do in the reply just above. The problem is that there are still magic durations that yield more voting power and more revenue, while waiting the same amount of time as the 1-month lock earns the user more DUST. More revenue and more voting power should be penalized if the user wishes to exit, not rewarded.
1 Like