Skip to main content

Security Architecture

Early iterations of the protocol relied on a very open governance process that prioritised flexibility over defence-in-depth. Over time we have moved towards a security-first posture and introduced multiple layers of protection for token supply and treasury operations.

Layers of Defence (current system)​

1. Supply-rate locks (CHA)​

Minting or burning CHA is limited to 1 token per 1 440 Bitcoin blocks. The logic is enforced on-chain and cannot be bypassed, even by administrators.

2. Multi-sig governance​

All critical functions (Rulebook limits, CHA cooldown, treasury moves) require a 3-of-4 multi-signature from Rozar, Kraqen, MooningShark and Vinzo. No single key can unilaterally change parameters or move funds.

3. Rulebook middleware​

Every EXP, ENERGY and DMG operation must be routed through the Rulebook contract, which:

  • checks the caller against a verified-interaction whitelist,
  • applies read-only status-effect modifiers,
  • enforces per-operation hard caps before forwarding to the token.

4. Verified-interaction whitelist​

Only pre-approved engines (e.g. Hold-to-Earn, meme engines, fatigue system) can invoke Rulebook functions. The list is governed by the same multi-sig and is auditable on-chain.

5. Read-only status effects​

Perks like Energetic Welsh or Raven Wisdom cannot mint or burn tokens; they purely return adjusted numbers, which are still clamped by Rulebook limits.

6. On-chain ceilings​

Caps such as max-reward, max-mint, etc. are stored in data-vars. Any change triggers an on-chain event and must pass the multi-sig.

7. Open-source & peer reviewed​

All contracts are open-source and visible on chain explorers. External peer reviews are scheduled before major upgrades; minor parameter tweaks are traceable via transaction history.

These overlapping controls—rate-limits, multi-sig, middleware, whitelists and transparent code—combine to deliver a robust, defence-in-depth security architecture.