Live Policy Snapshot
These values are read from the currently configured contracts and represent effective runtime policy, not static documentation text.
IDEAS_PER_ROUND
—
VOTING_DURATION
—
minStake
— BTK
MAX_VOTERS_PER_IDEA
—
authorSharePercent
—%
Pool Balance
— BTK
Faucet claimAmount
— BTK
Faucet cooldown
—
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 stake-backed. A vote is accepted only if all guardrails pass: active round, valid time window, minStake threshold, idea included in that round, and no self-voting. One address can vote once per round.
This policy intentionally makes governance expensive to spam while keeping it open to any participant with the required stake.
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 accounting state and Grant Manager executes distribution under eligibility checks. Author payout ratio is controlled by authorSharePercent and can be tuned via admin setter policy.
The protocol policy is to prefer explicit payout traceability over implicit off-chain accounting. Every critical transfer path should remain externally auditable.
Read Treasury PoliciesRoles & 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, claim test BTK, approve BTK spending, then create idea or vote in 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 Sepolia with fresh addresses from one deployment session before wider release.