Stack Overview
BERT governance stack is split into independent modules so policy, decision-making, and treasury execution are not tightly coupled. This separation improves auditability and allows controlled upgrades without rewriting the full protocol.
Conceptually, the stack has three big phases: state intake (ideas and votes), decision settlement (winner resolution), and execution (grant distribution and completion tracking).
Core Contracts
IdeaRegistry is the source of truth for proposal metadata and statuses. VotingSystem owns round lifecycle, vote accounting, and winner resolution. FundingPool maintains treasury balances and stake-linked accounting. GrantManagerapplies payout logic from settled governance outcomes. GovernanceToken provides ERC-20 stake asset behavior.
Each core contract has clear scope to reduce hidden side effects and simplify reasoning about failures.
Control Layer
Permission model is centralized through RolesRegistry. Contracts that need privileged actions receive dedicated system roles, while user capabilities are granted through progression pathways.
Admin controls (setters, pause/unpause, dependency rewiring) are powerful by design and must be operated under strict key and review policy.
Reputation & Progression Layer
ReputationSystem tracks contributor quality signals tied to outcomes. VoterProgression records winning participation and grants role eligibility (for example reviewer/curator paths) through policy logic.
This layer is intentionally separated from raw vote counting so social signal mechanics can evolve without breaking core vote accounting.
Execution Layer
Governance execution starts only after round settlement. Winner result feeds into payout workflow where treasury movement is validated, executed, and reflected in status updates. Final closure is author-driven completion marker on funded idea.
The design goal is that every meaningful execution step is externally verifiable through state and events.
Upgrade Layer
Core modules are deployed behind transparent proxies. Upgrade authority is administrative and therefore a major trust boundary. Safe upgrade policy requires storage compatibility checks, staging rehearsal, and post-upgrade verification.
Upgrades should be treated as governance events with explicit review notes, rollback planning, and audit trail.
Trust Boundaries
Trust-minimized parts: vote accounting, status transitions, and payout execution logic once valid calls are made. Admin-trusted parts: parameter tuning, pause controls, dependency rewiring, and upgrades.
Production governance maturity depends on reducing single-key assumptions and publishing these boundaries transparently to participants.