Summary
This proposal recommends the initial deployment parameters for the Venus Risk Stewards framework. The Risk Stewards system enables routine risk parameter updates - supply/borrow caps, collateral factors, and interest rate models - to be applied without requiring a full governance cycle, while preserving safety through configurable timelocks, debounce periods, and safe-delta thresholds.
Proposed Configuration
| Parameter | Safe Delta | Debounce | Timelock |
|---|---|---|---|
| Supply Cap | 50% (5000 bps) | 24 hours | 6 hours |
| Borrow Cap | 50% (5000 bps) | 24 hours | 6 hours |
| Collateral Factors | 5% (500 bps) | 48 hours | 6 hours |
| Interest Rate Model | N/A (always timelocked) | 72 hours | 6 hours |
Key definitions:
-
Safe Delta: The maximum change (relative to the current value) that can execute immediately without a timelock. Changes exceeding this threshold are registered and subject to the timelock period before execution.
-
Debounce: The minimum time that must elapse after the last executed update before a new update of the same type can be registered for the same market.
-
Timelock: The waiting period between when a non-safe update is registered on-chain and when it becomes eligible for execution by a whitelisted executor.
Motivation
The Problem: Governance Bottleneck for Routine Updates
Today, every risk parameter change on Venus - no matter how routine - must go through the full governance cycle: proposal submission, voting period, and timelock execution. While this process provides strong safety guarantees, it introduces significant latency for operational adjustments that risk managers need to make regularly.
Market conditions move fast. A sudden increase in deposit demand may require raising a supply cap promptly. A shift in asset volatility may warrant adjusting borrow caps. Interest rate curves may need recalibration as utilization patterns change. In each case, the multi-day governance cycle creates a gap between when a change is needed and when it takes effect.
The Solution: Delegated Authority with Safety Rails
The Risk Steward framework addresses this by creating a controlled delegation path for specific risk parameter updates. Rather than bypassing governance, it operates within a governance-approved envelope:
-
Governance defines the boundaries - the safe delta thresholds, debounce periods, and timelock durations are set by governance and can only be changed by governance.
-
The Risk Oracle proposes updates - a trusted off-chain risk engine publishes parameter recommendations on-chain.
-
The Risk Steward validates and applies - smart contracts enforce the configured safety constraints before any parameter is modified.
-
Governance retains override authority - the system can be paused, individual update types can be deactivated, and pending timelocked updates can be rejected by whitelisted executors at any time.
For changes that fall outside the Risk Steward’s approved envelope - large parameter shifts, new market listings, emergency actions - the existing governance process and Guardian multisig remain the appropriate venues.
Rationale
Supply Cap - Safe Delta: 50%, Debounce: 24h, Timelock: 6h
Why 50% safe delta: Supply caps represent an upper ceiling on deposits - they do not directly affect protocol solvency or trigger liquidations. Raising a supply cap allows more deposits but does not force any user action; lowering a cap prevents new deposits but does not impact existing positions. A 50% safe delta permits the risk team to make meaningful operational adjustments in a single immediate update - whether scaling up a growing market or reducing exposure to a declining asset. The blast radius of cap changes does not materially differ between a narrower and wider threshold, as caps are ceiling parameters that do not directly affect existing positions. This threshold is wide enough to handle routine market growth and reduce governance load, while the debounce period ensures that sequential changes remain bounded and detectable.
Why 24h debounce: A 24-hour debounce ensures that at most one supply cap update per market can be applied per day. This limits the compounding effect of sequential safe-delta changes. At 50% per day, a cap starting at 1M would take 3 days of consecutive maximum increases to reach ~3.375M - a trajectory that governance and risk monitoring can detect and intervene on well before it becomes problematic.
Why 6h timelock: Supply caps are the least solvency-sensitive of the four parameters. A 6-hour timelock provides sufficient time for the Venus team and whitelisted executors to review and potentially reject proposed changes exceeding the safe delta, while enabling more nimble responses to market conditions. This does not change the trust assumptions around the Risk Steward - timelocked updates are still only executable by Venus whitelisted executors after review. The shorter timelock also provides a very generous execution window (up to 42 hours for processing and execution combined), virtually eliminating the risk of updates expiring before they can be applied.
Borrow Cap - Safe Delta: 50%, Debounce: 24h, Timelock: 6h
Why 50% safe delta: Borrow caps, like supply caps, are a ceiling - they limit how much can be borrowed from a market but do not directly affect existing positions. The same 50% threshold applies: routine adjustments can be made immediately, while larger changes require a timelock review period. It is important to note that the most risk-on action - making a collateral-only market borrowable (0 borrow cap to a nonzero value) - cannot be performed by the Risk Steward, as the safe delta is relative and a percentage change from zero is undefined.
Why 24h debounce: Same rationale as supply caps - one update per market per day limits compounding risk while keeping the system responsive.
Why 6h timelock: While borrow caps carry slightly more risk than supply caps - increasing a borrow cap allows more leverage against the protocol’s collateral pool - the 6-hour timelock provides adequate time for the Venus team to evaluate and potentially reject large changes. The primary rate-limiting protection for caps comes from the debounce period (ensuring at most one change per day) and the safe delta (ensuring small changes execute immediately while large ones are timelocked). The 6-hour review window is sufficient for whitelisted executors to inspect proposed changes, and the generous 42-hour execution window ensures operational reliability.
Collateral Factors - Safe Delta: 5%, Debounce: 48h, Timelock: 6h
Why 5% safe delta: 5% safe delta is a balance between conservative and a practical approach. As the changes are relative a safe delta too small would render the risk steward unusable for exotic assets. On the other hand, collateral factors directly determining how much a user can borrow against their deposited assets and at what point positions become eligible for liquidation, even small changes can have significant consequences. A 2% absolute reduction in collateral factor on a large market can push leveraged positions into liquidation. In practice, any meaningful collateral factor changes will go through a rigorous process, a post on the forum, checking affected positions and getting the full timelock for larger updates, which is the intended behavior for this solvency-critical parameter.
Why 48h debounce: Collateral factor changes should be infrequent and carefully considered. A 48-hour debounce ensures at most one update every two days per market, preventing rapid sequential adjustments that could compound into material collateral ratio shifts. The conservative debounce also reflects that collateral factor changes typically respond to structural shifts in asset risk profiles, not short-term market movements.
Why 6h timelock: The 5% safe delta already ensures that only small “fine-tuning” changes bypass the timelock. Any change exceeding this tight threshold - which includes virtually all operationally significant CF adjustments - will sit in the timelock for 6 hours, providing time for the Venus team and whitelisted executors to review and, if needed, reject the update. Larger or more sensitive CF changes (such as setting initial collateral factors for new markets or making substantial adjustments) remain the domain of full governance proposals, not the Risk Steward. The collateral factor’s primary safety guardrails are its tight safe delta and long debounce, not the timelock duration.
Interest Rate Model - Safe Delta: N/A, Debounce: 72h, Timelock: 6h
Why no safe delta (always timelocked): Unlike the other parameters, IRM updates replace the entire interest rate model contract for a market. There is no numerical “delta” to compare - a new IRM contract could contain any rate curve logic, making automated safety assessment infeasible on-chain. Every IRM update therefore goes through the full timelock without exception. This is hardcoded in the IRMRiskSteward contract itself.
Why 72h debounce: Interest rate model changes are the highest-impact updates in this framework. A new IRM affects every borrower and lender in a market, altering rates across the entire utilization curve. The 72-hour (3-day) debounce ensures that once an IRM is updated, the market has a meaningful stabilization period before another change can even be proposed. This prevents rapid IRM churn that could confuse market participants, destabilize utilization patterns, or mask the effects of a previous change before they can be properly assessed.
Why 6h timelock: Every IRM update must pass through the timelock regardless of magnitude. The 6-hour period provides time for the Venus team and whitelisted executors to inspect the new IRM contract - verifying its rate curve parameters, checking for unexpected behavior, and confirming it aligns with the risk oracle’s published rationale - before it can be applied. The 72-hour debounce serves as the primary safety throttle for IRM changes, ensuring that updates are infrequent and deliberate regardless of the timelock duration.
Practical Considerations
Update Lifecycle and Execution Windows
Each update published by the Risk Oracle has a 48-hour expiration window (the UPDATE_EXPIRATION_TIME constant in the contract). A timelocked update must be both registered on-chain and executed within this window. This creates operational timing constraints that informed our timelock recommendations:
How the lifecycle works for timelocked updates:
-
The Risk Oracle publishes an update off-chain (at time T=0)
-
A bot or keeper calls
processUpdate()to register the update on-chain (at time T=P) -
The update’s timelock begins counting from the registration time
-
After the timelock elapses, a whitelisted executor calls
executeRegisteredUpdate()to apply it -
The update must be executed before T=48h or it expires and can no longer be applied
Registration deadline and execution window:
The update must be registered early enough that the timelock can complete before expiration. This means registration must occur within 48h - timelock of the oracle publishing the update. Once registered, the execution window spans from timelock completion until expiration.
| Parameter | Timelock | Max Registration Delay | Execution Window (if registered promptly) |
|---|---|---|---|
| Supply Cap | 6h | 42h | up to 42h |
| Borrow Cap | 6h | 42h | up to 42h |
| Collateral Factors | 6h | 42h | up to 42h |
| Interest Rate Model | 6h | 42h | up to 42h |
With a uniform 6-hour timelock across all parameters, there is a generous 42-hour processing window and up to 42 hours for execution. This virtually eliminates the operational risk of updates expiring before they can be registered or executed, significantly simplifying keeper infrastructure requirements compared to tighter execution windows.
Safe-Delta Updates Execute Immediately
When a parameter change falls within the safe delta threshold, it executes in a single transaction - no timelock, no executor step, no execution window concern. The bot calls processUpdate() and the change is applied atomically. This is the expected path for the majority of routine cap adjustments, making the system highly responsive for day-to-day operations.
Safety Mechanisms
The Risk Steward framework includes multiple layers of protection beyond the timelock and debounce:
-
Rejection: Whitelisted executors can call
rejectUpdate()at any time during the timelock period to permanently cancel a pending update. -
Pause: The entire system can be paused via
setPaused(), immediately halting all new update processing. -
Config deactivation: Individual update types can be disabled via
setConfigActive()without affecting others. -
Expiration: Updates that are not executed within 48 hours automatically expire and cannot be applied.
-
Governance override: All Risk Steward configuration parameters (safe delta, debounce, timelock, whitelisted executors) are controlled by governance and can be adjusted or revoked at any time.
-
Complementary mechanisms: For scenarios outside the Risk Steward’s envelope - emergency parameter changes, new market listings, large structural adjustments - the Guardian multisig and full governance process remain available and unaffected.
Debounce Behavior
The debounce period begins counting from the moment the previous update was executed on-chain, not from when it was registered. This means the debounce enforces a minimum gap between applied changes - ensuring the protocol has time to observe the effects of one update before the next can be submitted. The debounce is the primary rate-limiter for routine updates flowing through the safe-delta path, where changes are applied immediately without a timelock.
For scenarios requiring more rapid sequential changes - such as emergency deleveraging or responding to acute market stress - the Risk Steward is not the appropriate tool. These situations should be handled through the Guardian multisig or an expedited governance process, which are not subject to the Risk Steward’s debounce constraints.
Conclusion
The proposed parameters establish a graduated risk framework: supply and borrow caps receive the most operational flexibility with wider safe deltas as non-solvency-critical ceiling parameters, while collateral factors and interest rate models are subject to tighter thresholds and longer cooling periods reflecting their direct impact on protocol solvency. A uniform 6-hour timelock across all parameters enables nimble responses while preserving the review-and-reject mechanism for the Venus team. The primary safety differentiation between parameter types is achieved through their safe deltas and debounce periods rather than timelock duration. The Risk Steward system does not replace governance - it complements it by handling the routine adjustments that currently consume governance bandwidth, while preserving full governance authority over the framework’s configuration and the ability to pause, reject, or override at any time.