Live Policy Snapshot

These values are read from the currently configured contracts and represent effective runtime policy, not static documentation text.

Governance Rules

Round orchestration in BERT is permissionless by design: users do not wait for a centralized operator to advance governance state. A round starts only when protocol preconditions are satisfied, and it can be ended by anyone after the configured deadline.

Winner selection is deterministic and contract-level. This means disagreements about results should be resolved by chain state inspection, not by interface screenshots or off-chain claims.

Voting Rules

Voting is pledge-backed. A pledge is accepted only if all guardrails pass: active round, valid time window, minStake threshold, proposal included in that round, and no self-voting. One wallet can pledge once per round; winning participation credit is claimed individually after settlement, so V2.3 does not impose a 30-voter settlement cap.

Losing pledges are refundable. A proposal wins only when its gross pledge total is highest among viable proposals and remains at or above its declared minimumNetFunding after the round fee.

Proposal Lifecycle Policy

Canonical status path is: Pending -> Voting -> WonVoting/Rejected -> Funded -> Completed. Each transition is explicit and role/status guarded.

Moderation actions (review and low-quality marker) are intentionally constrained to Voting stage so they inform active decision-making without corrupting historical state.

Grant Distribution Policy

Treasury flow is separated by responsibility: Funding Pool holds idea-specific pledge escrow and Grant Manager executes the V2.3 20/40/40 release schedule. The first tranche is author-claimed; later tranches require a 40% winning-weight quorum, two-thirds approval of participating weight, and three approving backers. The configured pledgeFeeBps is reserved proportionally as author tranches are claimed.

The protocol policy is to prefer explicit payout traceability over implicit off-chain accounting. Every critical transfer path should remain externally auditable.

Roles & Moderation Policy

Roles are not pure UI badges. Reviewer and Curator capabilities are bound to progression and registry checks. This policy reduces arbitrary moderation and keeps privileged actions tied to measurable participation.

System roles should remain contract-assigned where possible, while high-impact admin privileges should be operated through hardened key policy.

Safety & Upgrade Policy

Incident flow: pause -> diagnose -> patch -> verify -> unpause. This is the default operational policy for protecting treasury and governance integrity.

Upgrade operations require post-upgrade verification: proxy owner checks, implementation checks, role wiring checks, and parameter checks. No policy change should be treated as complete until verification succeeds.

Get Started Policy

First-time user sequence: connect wallet, verify network, fund the wallet with test USDC, approve USDC spending, then create an idea or vote in an active round. If transactions fail, troubleshoot in this order: network alignment, addresses, pause state, role constraints.

Team policy for rollout: prove flows locally first, then repeat on Arc testnet with fresh addresses from one deployment session before wider release.