Proposed Risk Stewards Framework for More Efficient Risk Management

We propose introducing a Risk Stewards framework for Venus Protocol, applicable to Venus markets on each supported chain, with the goal of improving how risk parameter changes are identified, reviewed, and executed.

Today, many risk parameter updates require the same governance process regardless of scope or urgency. This proposal outlines a more flexible approach, where different types of risk changes follow different review and execution paths. This framework represents the intended scope to be proposed for a future VIP vote, and we are sharing it now to gather community feedback before development proceeds.


1. Existing Problems

Venus’ current risk management process is largely reactive and operationally heavy.

Risk parameter changes are typically initiated only after issues are identified, rely on a single external risk manager, and require a full VIP process even for minor adjustments. This can lead to slower responses to changing market conditions and unnecessary overhead for low-impact updates.

Additionally, all changes are handled in the same way, regardless of severity, making it difficult to scale risk management as the protocol grows.

2. How the Risk Stewards Framework Addresses These Problems

The Risk Stewards framework introduces a more flexible and proactive approach to risk management.

Approved risk managers (“Risk Stewards”) can propose changes to specific risk parameters when market conditions warrant it, without waiting for issues to be flagged internally. Changes are categorised by scope and severity, with different review and execution paths depending on the type of parameter being adjusted.

This allows smaller, well-bounded changes to be handled more efficiently, while ensuring that higher-impact changes still receive appropriate oversight.

3. Benefits to Users

  • Faster adaptation to changing market conditions
  • More proactive risk management across Venus markets
  • Reduced governance overhead for routine parameter updates
  • Clearer differentiation between minor adjustments and major risk changes

These changes are intended to improve operational efficiency while maintaining appropriate review processes.

4. Details

How It Works

Risk parameters are grouped into different risk categories (low, medium, and high), each with defined handling rules.

For certain parameters, changes within predefined ranges can be reviewed and executed more quickly. For larger or more impactful changes, a review window applies, during which Venus can approve or reject the proposal. Some parameter changes may still require longer review periods due to their complexity.

All proposals follow defined safeguards, including limits on how frequently the same parameter can be changed.

User Interaction

From a user perspective, this framework operates largely in the background.

When approved risk parameter changes are executed, updates can be communicated through dedicated notification channels, showing:

  • Which market was affected
  • Which parameters changed
  • The before-and-after values
  • The stated reason and intended outcome of the change

This is intended to improve transparency as risk parameters evolve over time.

5. Scope of Parameters

Under this proposal, the Risk Stewards framework covers:

  • Market supply and borrow caps
  • Collateral factors
  • Liquidation thresholds and incentives
  • Interest rate models (with stricter review requirements)

Certain parameters, such as reserve factors, close factors, flash loan settings, and eMode configuration, remain outside the scope of this framework.

We welcome community feedback on this approach ahead of proposing it formally through a VIP vote.

1 Like

Highly supportive to this proposal

We used to have high load of bureaucracy to work out, even for minor change like cap increase.

Efficiency is key to catch back development and competitivity.

Hello, and thank you for proposing the Risk Stewards Framework. I agree that improving the speed and flexibility of risk management is important. However, there are several governance-critical points that would benefit from additional clarification.

  1. Control over the Risk Stewards address list

Who controls the list of Risk Steward addresses, and how is this control exercised?
Is the list governed through a formal on-chain process (VIP), or does it function as a predefined set of privileged addresses?

It seems reasonable to assume that the initial Risk Steward will be closely aligned with Venus Labs. In that case, what guarantees exist that the list can be expanded in practice, for example to include an independent team, multisig, or a community-nominated entity?

  1. Clarification of “Receive Proposal”
  • The process includes a step called [Venus] Receive Proposal. What does this mean operationally?

  • What criteria are used to accept or reject it?

  • Is this a purely procedural step, or does it imply discretion on the side of Venus Labs?

  • From the current wording, it can be interpreted as “Venus Labs wants a proposal”, meaning that proposals are effectively gated or initiated internally.
    Please clarify what is actually happening at this stage.


I’m not disputing the importance of this upgrade. Still, as currently described, the framework could be perceived as a more explicit formalization of existing governance flows rather than a structural change to them.
Providing clearer details on how authority is distributed, constrained, and gradually broadened would help the community better understand how this fits into the long-term DAO vision.

Hi, thank you for your questions. Here are some further clarifications:

1. Risk Steward addresses will be managed through a Venus-maintained whitelist. Any addition or removal of a Risk Steward will require approval via a VIP.

2. By “receiving proposals,” we mean that risk teams are expected to submit a complete impact summary in a standard format, including:

  • The affected market(s)
  • The parameter(s) being changed
  • Before-and-after values
  • The rationale and intended outcome

This process ensures that the protocol’s impact can be reviewed prior to execution. It is intended to be a standard procedural step, except in cases where the impact is significant, in which case a separate VIP may be proposed.