Core Contracts

Summary

The RAAC protocol is expected to be compatible with all EVM-compatible. Problem is the RAACMinter contract uses block.number with a fixed 12-second block time assumption, which is incompatible with L2 networks that use L1 block numbers and have different block timing. This could result in inaccurate reward distributions on L2 deployments.

Vulnerability Details

The core issue lies in the RAACMinter's assumptions about block timing:

The contract calculates rewards based on block differences, but this calculation is problematic in some L2s. Let's take a look on Arbitrum for instance:

1. block.number on Arbitrum returns the L1 block number "ish" (approximately), not the actual L2 block number

2. L2 blocks are created based on usage, not at fixed intervals

3. The assumption of 7200 blocks per day (12-second blocks) doesn't hold true on L2s

For example:

This means the reward calculation emissionRate * blocksSinceLastUpdate could be incorrect in two ways:

1. Underestimating rewards during periods of high L2 activity (many L2 blocks per L1 block)

2. Overestimating rewards during periods of low L2 activity (few L2 blocks per L1 block)

Impact

1. The reward distribution will significantly deviate from the intended token emissions over time.

2. Users might receive different amounts of rewards for the same time period.

Tools Used

Manual Review

Recommendations

1. Avoid using block.number directly.

2. On Arbitrum for instance, the reliable way to get the block.number is using ArbSys, i.e: arbSys.arbBlockNumber()

3. Pass a variable for the blocks per day in the constructor so it can be adjusted during deployment based on the chain protocol being deployed.