Code divergence from upstream (%)
A fork / dependency lineage factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor records the percentage of lines changed between this fork's deployed code and the stated upstream source at the fork point, computed via git diff against the upstream repository at the reference commit. A high divergence percentage indicates that the fork has evolved substantially beyond the audited upstream, potentially introducing novel vulnerabilities that the upstream's audit does not cover. The data source is the protocol's public repository combined with bytecode diffing against the upstream.
Why it matters
Fork divergence is a proxy for how much 'new surface' has been added beyond the audited upstream code. A fork that has diverged 80% from Compound Finance is essentially a new protocol in a Compound wrapper -- the upstream's audit provides minimal assurance for the diverged portions. The sweet spot of fork risk is high divergence without corresponding audit coverage of the diverged code: the team gets the credibility signal of forking from a well-known protocol while deploying substantial novel code that has not been independently reviewed. Governance fork parameter changes are one of the most common forms of divergence; Curio ($16M, 2024) exploited a MakerDAO fork where voting power privilege logic had been modified without independent parameter review.
Green / Yellow / Red
Green: code divergence from upstream is below 20% and the diverged portion has been independently audited or is limited to configuration parameters. Yellow: divergence is 20% to 60%; a delta-audit covers the changed portions. Red: divergence exceeds 60% with no audit of the diverged code, or divergence is in security-critical functions (access control, oracle integration, liquidation logic) without independent review.
Common gray cases
This factor is gray when the protocol does not publish source code, when the upstream commit reference is not stated, or when the fork is of a non-public upstream that cannot be compared.
Notable historical examples
No hacks are currently linked in the database for this specific factor as a standalone causal driver. The factor is a structural input that feeds the RD-F-131 audit coverage assessment.
Measurement what to look for#
Measure the percentage of lines changed between this fork's deployed code and the stated upstream codebase at fork point.