Funds Stuck in `startExchangeYes <= startExchangeNo` Condition

[c4-bot-10]

Lines of code

https://github.com/code-423n4/2024-01-salty/blob/main/src/launch/BootstrapBallot.sol#L69

Vulnerability details

Impact

f the protocol fails to receive enough votes during the initial proposal, all funds sent to the InitialDistribution will become stuck (1000000 ether)

Proof of Concept

https://github.com/code-423n4/2024-01-salty/blob/main/src/launch/BootstrapBallot.sol#L69

The finalizeBallot() function is called for the initial distribution, airdrop, and starting the exchange at the launch time. However, if startExchangeYes <= startExchangeNo, this condition leads to ballotFinalized = true, preventing further calls. There is currently no way to retrieve the funds, as the protocol assumes it will receive startExchangeYes > startExchangeNo. A malicious competitor or attacker could exploit this by funding the attack or employing other methods to ensure the condition holds

The main issue is that the protocol cannot propose for a vote a second time. If it fails to get enough startExchange votes the first time, it will lose all the funds

Tools Used

Manual

Recommended Mitigation Steps

Implement a better approach that allows the protocol to repropose in case it doesn't receive enough votes initially:

1. Provide a period for protocol teams to reevaluate and advertise the protocol after the first failed proposal

2. Implement measures to make reproposing difficult for attackers by increasing the cost of such attacks

Assessed type

DoS

[c4-judge]

Picodes marked the issue as duplicate of #606

[c4-judge]

Picodes changed the severity to QA (Quality Assurance)

[c4-judge]

Picodes marked the issue as grade-b