Platform: Code4rena
Start Date: 08/07/2021
Pot Size: $50,000 USDC
Total HM: 7
Participants: 13
Period: 7 days
Judge: ghoulsol
Total Solo HM: 5
Id: 18
League: ETH
Rank: 5/13
Findings: 3
Award: $1,789.88
🌟 Selected for report: 1
🚀 Solo Findings: 0
shw
According to Chainlink's documentation, the latestAnswer
function is deprecated. This function does not error if no answer has been reached but returns 0, causing an incorrect price fed to the UniswapV3Oracle
.
Referenced code: UniswapV3Oracle.sol#L94
Referenced documentation: Chainlink - Deprecated API Reference Chainlink - Migration Instructions Chainlink - API Reference
Use the latestRoundData
function to get the price instead. Add checks on the return data with proper revert messages if the price is stale or the round is uncomplete, for example:
(uint80 roundID, int256 price, , uint256 timeStamp, uint80 answeredInRound) = wethOracle.latestRoundData(); require(answeredInRound >= roundID, "..."); require(timeStamp != 0, "...");
#0 - talegift
2021-07-15T10:57:12Z
#75
shw
In the migrateRewards
and _transferReward
functions of RewardDistribution
, the return values of rewardToken.transfer
are not checked to be true
. The return value could be false
if the reward token is not ERC20-compliant, indicating that the transfer fails, and the calling contract will not notice the failure.
Referenced code: RewardDistribution.sol#L182 RewardDistribution.sol#L189 RewardDistribution.sol#L191
Replace transfer
with the _safeTransfer
function in the LendingPair
contract.
#0 - talegift
2021-07-15T11:01:09Z
#67
🌟 Selected for report: shw
916.341 USDC - $916.34
shw
The InterestRateModel
contract assumes that the average block time is 13.2 seconds. However, the block time could range from 13.0 to 30.27, as we have seen in the past. The use of inaccurate block time could cause inaccurate borrow and supply rates.
Referenced code: InterestRateModel.sol#L17-L18
Etherscan.io - Ethereum Average Block Time Chart
Allow authorized parties to set the values of the LOW_RATE
and HIGH_RATE
variables or design them to be dynamically adjusted when the block time changes drastically. Alternatively, calculate the interests and rewards based on block.timestamp
instead of block.number
.
#0 - talegift
2021-07-15T11:03:13Z
block.timestamp
could be manipulated by miners.
This can be considered an acceptable risk. If the block time changes, we can swap the interest rate model in the controller quickly.
Severity should be set to 1.
#1 - ghoul-sol
2021-08-01T22:09:29Z
I don't see a direct exploit here. If blocks are produced faster, interest rate is calculated faster, if slower it's lower. This can be an issue however I agree it's a low risk.