Live Treasury Snapshot

These values are read from active contracts and represent current treasury policy state at runtime.

Scope & Objectives

Treasury policy in BERT exists to protect two things at the same time: capital safety and predictable execution. Safety without execution turns governance into dead process; execution without safety turns treasury into unbounded operational risk.

The policy therefore requires explicit funding rules, role boundaries, and verifiable state transitions for all treasury-affecting actions.

Treasury Sources

Primary treasury state is represented in Funding Pool. V2 separates voluntary reserve deposits from per-round pledge escrow: author bonds deter spam, losing pledges remain refundable, and fees from successfully claimed grants become protocol reserve.

Any source that changes effective pool balance should be traceable by event history and consistent with on-chain balances. If accounting and real token balances diverge, policy requires correction via authorized sync procedures before new distribution cycles.

Allocation Rules

Allocation follows conditional winner resolution from round settlement. A winner must clear its declared net target after pledgeFeeBps and have at least three distinct backers. Its own pledges fund a 20/40/40 grant: the first tranche is author-claimed, and each later tranche requires backer-controlled proof approval. Parameter changes are governance-sensitive and should be treated as policy-level updates, not routine UI edits.

Treasury policy should avoid hidden discretionary payouts. If a payout cannot be derived from round outcomes and configured rules, it should not be executed as standard treasury flow.

Distribution Workflow

Standard workflow is: round settled -> viable winner identified -> losing pledges become refundable -> winner claims 20% -> winning backers approve two 40% milestones -> fee finalizes to reserve as author tranches are claimed. Funding Pool and Grant Manager split responsibilities so pledge custody and payout logic are not mixed in one contract.

After payout, project delivery should be closed by author completion marker. This links financial execution with delivery accountability, reducing ambiguity in grant lifecycle reporting.

Reserve & Risk Limits

Treasury policy keeps reserve capital separate from grant escrow. A winning pledge is not transferred to the protocol reserve before the author claims; if a V2.3 grant is cancelled because of a missed deadline, failed second proof, or unresolved review, its unreleased escrow reopens the winning-pledger refund path.

High-impact parameter changes (stake thresholds, pledge fee, round size) should be evaluated against treasury sustainability, not only participation growth metrics.

Incident Policy

Incident sequence is mandatory: pause -> diagnose -> patch -> verify -> unpause. Treasury-affecting modules should remain paused until root cause is understood and post-patch verification confirms state integrity.

Emergency actions must be logged with reason, scope, and recovery steps. Policy violations in emergency handling should be treated as governance incidents.

Reporting & Transparency

Minimum reporting set: current pool balance, payout totals, grant outcomes by round, reserve state, and failed treasury transactions. These reports should reference on-chain events and not rely solely on manual spreadsheet summaries.

Public dashboards may be used for readability, but the source of truth remains contract state and transaction history.

Change Management

Treasury policy updates should follow explicit process: proposal -> review -> test rollout -> production apply -> post-change verification. Each change should include intended impact, rollback strategy, and measurable validation criteria.

For major changes, publish policy version notes and effective date to avoid governance ambiguity.