
Every so often I'm reminded how great Foundry is to work with.
I'm building something on top of Polymarket and I need to go direct to the Conditional Tokens they use for events, so I need to deploy on Polygon.
When trying to deploy to testnet I was reminded that Polygon (PoS where Polymarket is) doesn't support anything after the Paris hardfork, and since I used Solidity v0.8.30 that was a problem.

I was afraid I'd have to update the compiler version across my contracts, and when I tried to, it caused a lot of build errors in my tests. Then I thought that since both solc and evm_version are included in the foundry.toml file, it'd make sense if you could set an older evm_version and the compiled code would avoid opcodes that didn't exist on that version.

Turns out that works and you can change the evm_version and it will compile to exclude any opcodes supported in that Solidity version which that shouldn't be used on that EVM version.

There is even a convenient tool to check. Running cast disassemble <bytecode> will show a human readable version of the code that you can check for banned opcodes like PUSH0.

It's worth noting that this might not always work. My contracts were pretty simple and didn't explicitly use any features that were not present in v0.8.19 so recompiling and checking all my tests was enough.
Share Dialog
jamco.eth
1 comment
Working with Foundry has its perks, as explored by @jamco.eth. A recent deployment challenge on Polygon led to the discovery that adjusting the `evm_version` settings in Foundry can prevent compilation errors. Instead of changing Solidity versions, this solution allowed existing contracts to remain compatible with the desired EVM changes. A straightforward check with `cast disassemble <bytecode>` helps confirm safe opcodes without landing on roadblocks. Perfect for projects involving networks like Polymarket!