Security & Risk
Deposit-cap roadmap
Caps bound the maximum damage while the protocol earns trust, and rise on public criteria.
Every basket has a supply cap. Caps exist to bound the maximum damage while the protocol is unaudited and to bound aggregate exposure to issuer risk. They are a feature of the launch, not an embarrassment to hide.
Governance rails
- Every raise is a
setSupplyCapguardian transaction from the Safe, public on Blockscout, requiring explicit human sign-off. - The contract enforces an immutable per-basket ceiling (
maxSupplyCap, 1M tokens ≈ $100M at launch prices). No raise can ever exceed it: not by the guardian, not by anyone. - Raises never front-run their criteria. Lowering a cap is always allowed and never affects redemption or existing holders.
The phases
| Phase | Cap per basket | Unlock criteria |
|---|---|---|
| 1: Launch | $100K (≈1,000 tokens) | Mainnet launch. (current) |
| 2: Traction | $500K | Cap utilization > 80% sustained for 2 weeks and 250+ holders on the basket. |
| 3: Audited | $2M | Professional security audit completed and published, findings addressed. |
| 4: Scale | $10M+ | Progressive raises with demand; each step reviewed against issuer-risk exposure and on-chain liquidity of the constituents. |
Utilization and holder counts are measured from public on-chain data (Blockscout / Dune), so anyone can verify a raise met its criteria.
What a cap does (and doesn't) do
| Caps do | Caps don't |
|---|---|
Block mints that would push supply above the cap (SupplyCapExceeded) | Ever gate redemption: you can always exit a capped or paused basket |
| Bound the maximum TVL at risk while unaudited | Affect the backing of existing tokens |
| Apply equally to curated baskets (same guardian, same roadmap, 1,000-token starter cap) | Expire on their own: every raise is an explicit, public decision |