-
Notifications
You must be signed in to change notification settings - Fork 3
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
Voting Multipliers #100
base: dev
Are you sure you want to change the base?
Voting Multipliers #100
Conversation
…onfig with tests Changes to be committed:
3a0c818
to
daeb1ce
Compare
src/YieldDistributor.sol
Outdated
uint256 breadVotingPower = this.getVotingPowerForPeriod(BREAD, lastCycleStart, lastClaimedBlockNumber, _account); | ||
uint256 butteredBreadVotingPower = | ||
this.getVotingPowerForPeriod(BUTTERED_BREAD, lastCycleStart, lastClaimedBlockNumber, _account); | ||
return (breadVotingPower + butteredBreadVotingPower) * multiplier / PRECISION; |
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.
Ok I see what's going on. TBH I don't think PRECISION
should be shared here since it's being used in two different calculations. I think the getTotalMultipliers
function should probably return a tuple like (multiplier, multiplier_precision)
and that should be used here. Ignore my previous comment about using "1 instead of 1e18"
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.
so you're saying each multiplier should have it's own precision potentially? can't we just assume they are all 1e18?
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 we should return a single number formatted to 1e18, to avoid confusion and enforce standardization
@@ -20,7 +21,7 @@ import {IYieldDistributor} from "src/interfaces/IYieldDistributor.sol"; | |||
* @custom:coauthor kassandra.eth | |||
* @custom:coauthor theblockchainsocialist.eth | |||
*/ | |||
contract YieldDistributor is IYieldDistributor, OwnableUpgradeable { | |||
contract YieldDistributor is IYieldDistributor, OwnableUpgradeable, VotingMultipliers { |
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.
TBH I'm a little dubious of the upgrade safety here. It would probably be best to implement VotingMultipliers to use ERC7201 storage layouts (like they do with OwnableUpgradeable) to avoid storage layout collisions. It seems complicated but it's actually a pretty trivial one time calculation and some boilerplate code for accessing storage variables.
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 was thinking we should just deploy a new proxy for this version, and use the setter on the bread contract, as this would also help us resolve #96
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 there a foreseeable problem deploying as a new proxy, thus changing the address? if there is not, i would prefer we deploy fresh, therefore do not need to worry about upgrade-safety, and not over-complicated things. but again, this is assuming there is no major problem with changing the address.
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.
Deploying a new contract is definitely the move in this instance but I mean in future instances where we maybe want to make some changes to the VotingMultipliers.sol
contract. Namespacing the storage layouts ensure YieldDistributor
and VotingMultipliers
are using their own storage locations that won't clash, so if we want to add a variable to one or the other, we can do so safely. I can make a quick branch so show what it would look like.
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 also think there is a strong case to be made for VotingMultipliers
to be its own contract.
Deprioritizing for now |
This reverts commit de0309d.
…h voting function to prevent on-chain iteriations
/// @notice Calculates the total multiplier for a given _user | ||
/// @param _user The address of the _user | ||
/// @return The total multiplier value for the _user | ||
function getTotalMultipliers(address _user) public view returns (uint256) { |
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.
Assuming we keeping this as a quality of life function so we can avoid the double query getValidMultiplierIndexes(address)
-> getTotalMultipliers(address, uint256[])
? If so, I think this should be moved to be closer to getTotalMultipliers(address, uint256[])
so the overload is obvious. Maybe word adding a note in the natspec comments with a @dev tag
/// @notice Array of allowlisted multiplier contracts | ||
IMultiplier[] public allowlistedMultipliers; | ||
|
||
/// @notice Calculates the total multiplier for a given _user |
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.
Drop the underscore form _user
when referring to it in the comments to be consistent with other comments.
/// @notice Returns the multiplier at the specified index in the allowlist | ||
/// @param index The index of the multiplier in the allowlist | ||
/// @return The multiplier contract at the specified index | ||
|
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.
remove line break
error InvalidMultiplierIndex(); | ||
/// @notice Emitted when a new multiplier is added to the allowlist | ||
/// @param multiplier The address of the added multiplier | ||
|
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.
remove line break
|
||
/// @title Cross-Chain Proveable Multiplier Interface | ||
/// @notice Interface for contracts that provide a cross-chain proveable multiplying factor | ||
|
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.
remove line break
/// @title Dynamic NFT Multiplier Interface | ||
/// @notice Interface for contracts that provide a dynamic multiplying factor for _users based on NFT ownership | ||
/// @dev Extends the INFTMultiplier interface with dynamic multiplier functionality | ||
|
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.
remove line break
import {IProveableMultiplier} from "src/interfaces/multipliers/IProveableMultiplier.sol"; | ||
/// @title On-Chain Proveable Multiplier Interface | ||
/// @notice Interface for contracts that provide an on-chain proveable multiplying factor | ||
|
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.
remove line break
import {IDynamicNFTMultiplier} from "src/interfaces/multipliers/IDynamicNFTMultiplier.sol"; | ||
/// @title Proveable Multiplier Interface | ||
/// @notice Interface for contracts that provide a proveable multiplying factor based on _user activities | ||
|
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.
remove line break
*/ | ||
function castVoteWithMultipliers(uint256[] calldata _points, uint256[] calldata _multiplierIndices) public { | ||
uint256 _currentVotingPower = getCurrentVotingPower(msg.sender); | ||
if (_currentVotingPower < minRequiredVotingPower) revert BelowMinRequiredVotingPower(); |
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.
Are we sure we want to check this requirement before multipliers are applied??
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.
trueeeee
@@ -110,17 +112,20 @@ contract YieldDistributor is IYieldDistributor, OwnableUpgradeable { | |||
* @return uint256 The voting power of the user | |||
*/ | |||
function getCurrentVotingPower(address _account) public view returns (uint256) { | |||
return this.getVotingPowerForPeriod(BREAD, previousCycleStartingBlock, lastClaimedBlockNumber, _account) | |||
+ this.getVotingPowerForPeriod(BUTTERED_BREAD, previousCycleStartingBlock, lastClaimedBlockNumber, _account); | |||
uint256 lastCycleStart = lastClaimedBlockNumber - cycleLength; |
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.
Just realizing this will be invalid if cycleLength
is changed. We need a "lastCycleLength" variable. Maybe it'd be good to create a Cycle
struct?
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.
We should open a separate issue for this ... also mark it as bug so we don't upgrade changes without considering this...
#71
This is not upgrade-safe due to new variables introduced in an inherited class. Suggesting to couple this PR with #96 and create a brand new YieldDistributor