Role separation: upgrade ≠ fee ≠ oracle
A governance & admin factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor checks whether the upgrade, fee collection, and oracle configuration functions are assigned to distinct addresses or distinct multisigs — meaning no single address holds all three administrative powers simultaneously. The on-chain AccessControl or equivalent role mapping is queried for each of the three action types and compared for address overlap.
Why it matters
Role separation across upgrade, fee, and oracle functions prevents a single key compromise from granting an attacker total protocol control. An attacker who gains access to the oracle setter role should not also be able to upgrade the protocol or drain fee revenues. In practice, many DeFi protocols use a single deployer-controlled multisig for all three roles — which means that any compromise of that multisig constitutes a simultaneous oracle, fee, and upgrade authority breach. The evidence base shows that full-authority-concentration in a single key or multisig is strongly correlated with post-compromise total drains rather than partial impacts.
Green / Yellow / Red
Green is assigned when upgrade, fee, and oracle roles are held by three distinct addresses or multisigs with no overlap. Yellow covers two-of-three role separation (any one role shared with another). Red is assigned when all three roles are controlled by a single address or multisig, giving a single compromise total administrative authority.
Common gray cases
This factor is grayed when the protocol does not have all three role types (e.g., no oracle configuration because it uses an immutable oracle address — which is separately assessed under RD-F-180).
Notable historical examples
No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for#
Determine whether the upgrade role, fee-collection role, and oracle-config role are assigned to distinct addresses.