Launch App

Live Treasury Snapshot

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

totalPoolBalance

BTK

protocolReserve

BTK

authorSharePercent

%

BTK totalSupply

BTK

BTK maxSupply

BTK

Faucet claim/cooldown

BTK /

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. Sources may include governance-token stake flow, protocol-directed funding inflows, and admin-synchronized balance updates where explicitly allowed by contract policy.

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 winner resolution from round settlement. Grant splits use protocol parameters such as authorSharePercent. 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 -> winner identified -> grant eligibility validated -> payout executed -> status updated. Funding Pool and Grant Manager split responsibilities so balance 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 should preserve explicit reserve logic and avoid draining pool liquidity through aggressive payout cadence. If reserve utilization increases beyond expected bounds, policy recommends reducing payout aggressiveness until balance health normalizes.

High-impact parameter changes (stake thresholds, payout share, 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.

Back to Policy DocsHow it worksLaunch App