Party DAO - Ch_301's results

Summary

Low Risk Issues

• 1- Missing update the Status to Defeated
• 2- A malicious proposer could set cancelDelay to a large value
• 3- Potential of out-of-gas
• 4- users with zero voting power could make a proposal propose()
• 5- Ready proposal could get vetoed after passing the executionDelay
• 6- This will make the proposal to wait for the execution delay even if all hosts have accepted

Low Risk Issues

01- Missing update the Status to Defeated

the Proposal should enter the Status Defeated if it exceeds its voting window without reaching passThresholdBps. There is no check for this in accept(). so if this happened you should update pv.votes = type(uint96).max

There is one instance of this issue: GitHub: L595-L658

02- A malicious proposer could set cancelDelay to a large value

If the globalMaxCancelDelay == 0 in the Party. malicious proposer could set cancelDelay to a big value So no one can use this party anymore because his Proposal will stay in the InProgress status

There is one instance of this issue: GitHub: L797-L802

03- Potential of out-of-gas

in PartyGovernanceNFT.rageQuit() there is a for loop that could lead to out-of-gas so the users could end up leaving some funds in the PARTLY in order to invoke rageQuit() successfully

There are two instances of this issue:

GitHub: L378-L396 GitHub: L406-L441

04- users with zero voting power could make a proposal propose()

The PartyGovernance._assertActiveMember() should check if voting power is not delegated to another user

There is one instance of this issue: GitHub: L222-L228

05- Ready proposal could get vetoed after passing the executionDelay

It is not logical the Ready proposal could get VETO or anyone could front-run the transaction of the veto() / execute() because both of them accept the Ready states.

There is one instance of this issue: GitHub: L677 GitHub: L609

06- This will make the proposal to wait for the execution delay even if all hosts have accepted

We know the host could abdicate (Burned his host status) by invoking PartyGovernance.abdicateHost() at any time.

on the changelog tabel one of the changes is to add functionality to skip the proposal’s veto period if all hosts have accepted it. So Once all hosts accept a proposal, the veto period is skipped. This allows for parties to move faster.

If all the hosts have accepted a Proposal and one of them calls PartyGovernance.abdicateHost(address(0)) the value of numHosts gets decreased.

In order to skip the execution delay the PartyGovernance._hostsAccepted() function should return true

File: PartyGovernance.sol

1088:     if (pv.passedTime != 0) {
1089:       // Ready.
1090:       if (pv.passedTime + gv.executionDelay <= t) {
1091:         return ProposalStatus.Ready;
1092:       }
1093:       // If unanimous, we skip the execution delay.
1094:       if (_isUnanimousVotes(pv.votes, pv.totalVotingPower)) {
1095:         return ProposalStatus.Ready;
1096:       }
1097:       // If all hosts voted, skip execution delay
1098:       if (_hostsAccepted(pv.numHosts, pv.numHostsAccepted)) {
1099:         return ProposalStatus.Ready;
1100:       }
1101:       // Passed.
1102:       return ProposalStatus.Passed;
1103:     }

But due to the decrease in the numHosts value and the function `` only check in == number of the Hosts Accepted this proposal it will return a false

File: PartyGovernance.sol

1122:   function _hostsAccepted(
1123:     uint8 snapshotNumHosts,
1124:     uint8 numHostsAccepted
1125:   ) private pure returns (bool) {
1126:     return snapshotNumHosts > 0 && snapshotNumHosts == numHostsAccepted;
1127:   }

should be

File: PartyGovernance.sol

1122:   function _hostsAccepted(
1123:     uint8 snapshotNumHosts,
1124:     uint8 numHostsAccepted
1125:   ) private pure returns (bool) {
- 1126:     return snapshotNumHosts > 0 && snapshotNumHosts == numHostsAccepted;
+ 1126:     return snapshotNumHosts > 0 && numHostsAccepted >= snapshotNumHosts;
1127:   }