Implement VotingStreakMultiplier #129
Conversation
|
@bagelface @RonTuretzky with my latest commit here, the build is compiling without errors/warnings and the tests all pass. Can you advise on next steps? |
| /// @notice This is a no-op function that exists solely to implement the IMultiplier interface | ||
| /// @dev This function does nothing and always returns, as the actual multiplier update logic | ||
| /// is handled by the parameterless updateMultiplyingFactor() function | ||
| /// @param _newMultiplyingFactor Unused parameter | ||
| function updateMultiplyingFactor(uint256 _newMultiplyingFactor) external pure override { | ||
| return; | ||
| } |
There was a problem hiding this comment.
I think we can remove this one from this contract and the upstream interfaces as well if we're not using it
There was a problem hiding this comment.
i thought this was a function to be called externally in case we ever decide to update the multiplier value. like, if we start out thinking discord membership should give 1.05x but then later 1.1x or something, would this be the way to make that update?
There was a problem hiding this comment.
i confused myself a bit but that's my thinking for why we need to keep it in the upstream interfaces, since those are implemented by other kinds of multipliers. and so my understanding is it has to be implemented here
There was a problem hiding this comment.
I think basically you added one that was meant to be for this pr , then we figured out we need that one to accept address not an int, and now we have the previous one that's still there that we need to remove , no?
There was a problem hiding this comment.
I still don't see where the int version of updateMultiplyingFactor is being used so bumping this for its removal
There was a problem hiding this comment.
@RonTuretzky the idea seems to be that it will be used by NFTMultiplier here
There was a problem hiding this comment.
why would it not just be calculated and called internally? it being supplied implies that some outside contract is doing the logic to determine the multiplier update, but this is an anti pattern to the system design, as all multiplier logic is meant to be self contained within the multiplier contracts themselves
When a vote is cast (via the YieldDistributor), the VotingStreakMultiplier updates it's state variables tracking user's multiplier value and validity.
When this contract is deployed, the front end can call
getMultiplyingFactorfor the user's current multiplier.