Dependency tree uses EOL Solidity version
Uniswap (v2 + v3)'s assessment for RD-F-174 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
V2-core: Solidity 0.5.16 — very old (EOL; 0.5.x series ended ~2020). V3-core: Solidity 0.7.6 — not actively maintained (0.7.x reached legacy status Sept 2020 when 0.8.0 launched). Both contracts immutably deployed — permanently on EOL versions with no upgrade path. UniversalRouter: 0.8.26 (actively supported). V2: yellow (0.5.16 very old/EOL); V3: yellow (0.7.6 EOL/legacy). Combined: yellow.
Detail #
Solidity 0.5.x ended when 0.6.0 was released in December 2019; 0.5.16 was released in September 2019. Solidity 0.7.x reached legacy maintenance status when 0.8.0 was released in December 2020 — subsequent security patches went to 0.8.x only. Both V2 (0.5.16) and V3 (0.7.6) are on effectively-EOL compiler versions. However, since both codebases are immutably deployed, the compiler version risk is entirely historical — there is no future compilation risk. The risk is that known compiler bugs (see RD-F-170) cannot be patched, but those bugs are assessed as inapplicable to the deployed patterns.
Sources #
- GitHubUniversalRouter foundry.toml — 0.8.26 actively supportedUniversalRouter foundry.toml — solc 0.8.26 (supported)retrieved 2026-05-12
- hardhat.config.ts — solc 0.7.6 for V3 core contractsv3-core hardhat.config.ts — solc 0.7.6retrieved 2026-05-12
- Solidity releases — 0.8.0 launched December 2020 (0.7.x became legacy)Solidity release historyretrieved 2026-05-12
Methodology #
Determine whether the deployed code or its dependencies use an EOL or unsupported Solidity version without a forward-compatibility patch.
See the full factor methodology and distribution across all protocols →