A user can delegate his tire voting to a zero address

[code423n4]

Lines of code

https://github.com/jbx-protocol/juice-nft-rewards/blob/f9893b1497098241dd3a664956d8016ff0d0efd0/contracts/JB721TieredGovernance.sol#L177

Vulnerability details

Impact

A user can lose his vote for a specific tire id by delegating his vote to a zero address.

Proof of Concept

In the setTierDelegate function and also in _delegateTier function which is called by the previous function the input delegated address is not checked. In the _delegateTier function, then is stored in the _tierDelegation mapping for a specific tire id. In the _moveTierDelegateVotes function also there is not any revert if the new delegated address is zero.

Tools Used

Manual

Recommended Mitigation Steps

Check delegated for not being zero.

[drgorillamd]

This is not an issue, user can delegate votes at will (including delegating to another address later after delegating to address(0)), same as they can transfer to address(0) or vb.eth if they want.

[csanuragjain]

@drgorillamd
It wont be possible to delegate to other address post delegating to address 0. The reason being _moveTierDelegateVotes will only deduct vote and not increase. I have given detailed explanation at issue number 11
Can you please suggest

[drgorillamd]

@csanuragjain indeed, reopened 11 to give it another look, it kinda feels like a different issue tho

[Picodes]

The warden has not showed why the user won't be able to delegate to other address post delegating to address(0). Downgrading to QA has this issue only highlights a missing sanity check.

[c4-judge]

Picodes changed the severity to QA (Quality Assurance)

[c4-judge]

Picodes marked the issue as grade-b