Solc version used (known-bug versions flagged)

Evidence summary #

Core contracts: Solidity 0.8.28 (Cancun EVM). Post-TGE contracts: 0.8.30 (Prague EVM). SOL-2026-1 affects 0.8.28-0.8.33 when using viaIR + tstore delete — viaIR not confirmed enabled on USDf impl. sFF/Staking Vault (0.8.30, Prague) have higher tstore likelihood. Not on patched 0.8.34.

Detail #

USDf implementation and sUSDf implementation: Solidity v0.8.28+commit.7893614a, Cancun EVM. FF Token: Solidity v0.8.28+commit.7893614a. Staking Rewards Distributor: v0.8.28+commit.7893614a, Cancun EVM. sFF proxy: v0.8.30+commit.73712a01, Prague EVM. FF Staking Vault (StakingRewards): v0.8.30+commit.73712a01, Prague EVM, 1M optimizer runs. SOL-2026-1 (TransientStorageClearingHelperCollision) was reported 2026-02-11 and fixed in 0.8.34. It requires both viaIR pipeline AND delete operations on transient storage variables. USDf impl Etherscan shows standard optimizer (not IR), reducing risk for core contracts. However newer contracts on Prague EVM (which introduced TSTORE opcode) are more likely to use transient storage. None of the Etherscan pages confirm tstore/tload usage. Protocol has not upgraded to 0.8.34. Yellow because bug exists in compiler versions used but activation condition (viaIR + tstore delete) is not confirmed.

Sources #

Methodology #

Identify the Solidity compiler version used for deployed bytecode and flag if it appears on the known-bug list (solc bugs.json or Vyper 0.2.15–0.3.0 range).

See the full factor methodology and distribution across all protocols →