Governed Lottery Hook #97
Conversation
|
@harpreettrader is attempting to deploy a commit to the Matt Pereira's projects Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
onRegister function is not present in this hook
| } | ||
|
|
||
| // Create a new governance proposal | ||
| function createProposal( |
There was a problem hiding this comment.
So in this design, the owner can propose multiple changes, then choose which one(s) to implement. With 5 proposals, if 3 were approved, the owner could alternate between all the approved ones.
If only the owner can do this, consider one proposal at a time (perhaps with a variable deadline, constrained by a hard-coded minimum; e.g., min 3 days, but they could pick 3, 5, 7, 14 days, etc.), and a permissionless implementProposal. Only the owner could propose, but anyone could enforce the result after the deadline. Also consider an "implemented" flag, so that implementProposal can only be called once. Of course, at that point, since the owner has total control anyway, you might as well just let the owner set the fee directly... which I see you're also doing, so the voting mechanism doesn't really do anything.
Another possible design (though more complex), would be some notion of epochs: time periods during which anyone can create a proposal (probably capped to a certain number, like 5, especially if you're using an iterable array), and a permissionless "implement" that would implement the highest scoring proposal (or do nothing if there were no votes), then clear the data and start a new epoch.
Pending proposals could only be queried off-chain, which is maybe ok.
| } | ||
|
|
||
| // Function to set swap fee (can also be changed by governance) | ||
| function setHookSwapFeePercentage(uint64 swapFeePercentage) external onlyOwner { |
There was a problem hiding this comment.
As written, only the owner can set the fee (which would need to be validated in production). And if they can just set the fee directly, the voting doesn't really mean anything. (Though it already doesn't, if only the owner can propose any changes.)
If you want governance to be able to set it, you would have to implement that (e.g., derive from SingletonAuthentication and use the authenticate modifier). Then it could be set by Balancer governance or through voting. (Balancer governance would be unlikely to get involved with a third party hook like this, though.)
| } | ||
|
|
||
| // Pseudo-random number generation | ||
| function _getRandomNumber() private view returns (uint8) { |
There was a problem hiding this comment.
Would have to be an external Oracle or similar thing in production; there's no way to do this safely on-chain.
| import { GovernedLotteryHook } from "../contracts/hooks/GovernedLotteryHook.sol"; | ||
| import { AfterSwapParams, SwapKind } from "@balancer-labs/v3-interfaces/contracts/vault/VaultTypes.sol"; | ||
|
|
||
| contract GovernedLotteryHookTest is Test { |
There was a problem hiding this comment.
This is only testing the proposal and voting stuff; it doesn't actually use the hook. And couldn't, because there's no onRegister, and also getHookFlags returns nothing, so the Vault wouldn't call into the hook anyway even if it was connected and registered.
Also, the script is setting the Vault to v2.
| uint256 proposalId; | ||
| string description; | ||
| uint64 newSwapFeePercentage; | ||
| uint8 newLuckyNumber; |
There was a problem hiding this comment.
I don't think it makes any sense to update the lucky number. Updating the MAX_NUMBER would change the odds, which is meaningful. Maybe allow that to be updated, and generate a new lucky number based on the max (would have to use an Oracle or some other more random means).
The
GovernedLotteryHookis a smart contract designed for decentralized finance (DeFi) ecosystems, particularly in the Balancer V3 protocol. It introduces a lottery mechanism governed by community proposals, enabling users to vote on changes such as the lottery's winning number and swap fee percentage. The contract leverages a fee system collected from token swaps to fund lottery winnings, ensuring transparency and engagement within the community. By integrating governance with a lottery system, it creates an interactive and rewarding experience for participants while enhancing liquidity in the ecosystem.