Tension-Driven Governance:
Balancing Efficiency & Capture Resistance
I’m sharing some ideas that address some of the questions and reflections that have emerged in the co-creation sessions so far. Proceed with an open mind. 
“No viable organism is either centralized or decentralized. It is both at once, in different dimensions.”
Stafford Beer- VSM
Traditional DAOs often default to either slow, all-inclusive voting or tightly centralized decision-making. Both extremes carry risks: sluggish responsiveness on one hand, or loss of community legitimacy on the other.
A tension-driven model offers a middle path. 
It centers governance around actual, felt needs (raised as “tensions”) that can then be processed through predefined roles.
This is how living organisms manage to thrive in complexity, and could enable Scroll to move quickly on real issues while building in resilience and accountability. 
Structural Overview: Five Functional Layers
Inspired by Stafford Beer’s Viable System Model (VSM), this architecture splits responsibilities across five interacting layers:
-
System 1: Contributors / focused on direct execution of work (research, comms, dev, growth, etc.)
-
System 2: Support Squad (OpCo style) / roles that enable smooth coordination (docs, onboarding, synthesis, facilitation). Check out my post on this: Support Squad Pilot (Weaver + Scribe Model).
-
System 3: Audit Council / tasked with retroactive funding review, quality assurance, and systemic learning. This is in relation to the Execution Oversight Council (EOC).
-
System 4: Delegates / act as stewards of the long-term vision and feed back ecosystem signals (by through maintaining a direct link with token holders).
-
System 5: Foundation / final guardians of purpose and constitutional coherence (defining and updating the ‘why’ Scroll exists).
This division makes it clear who is responsible for what, and prevents overlaps or gaps in decision-making.
Verified Delegate Contribution Roles
By introducing “Verified Delegate” roles, Scroll is recognizing those who go beyond signaling to actively serve the protocol.
I propose to consider three contribution tracks:
-
Verified Delegate Responsibilities: voting, reviewing proposals and giving quality feedback to iterate them (+ whatever we decide needed)
-
Operational roles: Direct project-based work (e.g., leading research, creating content, organizing events, leading programs, onboarding users, driving business development, etc.)
-
Support roles: Governance infrastructure (e.g., writing summaries, improving documentation, coordinating working groups, facilitating co-creation and connection spaces)
Verification could be based on
- trackable, simple metrics like proposals authored, Forum participation, number of working group calls joined, etc.
- peer to peer vouching and trust based reviewing
- token-holder endorsement
- time spent within the DAO
- etc.
Audit Council: Oversight by Design
System 3 - Audit would be composed of a Council of (at least) 3 elected individuals serving staggered terms to ensure both continuity and representation.
Instead of having ‘contribution roles’ (selected by the Foundation); this would maintain a council that is elected (or nominated) by Token-Holders.
This adds a crucial layer of accountability to both the Foundation and delegate-contributor ecosystem (+ certain political-power to token-holding)
The main duties of this council could include:
-
Reviewing retro funding and bounty execution
-
Evaluating proposal outcomes vs. goals
-
Flagging misalignment or inefficiencies
-
Providing selection recommendations (optional-transparent input for Foundation decisions)
The Tension Flow: End-to-End Coordination
The full tension lifecycle would look like this:
-
A delegate, contributor, or token holder surfaces a tension (e.g. poor onboarding experience) as a sensor in the system 
-
A facilitator (a.k.a. Support Squad) turns that tension into a:
- concrete proposal or mission
- mission (anyone can engage; evaluated later),
- bounty (clear deliverable, assigned budget, credential required).
-
If the proposal raises structural implications, the Foundation can object (consent decision making); but must justify based on mission or risk, with support from a neutral facilitator
-
Once approved, the proposal/mission/bounty is executed by verified contributors, tracked in a public dashboard.
-
The Audit Council reviews outcomes and recommends rewards or process improvements.
This model allows Scroll to evolve without needing to constantly rewrite its whole system.
Consent-Based Governance & Safeguards
Instead of requiring active approval for every change, proposals move forward by default unless someone raises a reasoned objection. Objections that require escalation (whether due to level of impact or conflicts in reaching consent) can use “Optimistically Approved” decision model where Verified Delegate can veto.
This “consent” model dramatically speeds up governance while still protecting against harmful decisions.
Objections must be grounded in a clear risk to Scroll’s purpose or function, not just personal disagreement. Facilitators help ensure that all objections are processed constructively.
For more info on these, check out The Case for Holacracy as a Governance Model for Scroll.
I want to emphasize that this post proposes a long-term design, not a quick fix. These comments are intended as a starting point and a source of inspiration.
The beauty of it is that this allows us to begin with something and evolve it iteratively through your different ‘tensions’. 
https://calendar.google.com/calendar/u/0?cid=Y181YzYyZGI5YmEyOWVjOGIzOWFiN2JlMWJiYzc1MGIzMzNjNTU0YmIxNDRmNWJhYjI4Y2VmYTU1YmZhNGE4NGIzQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20