> For the complete documentation index, see [llms.txt](https://docs.pots.money/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.pots.money/building-pots/governance.md). # Governance #### The Philosophy of Decentralized Governance POTS is not governed by a team. It is governed by its community — through a transparent, on-chain process that ensures no single actor can unilaterally direct the protocol's future. Our governance model draws from the best practices of Compound, Curve, and Olympus DAO, while introducing a novel mechanism — vIBS — designed specifically for the constraints of a protocol where governance credentials, once issued, cannot be destroyed. {% hint style="info" %} 💡 Core Principle Governance power should reflect long-term commitment, not capital size. Those who stake more, and stake longer, earn proportionally greater influence — but early participants cannot permanently dominate the system. {% endhint %} #### What Can Be Governed? POTS governance covers three domains:
DomainExamples
Protocol ParametersEmission rates, slashing tax rates, RBS bands, MCL thresholds, epoch duration
Treasury AllocationSafety Treasury deployment, PBM bid pool strategy, multi-sig fund movements
Market Grant BudgetGrants for prediction market creation, ecosystem development, community initiatives
#### The Governance Flow **Step 1 — Forum Discussion (≥ 3 Days)** All governance proposals begin as informal discussions on the POTS community forum. The minimum discussion period is 3 days. This allows the community to identify issues, suggest improvements, and build consensus before a formal proposal is submitted. **Step 2 — Draft Proposal (Multi-sig Whitelist Required)** Only addresses on the treasury multi-sig whitelist may submit formal proposals to Snapshot. This prevents spam and ensures that proposals are reviewed by accountable parties before reaching a community vote. {% hint style="success" %} 🔐 Why a whitelist? Open proposal submission creates governance attack surfaces — malicious actors can flood the system with proposals to exhaust voter attention. The whitelist ensures that proposals reaching the vote stage have already passed a basic accountability filter. {% endhint %} **Step 3 — Snapshot Voting (5-Day Window)** Voting is conducted on Snapshot — a gasless, off-chain voting platform. Any address holding vIBS may vote. The voting window is 5 days. * Quorum: 10% of total vIBS supply must participate for the vote to be valid. * Pass Threshold: >50% Yes votes required. * Voting Weight: Proportional to vIBS balance at the snapshot block. **Step 4 — Timelock Delay (24 Hours)** Passed proposals enter a 48-hour timelock before execution. This security buffer allows the community to identify and respond to any malicious or erroneous proposals that may have passed the vote. **Step 5 — On-Chain Execution** Depending on the proposal type: * Automated parameters: Executed directly by smart contract. * Treasury movements: Require multi-sig approval (25-of-50 signers). Rejected proposals return to the forum for revision and re-discussion. #### vIBS — The Governance Credential vIBS is the non-transferable governance credential of the POTS protocol. It is minted when a user stakes IBS, and it is never destroyed — even after the staking period ends. **Minting Formula** When a user stakes $$N$$ IBS for $$D$$ days at protocol Epoch $$E$$: $$\text{vIBS}(N, D, E) = N \times \frac{D}{90} \times \alpha(E)$$ Where: * $$N$$ = amount of IBS staked * $$D$$= lock duration in days * $$\frac{D}{90}$$ = duration multiplier (90 days = 1×, 180 days = 2×, 360 days = 4×) * $$\alpha(E)$$ = epoch inflation factor at the time of minting **The Duration Multiplier** | Lock Duration | Multiplier $D/90$ | Example: 100 IBS | | ------------- | ----------------- | ---------------- | | 90 days | 1× | 100 base vIBS | | 180 days | 2× | 200 base vIBS | | 270 days | 3× | 300 base vIBS | | 360 days | 4× | 400 base vIBS | #### The Epoch Inflation Factor Because vIBS cannot be destroyed, a purely additive system would allow early participants to permanently dominate governance as their vIBS accumulates. The Epoch Inflation Factor $$\alpha(E)$$ solves this. **Design** Each Epoch lasts 1 week. The inflation factor grows geometrically: $$\alpha(E) = r^{E-1}, \quad r = 10^{1/51} \approx 1.0462$$ This means each new Epoch, the inflation factor increases by approximately +4.62%. **The Dilution Target** The system is calibrated so that by Epoch 52 (\~1 year after launch): $$\frac{\alpha(1)}{\alpha(52)} = \frac{1}{10} = 10%$$ A position minted at Epoch 1 (the very first week) has an inflation factor of 1.0. A position minted at Epoch 52 has an inflation factor of 10.0. For identical staking parameters ( $$N$$ IBS, $$D$$ days), the Epoch-1 position holds exactly 10% of the voting power of the Epoch-52 position. This ensures that early participants are rewarded for their commitment, but cannot permanently dominate governance as the community grows.
**Numerical Example**
PositionIBSLockEpoch\alpha(E)vIBS Minted
Alice (early)100360dE=11.00400
Bob (mid)100360dE=263.161,265
Carol (late)100360dE=5210.004,000
At Epoch 52, Alice's 400 vIBS represents 10% of Carol's 4,000 vIBS — despite identical staking parameters. This is the dilution mechanism in action. {% hint style="success" %} 📐 Why this design? Traditional veToken models (Curve, Convex) solve dilution through time-decay: your voting power decreases as your lock approaches expiry. POTS cannot use this mechanism because vIBS is issued retroactively and cannot be destroyed. The Epoch Inflation Factor achieves the same economic outcome — progressive dilution of early positions — through a different mathematical path. {% endhint %} #### Governance Parameters | Parameter | Symbol | Initial Value | Governance | | -------------------------- | -------- | ---------------------------- | -------------- | | Epoch duration | $$\tau$$ | 1 week | DAO-adjustable | | Inflation growth rate | $$r$$ | $$10^{1/51} \approx 1.0462$$ | DAO-adjustable | | Dilution target (Epoch 52) | — | 10% | DAO-adjustable | | Minimum forum discussion | — | 3 days | DAO-adjustable | | Voting window | — | 5 days | DAO-adjustable | | Quorum threshold | — | 10% of total vIBS | DAO-adjustable | | Pass threshold | — | >50% Yes | DAO-adjustable | | Timelock delay | — | 48 hours | DAO-adjustable | | Multi-sig threshold | — | 25-of-50 | DAO-adjustable | > All parameters are subject to DAO governance. See the Parameter Reference Table.