Venus Prime - nadin's results

Lines of code

https://github.com/code-423n4/2023-09-venus/blob/b11d9ef9db8237678567e66759003138f2368d23/contracts/Tokens/Prime/PrimeLiquidityProvider.sol#L249-L272

Vulnerability details

Impact

Inaccuracy of block.number will affect the calculation of accrueTokens(). That will affect functions like PrimeLiquidityProvider.sol#_setTokenDistributionSpeed() , Prime.sol#accrueInterest().

Proof of Concept

• According to the documentation where this code will be deployed:

Blockchains where this code will be deployed: BNB Chain, Ethereum mainnet, Arbitrum, Polygon zkEVM, opBNB.

• While block.number works reasonably well on Ethereum's mainnet, where new blocks are produced at ~12s intervals, it can become problematic on other chains, especially L2 networks, where blocks can be produced much more frequently, potentially every few seconds, and/or have variable rates of production. This can cause inconsistencies in the timing mechanism, therefore significantly affecting the time-weighted aspect to the PrimeLiquidityProvider.sol#accrueTokens() function.
• For example according to Arbitrum Docs, block.number returns the most recently synced L1 block number. Once per minute, the block number in the Sequencer is synced to the actual L1 block number. Using block.number as a clock can lead to inaccurate timing.
• It also presents an issue for Polygon zkEVM , opBNB.
• Here is the affected line of code : see here

276:    function getBlockNumber() public view virtual returns (uint256) {
277:        return block.number;
278:    }

---SNIP---

249:    function accrueTokens(address token_) public {
---SNIP---
254:        uint256 blockNumber = getBlockNumber();
255:        uint256 deltaBlocks = blockNumber - lastAccruedBlock[token_]; // @audit do not use of block.number on L2 to calculate this 

Tools Used

Manual review

Recommended Mitigation Steps

Use block.timestamp rather than block.number.

Assessed type

Timing