Open code423n4 opened 2 years ago
Good suggestion. I don't think protocol fee is ever intended to be 0. Since the disrupted activity does not risk any funds, and can be restored quickly by the team, added to the low likelihood of fee being 0, it seems to be low severity issue.
I'm downgrading this to QA. This case should not rise and if it does there is a simple fix such that no funds are lost.
kirk-baird changed the severity to QA (Quality Assurance)
kirk-baird marked the issue as grade-b
Lines of code
https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L335 https://github.com/code-423n4/2022-10-paladin/blob/d6d0c0e57ad80f15e9691086c9c7270d4ccfe0e6/contracts/WardenPledge.sol#L396
Vulnerability details
Impact
Users are unable neither to
createPleadge
norextendPledge
if protocol Fees are set to zero for some tokensProof of Concept
It is not stated in documentation if you allow protocol fees to zero. For your code it is possible to owner to set the fee to zero.
However there are many non-malicious tokens that will revert if you try to transfer zero tokens. For these cases the function
createPledge
andextendPledge
will revert when trying to transfer fees to chestAn scenario is that some user create a pledge, then the owner decides to set fee to zero for some reason. That user will be unable to extend pledge and pledge will expiry.
Recommended
If you do not plan to set fee to zero it is better to set a minimum fee.