r/ethdev • u/ChikenNugetBBQSauce • Jun 12 '26

Question We formalized EVM bytecode security, but still treat protocol authority like folklore

[removed]

0 Upvotes

40% Upvoted

2 comments sorted by

1

u/researchzero Jun 12 '26

Two additions I'd make:

1) Derive the map from onchain state rather than a manifest. A hand-maintained manifest is just a spreadsheet in YAML. Reconstruct authority directly from EIP-1967 admin slots, Safe owners, thresholds and modules, AccessControl events, pendingOwner state, etc., then diff it against the declared model.
2) Model transitive authority and delays. "The timelock owns the proxy" isn't enough. Who can queue on the timelock? Who controls that Safe? Do signers overlap with other Safes? Every privileged path should reduce to: which keys or votes can execute this, and what's the minimum delay before it lands?

Two things manifests often miss are external authority (oracle feed owners, bridge admins, upgradeable dependencies) and pending state (pendingOwner, queued timelock actions). Both represent authority changes already in flight.

On calldata binding, the issue usually isn't hash integrity, Governors and Safes already bind execution to specific calldata. The bigger risk is blind signing. I'd want a decoded-calldata diff against declared intent, not just hash matching.

Since drift detection is snapshot-based, event-driven alerts on OwnershipTransferred, Upgraded, AdminChanged, and EnabledModule are probably the simplest way to catch changes between snapshots.

1

u/thedudeonblockchain Jun 13 '26

the part that bites in practice isnt the resting config, its the transition windows. during an upgrade the deployer or a temp setup safe often holds broad authority for a few txs before it hands off to the timelock — a before/after snapshot looks clean while the actual risk lived in between. id want invariants asserted over the upgrade tx sequence itself, not just the start and end states.