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).
The current deployment should be understood as BERT Protocol V2: same modular foundation, but a more opinionated post-vote execution layer. The upgrade focused on IdeaRegistry, FundingPool, and GrantManager so proposal quality signals and treasury release logic could evolve without replacing the entire stack.
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 proposal-linked accounting. GrantManager applies payout logic from settled governance outcomes. USDC is the settlement asset used across participation thresholds, treasury movement, and grant execution.
Each core contract has clear scope to reduce hidden side effects and simplify reasoning about failures.
V2 contract focus
IdeaRegistry now carries a richer moderation and review surface, FundingPool participates in a more explicit treasury flow, and GrantManager governs staged release rather than a simplified winner-only payout model.
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.
V1 execution profile
Voting outcome primarily determined which idea won and whether the treasury should move funds. The public execution trail after the winner decision was comparatively narrow.
V2 execution profile
Voting still decides the winner, but the treasury path is now staged: initial claim, milestone proof submission, reviewer validation, later releases, and final completion. This better separates selection from delivery assurance.
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.
That is exactly how the V2 release should be read: not as a new protocol identity, but as a controlled proxy upgrade of critical execution modules with the surrounding system left intact.
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.