> 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/de/pots-aufbauen/governance.md).

# Governance

#### Die Philosophie der dezentralen Governance

POTS wird nicht von einem Team gesteuert. Es wird von seiner Community gesteuert — durch einen transparenten On-Chain-Prozess, der sicherstellt, dass kein einzelner Akteur die Zukunft des Protokolls einseitig bestimmen kann.

Unser Governance-Modell orientiert sich an den Best Practices von Compound, Curve und Olympus DAO und führt zugleich einen neuartigen Mechanismus ein — vIBS — der speziell für die Einschränkungen eines Protokolls entwickelt wurde, in dem Governance-Nachweise, einmal ausgegeben, nicht zerstört werden können.

{% hint style="info" %}
💡 Kernprinzip

Governance-Macht sollte langfristiges Engagement widerspiegeln, nicht die Größe des Kapitals. Wer mehr und länger stakt, erhält proportional größeren Einfluss — aber frühe Teilnehmer können das System nicht dauerhaft dominieren.
{% endhint %}

#### Was kann gesteuert werden?

Die POTS-Governance umfasst drei Bereiche:

<table><thead><tr><th width="251.8203125">Bereich</th><th>Beispiele</th></tr></thead><tbody><tr><td>Protokollparameter</td><td>Emissionsraten, Slashing-Steuersätze, RBS-Bänder, MCL-Schwellenwerte, Epochenlänge</td></tr><tr><td>Treasury-Zuteilung</td><td>Einsatz des Safety-Treasury, Strategie des PBM-Gebots-Pools, Mittelbewegungen über die Multi-Sig</td></tr><tr><td>Budget für Marktzuschüsse</td><td>Zuschüsse für die Erstellung von Prognosemärkten, Ökosystementwicklung, Community-Initiativen</td></tr></tbody></table>

#### Der Governance-Ablauf

**Schritt 1 — Forendiskussion (≥ 3 Tage)**

Alle Governance-Anträge beginnen als informelle Diskussionen im POTS-Community-Forum. Die Mindestdauer der Diskussion beträgt 3 Tage. So kann die Community Probleme identifizieren, Verbesserungen vorschlagen und einen Konsens aufbauen, bevor ein formeller Antrag eingereicht wird.

**Schritt 2 — Entwurfsantrag (Multi-Sig-Whitelist erforderlich)**

Nur Adressen auf der Multi-Sig-Whitelist der Treasury dürfen formelle Anträge bei Snapshot einreichen. Das verhindert Spam und stellt sicher, dass Anträge vor einer Community-Abstimmung von verantwortlichen Stellen geprüft werden.

{% hint style="success" %}
🔐 Warum eine Whitelist?

Eine offene Einreichung von Anträgen schafft Angriffsflächen für die Governance — böswillige Akteure können das System mit Anträgen überfluten, um die Aufmerksamkeit der Wähler zu erschöpfen. Die Whitelist stellt sicher, dass Anträge, die die Abstimmungsphase erreichen, bereits einen grundlegenden Verantwortlichkeitsfilter durchlaufen haben.
{% endhint %}

**Schritt 3 — Snapshot-Abstimmung (5-Tage-Fenster)**

Die Abstimmung erfolgt auf Snapshot — einer gaslosen Off-Chain-Abstimmungsplattform. Jede Adresse mit vIBS kann abstimmen. Das Abstimmungsfenster beträgt 5 Tage.

* Quorum: 10 % des gesamten vIBS-Angebots müssen teilnehmen, damit die Abstimmung gültig ist.
* Annahme-Schwelle: >50 % Ja-Stimmen erforderlich.
* Stimmgewicht: Proportional zum vIBS-Saldo zum Snapshot-Block.

**Schritt 4 — Timelock-Verzögerung (24 Stunden)**

Angenommene Anträge treten vor der Ausführung in einen 48-stündigen Timelock ein. Dieser Sicherheits-Puffer ermöglicht es der Community, mögliche böswillige oder fehlerhafte Anträge zu erkennen und darauf zu reagieren, die die Abstimmung möglicherweise bestanden haben.

**Schritt 5 — On-Chain-Ausführung**

Je nach Antragsart:

* Automatisierte Parameter: Direkt durch den Smart Contract ausgeführt.
* Treasury-Bewegungen: Erfordern Multi-Sig-Genehmigung (25 von 50 Unterzeichnern).

Abgelehnte Anträge kehren zur Überarbeitung und erneuten Diskussion ins Forum zurück.

#### vIBS — Der Governance-Nachweis

vIBS ist der nicht übertragbare Governance-Nachweis des POTS-Protokolls. Er wird geprägt, wenn ein Nutzer IBS stakt, und er wird niemals zerstört — auch nicht nach Ablauf der Staking-Periode.

**Prägeformel**

Wenn ein Nutzer $$N$$ IBS für $$D$$ Tage in der Protokoll-Epoche stakt $$E$$:

$$\text{vIBS}(N, D, E) = N \times \frac{D}{90} \times \alpha(E)$$

Wobei:

* $$N$$ = Menge der gestakten IBS
* &#x20;$$D$$= Sperrdauer in Tagen
* $$\frac{D}{90}$$ = Dauermultiplikator (90 Tage = 1×, 180 Tage = 2×, 360 Tage = 4×)
* $$\alpha(E)$$ = Epochen-Inflationsfaktor zum Zeitpunkt des Mintings

**Der Dauermultiplikator**

| Sperrdauer | Multiplikator $D/90$ | Beispiel: 100 IBS |
| ---------- | -------------------- | ----------------- |
| 90 Tage    | 1×                   | 100 Basis-vIBS    |
| 180 Tage   | 2×                   | 200 Basis-vIBS    |
| 270 Tage   | 3×                   | 300 Basis-vIBS    |
| 360 Tage   | 4×                   | 400 Basis-vIBS    |

#### Der Epochen-Inflationsfaktor

Da vIBS nicht zerstört werden kann, würde ein rein additves System frühe Teilnehmer dauerhaft die Governance dominieren lassen, während sich ihre vIBS anhäuft. Der Epochen-Inflationsfaktor $$\alpha(E)$$ löst dieses Problem.

**Konzept**

Jede Epoche dauert 1 Woche. Der Inflationsfaktor wächst geometrisch:

$$\alpha(E) = r^{E-1}, \quad r = 10^{1/51} \approx 1.0462$$

Das bedeutet, dass der Inflationsfaktor mit jeder neuen Epoche um ungefähr +4,62 % steigt.

**Das Verwässerungsziel**

Das System ist so kalibriert, dass bis Epoche 52 (\~1 Jahr nach dem Start):

$$\frac{\alpha(1)}{\alpha(52)} = \frac{1}{10} = 10%$$

Eine in Epoche 1 geprägte Position (also in der allerersten Woche) hat einen Inflationsfaktor von 1,0. Eine in Epoche 52 geprägte Position hat einen Inflationsfaktor von 10,0. Bei identischen Staking-Parametern ( $$N$$ IBS, $$D$$ Tage) hält die Position aus Epoche 1 genau 10 % der Stimmkraft der Position aus Epoche 52.

Dies stellt sicher, dass frühe Teilnehmer für ihr Engagement belohnt werden, aber die Governance mit dem Wachstum der Community nicht dauerhaft dominieren können.

<figure><img src="/files/2d7c5065b134f64381b118e7d80ab39f961e0fce" alt=""><figcaption></figcaption></figure>

**Numerisches Beispiel**

<table data-header-hidden><thead><tr><th width="156.2734375"></th><th width="95.9765625"></th><th width="107.88671875"></th><th width="101.30859375"></th><th width="94.51171875"></th><th></th></tr></thead><tbody><tr><td>Position</td><td>IBS</td><td>Sperre</td><td>Epoche</td><td><span class="math">\alpha(E)</span></td><td>vIBS geprägt</td></tr><tr><td>Alice (früh)</td><td>100</td><td>360 Tage</td><td>E=1</td><td>1.00</td><td>400</td></tr><tr><td>Bob (mittel)</td><td>100</td><td>360 Tage</td><td>E=26</td><td>3.16</td><td>1,265</td></tr><tr><td>Carol (spät)</td><td>100</td><td>360 Tage</td><td>E=52</td><td>10.00</td><td>4,000</td></tr></tbody></table>

In Epoche 52 repräsentieren Alices 400 vIBS 10 % von Carols 4.000 vIBS — trotz identischer Staking-Parameter. Das ist der Verwässerungsmechanismus in Aktion.

{% hint style="success" %}
📐 Warum dieses Design?

Traditionelle veToken-Modelle (Curve, Convex) lösen Verwässerung durch Zeitverfall: Deine Stimmkraft nimmt ab, je näher das Ende deiner Sperre rückt. POTS kann diesen Mechanismus nicht nutzen, weil vIBS rückwirkend ausgegeben wird und nicht zerstört werden kann. Der Epochen-Inflationsfaktor erreicht denselben wirtschaftlichen Effekt — die schrittweise Verwässerung früher Positionen — auf einem anderen mathematischen Weg.
{% endhint %}

#### Governance-Parameter

| Parameter                     | Symbol   | Anfangswert                  | Governance              |
| ----------------------------- | -------- | ---------------------------- | ----------------------- |
| Epochenlänge                  | $$\tau$$ | 1 Woche                      | durch die DAO anpassbar |
| Wachstumsrate der Inflation   | $$r$$    | $$10^{1/51} \approx 1.0462$$ | durch die DAO anpassbar |
| Verwässerungsziel (Epoche 52) | —        | 10%                          | durch die DAO anpassbar |
| Mindest-Forendiskussion       | —        | 3 Tage                       | durch die DAO anpassbar |
| Abstimmungsfenster            | —        | 5 Tage                       | durch die DAO anpassbar |
| Quorum-Schwelle               | —        | 10 % des gesamten vIBS       | durch die DAO anpassbar |
| Annahme-Schwelle              | —        | >50 % Ja                     | durch die DAO anpassbar |
| Timelock-Verzögerung          | —        | 48 Stunden                   | durch die DAO anpassbar |
| Multi-Sig-Schwelle            | —        | 25 von 50                    | durch die DAO anpassbar |

> Alle Parameter unterliegen der DAO-Governance. Siehe die Parameter-Referenztabelle.
