Venus Prime - kutugu's results

Lines of code

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

Vulnerability details

Impact

There are two issues regarding the release rate of tokens in PrimeLiquidityProvider:

1. Arbitrum use the L1 block number not L2 block number. Not sure if this is intentional, as Arbitrum's block production rate is variable so the protocol may want to adopt the L1 block to release tokens smoothly.
2. But for polygon zkevm, one tx represents one block, which means malicious users can send large amounts of spam emails to promote block generation and token release. This is beneficial to early staking users, who can collude to collect all rewards at a much faster release rate than expected.

There is also a BLOCKS_PER_YEAR variable in Prime, I don't think this will work properly on polygon zkevm.

Proof of Concept

I cannot provide a POC simulation to control the generation rate of blocks. You can view it from https://zkevm.polygonscan.com/. The general process is as follows:

1. Based on the recent actual polygon zkevm block production rate of 1 block/s, the protocol sets the token release rate to 1e18, the total number of tokens to 1e24, and is expected to be released in 12 days
2. The early users will immediately send a large amount of spam emails, with a production speed of 10 blocks/s and expected to be released in about 1 day, avoiding additional user participation and obtaining large rewards.

Tools Used

Foundry

Recommended Mitigation Steps

Use timestamp instead of block number to calculate rate

Assessed type

Context