Admin & governance
Every protocol has admin powers. Most make you read the bytecode to find them. This page is the complete inventory — what the admin can do, what it structurally cannot, and how those powers get caged for mainnet.
What is immutable — for everyone, forever
These are code-level guarantees, not policies:
- Market bindings are write-once. A market's vault, synth, and decimals freeze at first registration. No owner can re-point live receipts at a different vault or re-denominate their debt. Your claim's plumbing cannot move under you.
- Burning spends allowance. Even the authorized burner cannot destroy lUSD you haven't approved. Redemption is always your signature.
- Disabling a market never traps funds. The mint switch stops new deposits only; the redeemer deliberately ignores it. There is no configuration state in which you cannot exit.
- Fee ceilings are constants: performance fee ≤ 20% (5% today), marketplace fee ≤ 5% (0% today). No owner can set 100% and confiscate via fees.
What the admin can do
Full transparency, including the uncomfortable parts:
| Power | Blast radius |
|---|---|
| Grant/revoke minter & burner roles | Critical — a malicious grant could mint unbacked lUSD |
| Swap the vault's yield adapter | Critical — migration moves all collateral; a malicious adapter is a drain |
| Rotate periphery (registry / manager / redeemer) | High — the upgrade path; also an attack path if the key is hostile |
| Register new markets, tune ratios & delays | Medium — new-market params; existing receipts keep their recorded terms |
| Set fees within caps, change fee recipient | Low — bounded by the constants above |
| Disable/enable minting per market | Low — cannot trap funds (see above) |
Where those powers live today — and at mainnet
Today (testnet): a single deployer key holds every owner role. That is an acceptable posture for test funds and an unacceptable one for real funds — we say so in our own published review rather than waiting for someone else to.
At mainnet, before any deposit:
- Every
owner()moves to a multisig with hardware-backed signers. - A timelock (24–72h) fronts the critical-radius functions — role grants, adapter swaps, market registration — so any change is visible on-chain days before it can execute.
- The only fast-path action is disabling mints, which can never trap funds.
- On-chain monitoring watches every role and configuration event, with public alerting, so "watch the admin" is a service, not a chore.
The step-by-step launch checklist, including these items, is published in the audit report. Governance beyond the multisig — including any $LOOM voting — will be documented here when it is real, not before.