Summary
This proposal formalizes a phased upgrade: expand the existing Cap Guardian model to cover more parameter types, bolt on automated circuit breakers for oracle and liquidation events, and chart a longer-term path toward a full Risk Oracle integration. Governance still sets the guardrails and Anthias doesn’t go anywhere.
Motivation
Moonwell now spans Base, Optimism, and Moonbeam, managing complex assets including BTC derivatives, Morpho Vaults, and OEV wrappers. Current governance systems involve monthly parameter votes where Anthias Labs proposes changes and the community votes on execution. This proposal is meant to introduce a complementary set of structural changes: automated oracle circuit breakers that pause markets when prices look obviously broken, and delegated authority for routine parameter adjustments within governance-approved bounds. Both mechanisms maintain full governance control through transparent logging and clear limits.
Specification
Three phases. The first two can move on existing infrastructure. The third is a longer-term DAO decision.
Phase 1: Expand the Risk Steward Model
The Cap Guardian already proves the concept works. A delegated role, bounded authority, no full governance vote required for each individual action. We extend the same logic to parameters beyond supply and borrow caps.
Reserve factors adjustable within governance-defined floors and ceilings. Interest rate model parameters (kink, base rate, multipliers) adjustable within governance-approved ranges.
To show what “bounded” means concretely, here are example guardrails:
For USDC: interest rate adjustable between 1% and 10% total, with individual changes capped at ±1 percentage point, rate-limited to once per week. For ETH and BTC: interest rate adjustable between 2% and 8% total, with changes capped at ±1.5 percentage points, also once per week. For all assets: reserve factors adjustable between 10% and 30% total, with changes capped at ±2 percentage points per adjustment.
These ranges are illustrative examples only. Anthias Labs will propose the final specific bounds during Phase 1 specification, informed by detailed risk analysis. Final bounds will be voted on by governance.
Collateral factors are deliberately excluded because changes to collateral factors affect user liquidation risk. That level of risk merits direct governance review each time, with no exceptions.
All adjustments would be rate-limited on-chain with a cooldown per asset and a cap on how much can change at once.
Every change made under this expanded authority gets logged on-chain and reported to the forum within 48 hours. Anything outside pre-approved bounds goes through the full governance process, no exceptions. Under this model, Anthias’s role would evolve from recommending parameter changes that governance then votes on individually, to executing adjustments directly within governance-approved frameworks. The analytical work stays the same, what changes is the execution path and response time.
Phase 1 should require new guardian smart contracts for each parameter type, similar to the existing Cap Guardian architecture. Lunar Labs will need to confirm the technical requirements and audit scope early so we know what we’re committing to. The governance design, defining per-asset ranges, reporting requirements, and override authority, can proceed in parallel.
Security and Failsafes
Delegating authority to Anthias Labs creates security considerations, particularly around private key management and compromise scenarios. Security procedures, key rotation policies, and failsafe mechanisms (e.g., automatic parameter resets, emergency governance intervention) will be detailed during Phase 1 specification and reviewed by Lunar Labs as part of the implementation audit.
Phase 2: Oracle and Liquidation Safeguards
Three automated mechanisms:
Oracle Circuit Breaker: If an oracle price deviates beyond a defined threshold from a secondary reference or established historical range, the affected market pauses automatically. A circuit breaker / threshold check catches price deviations before a human has to .
However, not every case will be that clean. A 30% drop could be a broken oracle or a real crash, and on-chain they look the same. Pausing is safer for oracle errors. Letting liquidations run is safer for real crashes. The circuit breaker design needs to specify which way it defaults when the signal is unclear.
The implementation will be scoped per-asset-category during Phase 2 specification, as different asset types have different oracle characteristics and failure modes. Stablecoins, major caps, bridge-wrapped assets, and derivative tokens each require tailored detection logic. Each circuit breaker will be implemented as a separate smart contract to avoid code size constraints in the Comptroller. This also allows circuit breakers to be deployed and voted on independently based on community priorities.
Liquidation Cascade Circuit Breaker: If liquidation volume in a single market exceeds a defined threshold within a time window, new liquidations in that market pause pending review.
Deployment Validation: Before any new market goes live, the oracle configuration should pass a structured review, not just a sanity check on whether the price looks right. At minimum this should include: a written justification for why the chosen oracle type (market-price, exchange-rate, proof-of-reserves) is the right fit for the asset’s risk profile; an explicit disclosure of the failure modes that oracle type cannot detect; and confirmation that the oracle’s trust surface is independent from the asset’s own. An oracle that depends on the same bridge or infrastructure the asset depends on can fail at exactly the moment it matters most.
Phase 2 needs smart contract development and a proper audit. I’d specifically like Lunar Labs’ input here on technical feasibility and how this interfaces with the existing OEV wrapper architecture before we scope the build.
Phase 3: Full Risk Oracle Integration
The model described in Phases 1 and 2 represents an intermediate step toward a more mature risk management system, where parameter adjustments can occur continuously within governance-approved bounds rather than through periodic proposals.
At a more advanced level, this would involve formalizing a framework where:
- governance defines parameter ranges and guardrails
- risk contributors define the operating logic within those bounds
- and adjustments can be executed in near real-time, subject to transparency and the ability for governance to intervene
A more natural path would be to expand the mandate of our existing risk contributors such as Anthias Labs, allowing them to move from periodic recommendations toward supervising a continuous, framework-driven risk system.
This would represent an evolution of the current model, rather than a replacement. The DAO would continue to define the boundaries, while risk contributors operate within them.
Reaching this stage would require:
- additional infrastructure and smart contract design
- clear governance-approved parameter boundaries
- and alignment on oversight, reporting, and intervention mechanisms
Conclusion
This proposal introduces three complementary mechanisms to strengthen Moonwell’s risk management: delegated authority, oracle circuit breakers, and liquidation safeguards. Each is bounded, transparent, and subject to governance control. The phased approach allows the community to evaluate each component independently. We welcome feedback on guardrail calibration, sequencing, and implementation priorities.