Immutable Rules

The shortest list of rules PB is supposed to obey, regardless of market cycle, narrative, or operator preference.

What This Page Is For

This page is not a manifesto and not a marketing summary. It is the plain-English constraint set serious readers can use to judge the contracts, the UI, and future claims.

Supply and Position Structure

I-01

PB supply is fixed at genesis

The protocol is designed around a fixed 21 million PB supply. No discretionary inflation should exist after deployment.

I-02

Locked exposure is represented separately

Liquid PB, locked PBc, and per-position PBt tracking exist for different purposes and should not be blurred in documentation or UI.

I-03

PBt tracks position state

Entry price, next unlock index, and remaining locked claim are position-level state, not a frontend estimate.

Backing and Vault Discipline

I-04

Vault reserve must cover outstanding PBc obligations

Vault-held PB should remain sufficient to honor remaining PBc claims. Surplus may exist, but reserved backing should not be silently consumed.

I-05

LP contribution is phase-dependent

Liquidity contribution is allowed only while the vault retains surplus beyond what is needed for outstanding PBc backing.

I-06

Phase transition is rule-based

The protocol should move from distribution behavior to reserve-preservation behavior automatically, not by operator discretion.

Unlock and Settlement Mechanics

I-07

Unlock progression is price-based, not time-based

Unlocks happen because price reaches the required threshold, not because a date arrived.

I-08

Each unlock settles a deterministic tranche

The unlock schedule follows a fixed rule on the remaining PBc claim. It is not operator-adjusted per user.

I-09

Internal netting should precede unnecessary AMM routing

When an eligible buy can settle existing unlocks internally, the protocol should prefer that route before the AMM leg.

I-10

Dust is the only natural endpoint

Positions do not have a calendar expiration. They converge through repeated unlocks until only dust remains.

Trust Model

I-11

No admin control after deployment

The core trust claim is that nobody can later freeze, pause, remint, or rewrite the rules through privileged access.

I-12

No upgrade path should change the mechanism

If the protocol is presented as immutable, the live deployment path must not rely on upgradeable control.

I-13

Locked positions are intentionally constrained

PB's anti-dump design depends on position constraints being enforced consistently, not softened through side channels.

I-14

Frontend claims should match contract reality

If the UI says something is guaranteed, that guarantee should come from code, not just confidence in the copy.

How to Use This Page