Lifecycle Operations

This page covers operating an existing fixed-rate reserve over its lifecycle: making parameter changes, what’s mutable vs. immutable, and how to wind a reserve down when it’s no longer needed.

​

Updating an existing fixed-rate reserve

The general reserve-update flow at Reserve Management applies — download config, edit, preview, apply. A few constraints are specific to fixed-rate reserves:

​

Sunsetting a fixed-rate reserve

Two patterns:

​

Soft sunset — gradual wind-down

Set debt_maturity_timestamp to a future date. New borrows are blocked from that moment; existing borrows continue running. As they hit their per-borrow term ends, they roll, repay, or get protocol-liquidated. Once the reserve maturity hits and mature_reserve_debt_liquidation_enabled is on, any remaining debt becomes fully liquidatable with no throttle. This is the normal path. It gives existing borrowers fair notice and lets the reserve unwind through normal maturity flow.

​

Hard sunset — immediate stop

Set the reserve status to Inactive (1) — blocks all new operations. Existing debt remains and must wind down through normal repayment, rollover (if pointed elsewhere), or liquidation paths. Use this only when the reserve must stop serving new borrowers immediately for risk reasons. Hard sunset is a circuit breaker — reach for it only when there’s an active reason to halt activity, because it prevents borrowers from rolling within the reserve.

​

Operational notes

• Lock time. Reserve config updates typically have a ~4-hour lock between commitment and on-chain effect. Plan parameter changes around testing windows.
• Simulate first. Always use --mode inspect before --mode execute. The simulation will surface invalid parameter combinations (e.g. attempts to shorten an active reserve’s term) before they hit the chain.
• Rate changes don’t affect existing borrows. This is a feature, not a bug — borrowers locked in a rate keep that rate. Adjust rates expecting the change to flow through over time as positions turn over.
• Rollover-in-elevation-groups is unsupported. Borrowers using elevation modes (eMode) on the market cannot have their fixed-term positions rolled over. If your market makes heavy use of eMode, expect those positions to require manual repayment at maturity.
• The withdrawal queue requires the kvault program to be on a recent version. Vaults integrating with your market need their kvault upgraded before they can interact with FR reserves correctly. Coordinate the rollout with vault curators.
• Penalty interest accrues to protocol fees on the debt reserve, not to the lender side. The early-repay penalty design protects lenders by discouraging premature exits but doesn’t directly compensate them.

​

What’s next