Several patterns and approaches involve admin keys or upgrade mechanisms (white-label deployments, Privacy L2 operators, token issuers with freeze/blacklist). None currently document what the admin key is prevented from doing — the immutable guarantees that hold even if the operator is hostile.
End users and auditors need to understand: "what does the math prevent, even if the institution wanted to?"
Deliverables
New pattern: pattern-immutable-guarantees.md
- Intent: Define and enforce on-chain constraints that no admin key, upgrade, or governance action can bypass
- Ingredients: Immutable contract logic, constrained proxy patterns, timelocked upgrades with exit windows, nullifier-based ownership proofs
- Protocol: How to separate mutable operational parameters (fee rates, compliance lists) from immutable safety invariants (ownership, withdrawal rights, privacy guarantees)
- Guarantees: Specific properties that survive hostile upgrades — e.g., "no upgrade can prevent withdrawal", "no admin action can reveal shielded balances"
- Trade-offs: Reduced operational flexibility, upgrade complexity, regulatory tension (regulators may want override capability)
Update CHANGELOG.md
Several patterns and approaches involve admin keys or upgrade mechanisms (white-label deployments, Privacy L2 operators, token issuers with freeze/blacklist). None currently document what the admin key is prevented from doing — the immutable guarantees that hold even if the operator is hostile.
End users and auditors need to understand: "what does the math prevent, even if the institution wanted to?"
Deliverables
New pattern:
pattern-immutable-guarantees.mdUpdate CHANGELOG.md