Towards Verifiably Secure Governance
summary
A permissioned governance stack is built around an authorizer singleton that answers can-account-do-action by checking hashed action IDs (function selector + contract), plus Slack alerts and CI-checked JSON mappings; renouncing permissions and a time-lock delay and cancelability window reduce phishing and mistaken-execution risk. That system works but adds opacity and new phishing vectors (obscure hashes, fake sites, DNS cache attacks). The missing piece is a middleware that aggregates design intent, risks, delays and human owners so reviewers can judge whether each queued action is sane.
AI-written summary · about
chapters (10)
- 0:00Intro
- 0:32The need for Access Control
- 3:47Address or Permission based
- 5:22Permissions at Balancer
- 6:10Permission sadness
- 6:40Reverse lookup
- 8:05Revised threat model
- 11:35Choosing delays
- 14:34Efforts underway
- 15:43Going beyond
related talks
41mSecurely Scaling Decentralized Governance
26mPolicy-Based Governance for End-to-End Integrity Control of...
15mBuilding Verifiable Agents with the Triple Verified Stack
27mSecurity-by-construction: How to weave authorization into modern app stacks using Open Policy Agent
22mGrowing & Securing Networks What’s Next for Onchain Governance
16mA Future to Protocol Upgradability
59mProvably secure authorization
54mFrom "Trust Me" to "Verify Me"