FIAT DAO veFDT contest - cryptphi's results

Unlock liquidity for your DeFi fixed income assets.

General Information

Platform: Code4rena

Start Date: 12/08/2022

Pot Size: $35,000 USDC

Total HM: 10

Participants: 126

Period: 3 days

Judge: Justin Goro

Total Solo HM: 3

Id: 154

League: ETH

FIAT DAO

Findings Distribution

Researcher Performance

Rank: 8/126

Findings: 2

Award: $571.54

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: KIntern_NA

Also found by: ak1, cryptphi, scaraven

Labels

bug
duplicate
2 (Med Risk)

Awards

541.6482 USDC - $541.65

External Links

Lines of code

https://github.com/code-423n4/2022-08-fiatdao/blob/main/contracts/VotingEscrow.sol#L555-L592

Vulnerability details

Impact

In the delegation() call, there is no check if the caller's lock has reached expiration. With this a user whose lock has expired can delegate to other running locks so long the amount locked is not withdrawn.

Above can be used to influence voting power

Tools Used

Manual review

additional require check to ensure the delegator's lock is not expired.

#0 - lacoop6tu

2022-08-17T10:28:52Z

Duplicate of #254

  1. missing zero address check The following are missing zero address checks which may lead to contract redeployment, reverts, loss of ownership to contract and/or loss of funds.

**Occurrences:

  • Blocklist.constructor() - _manager and _ve params are missing zero address check which would lead to contract redeployment.
  • VotingEscrow.constructor() - params are missing zero address check which would lead to contract redeployment.
  • VotingEscrow.transferOwnership() - transferring ownership to zero address would make address(0) and ability to make admin calls lost permanently.
  • VotingEscrow.updateBlocklist() - setting blockslist address to address(0) would make many functions in contract revert.
  • VotingEscrow.updatePenaltyRecipient() - setting penaltyRecipient to address(0) may lead to loss of funds when collecting Penalty in collectPenalty()
  1. Blocklist contract should inherit from IBlocklist The Blocklist contract is not inheriting IBlocklist.

  2. Floating Pragma Contracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.

**Occurrences:

  • IVotingEscrow.sol
  • VotingEscrow.sol
  • IBlocklist.sol
  • Blocklist.sol
  • IERC20.sol
  1. Developer comment in Blocklist.block() should be @dev only callable by manager. instead of @dev only callable by owner.
AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter