Summary

Contracts should use strict versions of solidity. Locking the version ensures that contracts are not deployed with a different version of solidity than they were tested with. An incorrect version could lead to uninteded results.

https://solodit.cyfrin.io/issues/n-01-use-of-floating-pragma-code4rena-rubicon-rubicon-git

Vulnerability Details

There are 3 different smart contracts, each using a Floating Pragma

Impact

1. Potential Compilation Inconsistencies

• If the project is compiled in different environments (local, CI/CD, production) and the compiler versions are different (e.g. 0.8.17 vs 0.8.20), it can result in different bytecode.

• This can lead to differences in contract behaviour or bugs that are difficult to track down.

2. Vulnerable to Semantic Changes

• New versions of Solidity can bring semantic changes (although minor versions are usually backward-compatible).

• With loose pragmas, your contract may be compiled with a version that has different behaviour than the one you tested before.

3. Security Risks

• New versions may introduce new features or change the way optimisation works.

• If not thoroughly retested in the new version, it could lead to hidden security holes.

4. Audit Issues

• Auditors usually prefer locked pragmas to ensure that the contract being tested is the correct compiled version.

• Floating pragmas can make auditing difficult as the results can be non-deterministic if the compiler is different.

Tools Used

1. Foundry

2. Slither

3. Aderyn

Recommendations

Lock up pragma versions.