You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is my suggested structure for the smart contract based on the aspects we discussed.
Instead of storing each lock up per supporter per initiative, we can simplify by simply storing the total amount of weight per initiative. We only need to calculate decay immediately before adding more weight. If the weight ever surpasses the threshold, it can be considered a success. Then we also store a list of each supporters' lockup amounts so we know when they can be withdrawn.
Overview of what to update in the code:
Add top-level variable interval which specifies the inteval length (e.g. 1 day), and helper functions to calculate how many intervals have passed since a certain point of time.
Convert locks to a mapping(uint256 => LockInfo) to assign one LockInfo to each initiative, and change LockInfo to only include the total current weight and the timestamp of the last time the weight was updated.
Any time supportInitiative is called, first update the current total weight of the initiative based on how many intervals have passed since it was last updated, then add the new weight to the total. Add the token amount, expiration of the lockup, and the initiative id to the list of lockups this supporter has submited.
When a supporter wants to withdraw, check their list of lockups for all entries for which either the lockup expiration has passed, or for which the associated initiative has been accepted.
Next steps:
Add a bool variable to record if an initative has ever passed the threshold. Then allow anyone (not just owner) to accept any initiative that has passed the threshold at some point in the past (even if decay has caused it to drop below since then)
The text was updated successfully, but these errors were encountered:
For each initiative, we will record a map of supporters, and for each supporter we will store a map of their contributions (locks).
To caclulate total weight, we step through each supporter and step through each lock, pass it through the function for finding the current weight, and add that to the grand total. For V1, total weight is only calculated for display in the UI and is not referenced in any on-chain transaction (in the future, we can consider calculating this every time weight is added to see if the threshold is met -- need to test if this will be too costly)
Here is my suggested structure for the smart contract based on the aspects we discussed.
Instead of storing each lock up per supporter per initiative, we can simplify by simply storing the total amount of weight per initiative. We only need to calculate decay immediately before adding more weight. If the weight ever surpasses the threshold, it can be considered a success. Then we also store a list of each supporters' lockup amounts so we know when they can be withdrawn.
Overview of what to update in the code:
Add top-level variable
interval
which specifies the inteval length (e.g. 1 day), and helper functions to calculate how many intervals have passed since a certain point of time.Convert
locks
to amapping(uint256 => LockInfo)
to assign oneLockInfo
to each initiative, and changeLockInfo
to only include the total current weight and the timestamp of the last time the weight was updated.Any time
supportInitiative
is called, first update the current total weight of the initiative based on how many intervals have passed since it was last updated, then add the new weight to the total. Add the token amount, expiration of the lockup, and the initiative id to the list of lockups this supporter has submited.When a supporter wants to withdraw, check their list of lockups for all entries for which either the lockup expiration has passed, or for which the associated initiative has been accepted.
Next steps:
The text was updated successfully, but these errors were encountered: