code423n4 commented 2 years ago

Lines of code

https://github.com/code-423n4/2022-05-backd/blob/1136e0cdc8579614a33832fe2a21785d60aac19b/protocol/contracts/BkdLocker.sol#L77-L83 https://github.com/code-423n4/2022-05-backd/blob/1136e0cdc8579614a33832fe2a21785d60aac19b/protocol/contracts/BkdLocker.sol#L221-L232

Vulnerability details

The reason that users are given boosted rewards for locking their governance tokens is that by making them illiquid for a set amount of time, the supply available to be sold is restricted, and users buying the token are more able to push the price up.

Impact

By not blocking wrapper contracts, the tokens can be made more liquid, and in an efficient market, arbitrage would make the now-liquid wrapped tokens and the non-wrapped tokens be close to the same, lower price. See this prior finding for details.

Proof of Concept

There are no allow/deny lists for preventing non EOA accounts from interacting with the protocol:

File: protocol/contracts/BkdLocker.sol   #1

77       /**
78        * @notice Lock gov. tokens.
79        * @dev The amount needs to be approved in advance.
80        */
81       function lock(uint256 amount) external override {
82           return lockFor(msg.sender, amount);
83       }

https://github.com/code-423n4/2022-05-backd/blob/1136e0cdc8579614a33832fe2a21785d60aac19b/protocol/contracts/BkdLocker.sol#L77-L83

Tools Used

Code inspection

Recommended Mitigation Steps

Add an allow list or a deny list for approving/denying contracts allowed to lock tokens

chase-manning commented 2 years ago

We are fine with a user wrapping this.

GalloDaSballo commented 2 years ago

Beside the sponsor disputing, the warden has made a statement about the usage of the smart contracts, which in no way break any invariants nor requirements brought in by the Sponsor.

For those reasons, I agree that the finding is invalid

code-423n4 / 2022-05-backd-findings