# DOS of proposals by abusing ballot names without important parameters

Salty.IO DAO ballot names omit key proposal parameters, letting an attacker squat names and block legitimate proposals for days.

- Payout: Contest reward
- Severity: medium
- Program: Salty.IO
- Credited: juancito
- Disclosed: 2024-04-19
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-salty-findings/issues/621
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-salty%3AM-12
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:dos vuln:governance

**Target:** DAO Proposals.sol ballot creation
**Root cause:** openBallotsByName uniqueness check keys only on ballotName, which omits parameters like newAddress, call number, tokenIconURL, and description, so an attacker can pre-create a colliding ballot.
**Steps:**
1. Call `proposeSendSALT()` with a malicious recipient; ballot name is fixed `sendSALT`.
2. Legit `proposeSendSALT()` reverts on `require(openBallotsByName[ballotName] == 0)`.
3. Wait for ballot duration (min 3 days, default 10), finalize, immediately re-create the same ballot.
4. Repeat to permanently block; similarly squat `proposeSetContractAddress`/`proposeCallContract`/`proposeTokenWhitelisting` by name-only collisions.
**How found:** Code review of Proposals.sol ballot-name construction; noticed ballotName omits parameters and that the uniqueness require reverts on duplicates, then mapped each propose function to its missing parameter.
**Exploitation:** Attacker stakes SALT, repeatedly creates colliding ballots (e.g. sendSALT to self) every ballot period, finalizing and re-creating to keep the name occupied, blocking all legitimate proposals of that type indefinitely at negligible cost.
**Insight:** When a uniqueness key gates creation, check whether the key covers all semantically distinct inputs; any omitted field becomes a squatting/front-running DoS vector, especially with fixed names like sendSALT.