Core Contracts

Summary:

The RAACMinter contract uses a hardcoded value for BLOCKS_PER_DAY (7200), which assumes a 12-second block time. This assumption is incorrect for many chains, including Arbitrum (0.1 seconds) and Optimism (2 seconds). This hardcoded value leads to inaccurate RAAC emission calculations and unpredictable token distribution across different chains.

Vulnerability Details:

The RAACMinter contract calculates emissions based on the emissionRate, which is expressed in RAAC per block. This emissionRate is then used in the tick() function to determine how many RAAC tokens to mint and distribute. The BLOCKS_PER_DAY constant is used in the constructor to derive the initial emissionRate and is also implicitly used in the tick() function when calculating emissions over a period of blocks. Because BLOCKS_PER_DAY is hardcoded, the emission calculations will only be accurate on chains with a 12-second block time (Ethereum). On chains with faster block times, emissions will be significantly higher than intended, while on chains with slower block times, emissions will be significantly lower.

• BLOCKS_PER_DAY Constant

• Tick Function

Impact:

The hardcoded BLOCKS_PER_DAY leads to the following issues:

• Inaccurate Emissions: On chains with faster block times (like Arbitrum, Optimism), the RAACMinter will mint and distribute far more RAAC than intended. On chains with slower block times (like Ethereum), it will mint and distribute far less RAAC.

• Unpredictable Token Supply: The inaccurate emission rate makes it impossible to accurately predict the total RAAC supply over time. This can negatively impact the token's price and overall ecosystem health.

• Unfair Distribution: Users on different chains will receive vastly different amounts of RAAC for the same activity due to the block time discrepancy. This creates an unfair distribution mechanism.

• Potential for Exploitation: Knowing the block time of a chain, malicious actors could potentially exploit the inaccurate emission calculations to accumulate more RAAC than they should.

Proof of Concept:

Let's consider two scenarios:

Scenario 1: Arbitrum (0.26-second block time)

• Actual blocks per day: (24 hours x 60 minutes x 60 seconds) / 0.1 seconds/block = 864,000 blocks/day

• RAACMinter's BLOCKS_PER_DAY: 7200

• If the intended emission rate is 1000 RAAC per day, the RAACMinter will calculate emissionRate based on 7200 blocks, but the actual number of blocks will be 864,000. This means the actual emissions will be significantly higher, approximately 120 times higher (864,000/7200).

Scenario 2: Optimism (2-second block time)

• Actual blocks per day: (24 hours _ 60 minutes _ 60 seconds) / 2 seconds/block = 43,200 blocks/day

• RAACMinter's BLOCKS_PER_DAY: 7200

• If the intended emission rate is 1000 RAAC per day, the RAACMinter will calculate emissionRate based on 7200 blocks, but the actual number of blocks will be 43,200. This means the actual emissions will be significantly higher, approximately 6 times higher (43200/7200).

In both scenarios, the actual emissions will be much higher than intended due to the hardcoded BLOCKS_PER_DAY value. This demonstrates how the hardcoded value leads to vastly different and incorrect emission rates on different chains.

Tools Used:

• Manual code review

Recommended Mitigation:

The BLOCKS_PER_DAY constant should be removed. The RAACMinter contract should retrieve the block time dynamically. This can be done by using a chain-specific oracle or by calculating the average block time over a recent period. The emission calculations should then be adjusted to use this dynamically retrieved block time. Alternatively, the contract could use a time-based emission calculation (e.g., RAAC per second) instead of a block-based calculation. This would remove the dependency on block time altogether.