Dependency tree uses EOL Solidity version
A tooling / compiler / ai factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor flags whether the protocol's deployed code or its key dependencies use an end-of-life (EOL) Solidity version -- defined as a version no longer receiving any security patches from the Solidity team. EOL status is determined by the official Solidity changelog and is updated on a semi-annual cadence. The factor covers both the protocol's own contracts and the shared library versions (OpenZeppelin, Solady) where the library was compiled with an EOL version.
Why it matters
End-of-life compiler versions accumulate known vulnerabilities without patches, creating a growing gap between the deployed code's security properties and the current state of compiler knowledge. Unlike active versions where bugs are reported and patched, EOL versions have no patch pathway: a discovered vulnerability in an EOL version will never be fixed, and protocols using that version must migrate their entire codebase to receive the fix. The migration cost is exactly the risk that leads to extended use of EOL versions, creating a compounding risk: the longer the protocol stays on EOL, the more known-but-unpatched compiler bugs accumulate. This factor is forward-looking -- it flags exposure before a specific compiler bug is exploited rather than after.
Green / Yellow / Red
Green: all deployed contracts use a Solidity version that is currently supported and receiving security patches, with no EOL versions in the dependency tree. Yellow: deployed contracts use a Solidity version that is in the final six months of active support (approaching EOL) but has no currently-known critical bugs. Red: any deployed contract uses an EOL Solidity version with no active patching, or any shared library dependency was compiled with an EOL version that affects the protocol's deployed bytecode.
Common gray cases
Protocols that use a pinned older version for reproducibility reasons but have documented, audited evidence of compatibility with a patched newer version may be treated as yellow rather than red; curator must verify that the documented upgrade path has been implemented or has a firm timeline.
Notable historical examples
No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for#
Determine whether the deployed code or its dependencies use an EOL or unsupported Solidity version without a forward-compatibility patch.