Which Solidity Version Should You Use? A Security View

Video transcript

Which Solidity version is safest right now? Use zero point eight point thirty-eight, the latest release and the only one with no known bugs.

Only the latest version gets security fixes, apart from exceptional cases. In 2026 alone, the Solidity team disclosed seven compiler bugs.

Older versions are not cleaner. The Yul optimizer bug went unreported for over three years, and two memory spill bugs date back to zero point seven point two.

The compiler repository tracks known bugs per release. Only the latest shows none, which means nothing found yet, not nothing left.

Your code generator matters too. Of those seven bugs, four affect via-IR only and one affects legacy only. Pick a pipeline early, then audit and deploy with it.

The default EVM target keeps moving: Shanghai, Cancun, Prague, now Osaka. Chains upgrade on their own schedules, and Linea and Kava rejected push zero when Guardian reviewed USDT zero's OneSig deployment. Pin the target and test each chain.

A pragma only checks the compiler version. It does not choose one. Floating ranges accept releases with known bugs, so pin an exact version and lock your build settings.

Guardian audits review the compiler version, pragma, EVM target and target chains alongside the code. Read the full guide, or talk to Guardian about auditing the build you deploy.

The Solidity docs are direct: "When deploying contracts, you should use the latest released version of Solidity."

The next line explains why: "Apart from exceptional cases, only the latest version receives security fixes."

2026 shows it. The Solidity team disclosed seven compiler bugs this year, fixed across four releases.

This guide covers known bugs by version, via-IR, EVM targets and pragma policy. For how one compiler bug becomes a vulnerability, see Solidity compiler bugs.

The Short Answer

For a new deployment, use 0.8.38 with an exact pragma: pragma solidity 0.8.38;

Its bug list is empty today. That records what has been found so far, not proof that nothing is left.

Latest versus battle-tested

The case for an older version is time in production. The record cuts the other way:

• The Yul optimizer bug fixed in 0.8.38 entered in 0.8.19, released February 2023.
• It was reported in August 2026, more than three years later.
• Two memory spill bugs fixed in 2026 date back to 0.7.2.
• The memory bytes delete bug predates the compiler's first release.

Older versions are not cleaner. Every one carries known bugs, and none gets fixes.

The real cost of a new release is that its new code has had the least scrutiny. Read its changelog and run your full test suite before switching.

Known Bugs by Version

The compiler repository keeps the record in two files. bugs.json describes each bug; bugs_by_version.json lists the known bugs in every release.

Recent releases, with the known bugs each one carries as of November 6, 2026:

The 2026 disclosures, and what each one needs to trigger:

Most need specific settings. The team rated only one high: the transient storage bug, reported by Hexens on February 11, 2026.

It needed via-IR, a delete on a transient variable and storage clearing in the same contract. The team found three deployed contracts matching the pattern, none of them public production apps.

Via-IR Versus Legacy

Solidity has two code generators in normal use. The legacy pipeline is the default. Via-IR compiles through Yul, Solidity's intermediate language, and is off unless you enable it.

The pipeline decides which bugs reach you. Of the seven 2026 bugs:

• Four affect via-IR only.
• One affects the legacy pipeline only: the memory bytes delete bug.
• The inheritance order bug is independent of the pipeline.
• The Yul optimizer bug can hit any optimized via-IR code, but legacy code only in narrow cases.

Neither pipeline is bug-free. Choose one early, audit with it, and deploy with it.

The optimizer also changes what ships. In Ethena Pay, an optimized via-IR build removed an unused transient storage probe documented as a deployment check (I-04, acknowledged).

EVM Version and Chain Support

The EVM version tells the compiler which opcodes it may emit. Solidity's default has moved with Ethereum:

• 0.8.20: Shanghai, which adds PUSH0.
• 0.8.25: Cancun, which adds TLOAD, TSTORE and MCOPY.
• 0.8.30: Prague.
• 0.8.31: Osaka, the current default.

Toolchain defaults move too. Foundry switched its evm_version default from Prague to Osaka in v1.7.0 (April 2026), though its config reference still lists Prague.

Set the EVM version explicitly in your build config.

The Solidity docs warn: "Compiling for the wrong EVM version can result in wrong, strange and failing behavior."

Test the target chain

Chains adopt Ethereum upgrades on their own schedules. In Guardian's June 2025 review of USDT0's OneSig deployment, Linea and Kava rejected PUSH0 at the time (I-04).

The report's check is one line. It simulates a contract creation that runs PUSH0 (0x5f), then TLOAD (0x5c):

cast call --rpc-url <RPC> --create 0x5f5c

An "invalid opcode" error means you must compile for an older EVM version, or skip that chain.

Transient storage

Transient storage needs Cancun. Ethena swapped ReentrancyGuardTransient for ReentrancyGuard after Guardian flagged chains without it (I-18, resolved).

Transient values also clear at the end of every transaction. In MUX Perps, prices kept there were gone by the next transaction, breaking a withdrawal path (H-04, High, resolved).

Pragma Policy

A pragma does not choose your compiler. The docs say it "just instructs the compiler to check whether its version matches the one required by the pragma."

So ^0.8.0 accepts any 0.8 release, including ones with known bugs. Guardian flagged exactly that in GMX Synthetics in 2023 (GLOBAL-8).

Ranges can also break features. Magna's vester used transient state variables, which compile only from 0.8.28, under a ^0.8.24 pragma (L-04).

A policy that holds up:

1. Pin an exact version in every deployable contract's pragma.
2. Pin the same version, EVM version, via-IR flag and optimizer runs in your build config.
3. Keep version ranges only in libraries others compile.
4. Fail CI when compiler settings change. See smart contract CI/CD.
5. Verify deployed bytecode against the exact audited settings.
6. When Solidity discloses a bug, check deployed contracts against bugs_by_version.json.
7. Treat a compiler upgrade as a code change: rerun tests and review the diff.

The disclosures include steps for checking deployed code. For the Yul optimizer bug, the team suggests comparing bytecode built with and without the fix.

For the rest of the build checklist, see Solidity security best practices.

How Guardian Checks Compiler Risk

Guardian audits review the compiler version, pragma, EVM target and target chains alongside the code. The audit findings above come from Guardian's public reports.

A Guardian smart contract audit runs three passes: design review, an invariant suite, then senior researchers attack what is left.

With Vanguard, two independent teams review one scope, and post-launch updates are audited too.

Frequently Asked Questions

What is the latest version of Solidity?

Solidity 0.8.38, released October 22, 2026. As of November 6, 2026, the official bugs_by_version.json lists no known bugs for it. Earlier releases each carry at least one.

Should I use a floating pragma like ^0.8.0?

Not in contracts you deploy. A pragma only checks the compiler version; it does not choose one. A range accepts releases with known bugs and can break features that need a newer compiler. Pin an exact version.

Is via-IR safe to use?

Both pipelines have had bugs. Four of the seven compiler bugs disclosed in 2026 affected via-IR only, and one affected the legacy pipeline only. Choose a pipeline early, audit with it and deploy with the same settings.

Why does my deployment fail with "invalid opcode: PUSH0"?

The compiler targeted Shanghai or later, the default since 0.8.20, and the chain does not support PUSH0. Compile for an older EVM version on that chain, or test support first with a one-line cast call.

Sources

• Solidity docs: Solidity, version guidance
• GitHub, ethereum/solidity: Releases (0.8.38, October 22, 2026)
• GitHub, ethereum/solidity: bugs_by_version.json (read November 6, 2026)
• GitHub, ethereum/solidity: bugs.json (read November 6, 2026)
• GitHub, ethereum/solidity: Changelog
• Solidity blog: Transient Storage Clearing Helper Collision Bug (February 18, 2026)
• Solidity blog: Yul Optimizer Knowledge Base Stale Bookkeeping Bug (October 22, 2026)
• Solidity blog: security alerts and release announcements, 2026
• Solidity docs: Using the Compiler, EVM version targets
• Solidity docs: Layout of a Solidity Source File, version pragma
• Foundry docs: Solidity compiler configuration
• GitHub, foundry-rs/foundry: Release v1.7.0, Osaka as default EVM version (April 28, 2026)
• Ethereum Improvement Proposals: EIP-3855, PUSH0 instruction
• Ethereum Improvement Proposals: EIP-1153, transient storage opcodes
• Guardian: USDT0 OneSig Deployment report (June 4, 2025)
• Guardian: Ethena TimelockController report (May 26, 2025)
• Guardian: Ethena Pay Updates report (July 6, 2026)
• Guardian: MUX Perps report (February 6, 2025)
• Guardian: GMX Synthetics V2, Review 6 report (July 11, 2023)
• Guardian: Magna Merkle Vester report (August 20, 2025)