-
Notifications
You must be signed in to change notification settings - Fork 32
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
staker v2: track historical total staked and historical seconds/staked #61
Comments
@moodysalem Approach planI think that all the changes should happen within staker.cairo or in other contract that is listening to staker events. I see the task as the following:
I would use a: pub mod Staker {
#[storage]
struct Storage {
// ....
staked_total: Map<ContractAddress, u128>
staked_per_second_cumulative_amount: Map<ContractAddress, Vec<(Timestamp, CumulativeStakedAmount)>>
}
// ....
} fields. Every time
1 additional method will be added: fn get_staked_per_second_cumulative_amount(addr: ContractAddress, ts: u128) -> CumulativeStakedAmount This method will find log record before
else
resulting CumulativeStakedAmount = CurrentStakedAmount * (ts - log_before.Timestamp) Simplification at the cost of storageThis scheme can be simplified by storing total_amount as vector as well.
@moodysalem Let me know what you think and which way you prefer. I also need guidance on how to initialise staking amounts values. |
Not necessary, since the old one is not upgradeable we do not need to do any migrations. This would be a new deployment addressed in the governor that supports multiple stakers
Staked total that we care about is the overall total staked across all addresses, not per address, and we probably want to use an accumulator also so we can get the total voting weight over a period
Again not per address, this is at a global level, we just need historical to be able to compute the difference over any two timestamps |
we should keep track of snapshots of total staked (u64 + u128) and historical seconds per total staked
we should also allow computing the seconds per total staked at any historical point
this will allow for on-chain distribution of tokens to stakers. an external contract can take the tokens, stake them, and then when you unstake the tokens it can measure your number of stake-seconds (i.e. seconds where you have 100% stake) and reward you accordingly
keeping track of total staked is also nice because we can build a feature in the governance where if a proposal vote cannot fail it can be executed earl (technically we would need to know the total voting weight when voting started, not the total staked, which can be higher than total staked at the time the proposal was created)
we should probably make the staker upgradeable also
The text was updated successfully, but these errors were encountered: