Kogaroshi
commented
2 years ago This behavior is wanted The purpose of the hPAL is not to receive this type of bribes. And having the current logic allows that hPAL token to be used inside a Paladin Pool (which sells vote delegation through a different system than bribing)
Any system built on top of hPAL that should influence liquidity flow, will work through a different system with delegation/vote boosting cooldowns
1. Low - No vote delegation lock can cause bribe issues
Impact
Most vote delegation tokens that vote for liquidity flow introduce bribing, as seen in the Curve wars. If a similar mechanism is intended for hPAL, the _delegate function does not have any storage variable or checks to limit how long a delegation must remain in place before it is changed. This can lead to a situation where vote bribing is hard to enforce on chain, because a hPAL owner could sell their votes without on-chain enforcement of the delegation getting sold again.
Proof of Concept
There is no limit to how often a hPAL owner can delegate their votes. If they sell their votes on a bribing platform, there is no enforcement that the votes cannot be sold again and delegated elsewhere. There is no checks in the _delegate function or the functions that call it. https://github.com/code-423n4/2022-03-paladin/blob/main/contracts/HolyPaladinToken.sol#L1317-L1330
Tools Used
Manual analysis
Recommended Mitigation Steps
Add a lock period of 1 week or 1 month for delegation to remain static. If a hardcoded value is not flexible enough, the user could delegate their votes for a user specified amount of time to prove they will not redelegate their votes after selling them.