-
Notifications
You must be signed in to change notification settings - Fork 608
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
Turnpike/f1 fee distribution #543
Turnpike/f1 fee distribution #543
Conversation
No need to distribute using stake ratio. there is always one current_reward to one gauge
fix wrong range for unlocking lock candidate check accumulate store : accumulated sum of total locks unlocking accumulate store : acculated sum of unlocking locks total stake for distribution = accumulated value of locks - accumulated value of unqualfied unlocking
current reward historical reward period-lock-reward
Codecov Report
@@ Coverage Diff @@
## main #543 +/- ##
==========================================
- Coverage 20.44% 18.93% -1.51%
==========================================
Files 163 164 +1
Lines 23186 26806 +3620
==========================================
+ Hits 4741 5077 +336
- Misses 17668 20885 +3217
- Partials 777 844 +67
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The main logic of the implementation of the F1 distribution looks pretty solid
x/incentives/types/keys.go
Outdated
KeyHistoricalReward = []byte{0x11} // TODO : Confirm this key name/value | ||
|
||
// KeyHistoricalReward defines key for storing historical reward | ||
KeyHistoricalRewardRef = []byte{0x12} // TODO : Confirm this key name/value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from that I think I need explanation on why this key has Ref behind, the other Key names look ligit to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is explanation enough? or do you prefer to rename the key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the key name should be fine!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just that I'm still confused how KeyHistoricalReward and KeyHistoricalRewardsRef are different / how they are related, connected to each other
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HistoricalReward can be found with denom, duration, and "period" which is a range of time that total stakes have not changed
But when a lock is "unlocking" or gauge becomes "finished" state, period can not be referred because
- "unlocking lock" should not be rewarded (or excluded from recent periods) if remaining locked duration is smaller than gauge's duration
- f1 distribute() will not be called if no gauge for denom&duration exist.
KeyHistoricalRewardsRef is used to get exact "period" by epoch number
- change lockable_durations->lockable_duration - remove for loop which only access to first element
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Second round of reviews
x/incentives/types/keys.go
Outdated
KeyHistoricalReward = []byte{0x11} // TODO : Confirm this key name/value | ||
|
||
// KeyHistoricalReward defines key for storing historical reward | ||
KeyHistoricalRewardRef = []byte{0x12} // TODO : Confirm this key name/value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the key name should be fine!
x/incentives/types/keys.go
Outdated
KeyHistoricalReward = []byte{0x11} // TODO : Confirm this key name/value | ||
|
||
// KeyHistoricalReward defines key for storing historical reward | ||
KeyHistoricalRewardRef = []byte{0x12} // TODO : Confirm this key name/value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just that I'm still confused how KeyHistoricalReward and KeyHistoricalRewardsRef are different / how they are related, connected to each other
this comit also contains - unify key combination for current_reward and historical reward - remove unused key
Closing in favor of #750 |
Closes: #XXX
Description
Following changes are made in this PR:
Period
CurrentReward
HistoricalReward
new period lock with requested coin amount is generated and begin unlock
For contributor use:
docs/
) or specification (x/<module>/spec/
)Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorer