Solidity Foundry Import Forge – How to Install Multiple Versions of a Dependency in Foundry

In most cases the contract will just not compile. Many projects use the caret operator (^) in their pragma because the code should generally still work until the next breaking release of the compiler and beyond that all bets are off.

In some cases the contract might work after a breaking change with little to no changes. If it does, you're safe most of the time. The question is if you consider "most of the time" good enough. Given that security holes in smart contracts are very common, I think it would be unacceptable for any contract that is meant to hold a significant amount of funds.

To mitigate the risk you should carefully review the contract source if you're planning to do that. Take a good look at the list of breaking changes in the compiler, especially the section called "Silent Changes of the Semantics":

• Solidity v0.7.0 Breaking Changes
• Solidity v0.8.0 Breaking Changes

Every breaking release may introduce some semantic changes that make code behave differently in specific situations. For example;

• Unchecked arithmetic added in 0.8.0 makes any code that relies on overflows/underflows revert at runtime. Some libraries might be doing that on purpose as a form of gas optimization, especially when doing bit manipulation. Such code will compile but is broken if you do not wrap it in unchecked.
• a**b**c used to mean (a**b)**c. This is different than in most other programming languages and counterintuitive so it was changed to a**(b**c) in 0.8.0. If the library is relying on it, its calculations will be wrong.
• assert() and reverts issued by the compiler used to use the INVALID instruction which terminates the execution and eats all gas. Due to high gas costs and the introduction of unchecked arithmetic (which makes such reverts more common as a form of validation) it was changed and a Panic() error is returned instead. But in rare cases leaving some gas available actually has security implications and makes some forms of attack possible. Here's a case where OpenZeppelin decided to switch back to the old behavior due to that: Use invalid opcode in MinimalForwarder #2864. If the library has code like that, using a newer compiler without addressing it opens a subtle vulnerability.

As you can see, there are some things that can bite you hard if you're not careful. If the project has a good test suite, you should run it. If it passes, you can have more confidence that running on a newer compiler version did not introduce any unintended changes in behavior. It's still not a 100% guarantee though and some manual review with going through the list of changes in the Solidity docs is always recommended as an extra precaution.

If you do not want to spend all that effort, it's better to look for ways to use the third-party contract as is. See my answer in How to import Aave and Uniswap contracts from a 0.8.x Solidity contract for some hints on what you can do.

While executing the forge script command, include --sender or --private-key wallet options to change the tx.origin address.