Establish Parameter Committee

Temperature Check
,
1

Summary

This temperature check introduces a framework to establish a Parameter Committee responsible for actively managing Liqwid Finance’s interest rate model parameters across markets.

The committee will be responsible for setting and updating:

  • Base rate
  • Utilization multiplier (pre-optimal slope)
  • Optimal utilization point
  • Post-optimal utilization multiplier (post-optimal slope)

These parameters will be adjusted according to a clearly defined hierarchy of objectives:

  1. Solvency / bad debt prevention
  2. Liquidity availability
  3. Target utilization (capital efficiency)
  4. Borrow demand stability

Motivation

Liqwid operates a dynamic interest rate money market, similar in design to protocols like Aave.

In such systems, interest rate parameters are not static risk settings - they are active control levers that directly influence:

  • Liquidity availability
  • Borrower behavior
  • Liquidation dynamics
  • Protocol health

Current Market Conditions

Across Liqwid markets - particularly stablecoin markets (where efficiency matters most) - we currently observe:

  • Persistently low utilization
  • Large amounts of idle capital
  • Utilization significantly below optimal levels

Current stablecoin market utilization ratios (as of Friday, May 8, 2026, 15:37 UTC):

Market Utilization Optimal utilization
DJED 60.53% 90%
wanUSDT 51.96% 90%
wanUSDC 44.97% 90%
iUSD 37.81% 90%
USDM 38.32% 90%
USDA 31.06% 90%
USDCx 9.92% 90%

*Only markets with over $100k liquidity were included above.

This indicates:

  • Underutilized liquidity
  • Reduced capital efficiency
  • Suboptimal borrower incentives

Preventing Negative Feedback Loops

A critical dynamic in lending markets is the supply-demand feedback loop:

  • If utilization is low → yields for lenders decrease
  • If yields are insufficient → lenders migrate elsewhere
  • Reduced supply → lower liquidity → worsened borrower conditions
  • Borrow demand declines further → reinforcing the cycle

This proposal explicitly aims to:

Increase borrower demand while ensuring lender yields remain competitive, preventing this negative feedback loop from materializing

Why This Matters

If interest rate parameters are not actively managed:

  • Liquidity may remain idle
  • Borrower demand may stagnate
  • Lenders may leave due to uncompetitive yields
  • Markets may become uncompetitive
  • Risk conditions may drift out of alignment

At the same time:

  • Overly frequent changes → borrower instability
  • Overly infrequent changes → market inefficiency

This creates a need for:

Structured, periodic, data-driven parameter updates

The Lending Market Trilemma

Setting interest rate parameters is fundamentally a multi-objective optimization problem.

There is no single “optimal” configuration - only trade-offs.

The Core Trade-Off

Capital Efficiency (Utilization)
vs
Liquidity Buffer (Withdrawability)
vs
System Safety (No Bad Debt)

You cannot maximize all three simultaneously.

Parameter Trade-Offs Explained

1. Optimal Utilization

  • Higher (e.g. 90%)

    • ↑ Capital efficiency
    • ↓ Liquidity buffer
    • ↑ Risk in stress scenarios

  • Lower (e.g. 80%)

    • ↑ Safety & withdrawal reliability
    • ↓ Efficiency

2. Pre-Optimal Slope (Utilization Multiplier)

  • Higher slope

    • ↑ Borrowing costs earlier
    • ↓ Utilization
    • ↑ Liquidity buffer

  • Lower slope

    • ↑ Borrowing demand
    • ↑ Utilization
    • ↓ Buffer

3. Post-Optimal Slope

  • Steeper slope

    • Aggressively protects liquidity
    • Forces deleveraging
    • May cause rate spikes

  • Flatter slope

    • Smoother borrower experience
    • Weaker protection in stress

4. Base Rate

  • Higher base rate

    • Ensures minimum yield for suppliers
    • Discourages low-value borrowing

  • Lower base rate

    • Increases borrower accessibility
    • May reduce lender incentives

Key Insight

Improving one dimension often comes at the expense of another

Therefore, parameter setting must follow a clear priority hierarchy.

Proposed Framework

The committee will manage parameters according to the following descending order of importance:

1. Solvency / Bad Debt Prevention

Ensure:

  • Liquidations can be processed under stress
  • Sufficient liquidity exists during market shocks
  • Bad debt risk is minimized

2. Liquidity Availability

Maintain:

  • Sufficient buffer for withdrawals
  • Healthy market functioning during normal conditions

3. Target Utilization (Capital Efficiency)

Optimize:

  • Proportion of supplied capital actively generating yield
  • Balance between idle liquidity and active borrowing

4. Borrow Demand Stability

Ensure:

  • Predictable rate environments
  • Minimal parameter volatility
  • Borrower confidence and retention

Committee Structure

Initial Composition (t0)

  • Core team members
  • Same signers as the admin multisig

Governance Oversight

Committee authority is explicitly subordinate to governance.

  • Any changes to the committee/admin multisig (including adding, removing, or replacing signers) must be approved through a governance vote
  • Ensures:
    • Accountability
    • Transparency
    • Community control

Future Expansion

The committee may expand to include:

  • Non-core contributors
  • Risk analysts
  • Governance participants

Selection based on:

  • Contribution
  • Analytical rigor
  • Alignment

All changes remain subject to governance approval.

Operating Cadence

  • Parameters reviewed every 4-6 weeks
  • Updates made only when necessary

Guiding Principles

  • If utilization is near optimal → no changes
  • Avoid excessive updates → borrower stability
  • Prioritize data-driven decisions

Exception: Overheated Markets

Updates may occur faster when:

  • Utilization is significantly above optimal
  • No natural deleveraging is observed
  • Liquidity buffers are at risk

In such cases:

Solvency and liquidity take priority over stability

Communication & Transparency

The committee will ensure:

  • Public communication for every parameter update
  • Clear rationale and data backing each decision
  • Posts/announcements documenting:
    • Changes made
    • Expected outcomes
    • Observed results over time

Data Accessibility & Independent Analysis

To encourage decentralization and external contributions:

A method for accessing market data will be provided alongside this proposal, including:

  • Historical utilization
  • Lender / borrower / protocol rates
  • Total supply
  • Total liquidity
  • Total debt
  • Data in both USD and token denomination

Data Dashboard (Work in Progress)

A dedicated data dashboard referenced in this proposal is currently under development and not yet publicly available.

  • Once ready, this governance temperature check will be updated to include a direct link
  • The dashboard will serve as a primary source of truth for:
    • Parameter decision-making
    • Independent analysis
    • Community validation

This proposal is being shared ahead of its completion because:

Early community and DAO feedback is critical to refining the framework and converging on a strong first iteration through discussion and consensus

Objective

  • Enable independent validation of assumptions
  • Encourage third-party analysis
  • Allow community members to propose improvements
  • Gradually decentralize parameter decision-making

Community Participation

All DAO and community members are encouraged to:

  • Review the framework
  • Challenge assumptions
  • Propose alternative approaches
  • Contribute analysis

The goal is to:

Iterate toward an increasingly optimal framework through open discussion

Committee vs Governance Trade-Off

There is a clear trade-off:

Committee Approach

  • :cross_mark: More centralized
  • :white_check_mark: Faster updates
  • :white_check_mark: Lower friction
  • :white_check_mark: More responsive to market conditions

Governance-Only Approach

  • :white_check_mark: More decentralized
  • :cross_mark: Slower
  • :cross_mark: Higher friction
  • :cross_mark: Risk of parameter lag

Key Insight

Allowing a committee to act within a structured framework ensures parameters do not fall behind market conditions

This reduces:

  • Mismatch between rates and demand
  • Inefficient capital allocation
  • Risk exposure

Scope

This proposal covers:

Interest rate parameters only

Future Work

Future proposals may address:

References

The framework primarily draws inspiration from Aave. A couple references:

These are just some examples of how we can learn from industry leaders and they reinforce that iterative, data-driven parameter management is the industry standard.

Expected Impact

  • Increased utilization
  • Improved lender yields
  • Stronger borrower demand
  • Reduced risk of liquidity fragmentation
  • Prevention of negative feedback loops

Risks & Considerations

1. Centralization (Short-Term)

Mitigated by governance oversight, public track record, constant communication and transparency.

2. Misconfiguration or “Overshooting” Risk

Mitigated by conservative iteration through avoiding drastic changes affecting large or mature pools.

3. Borrower Instability

Mitigated by controlled cadence through avoiding overly frequent changes.

Next Steps

  1. Gather feedback
  2. Iterate on framework
  3. Conduct temperature check vote
  4. Proceed to governance if consensus emerges

Poll

  • I do not support this framework
  • I support establishing the committee and framework
  • I support the framework with all updates going through governance proposals
0 voters
2

  1. I am surprised. I assumed this was already fully automated, run periodically by the team, and parameters changes proposed via governance when necessary after analysis.
    (Actually, I was looking a few days ago at open-sourcing a dashboard of per token risk metrics mostly according to Liqwid risk framework. Because for all Cardano lending protocols, users have no visibility on actual calculated risks and parameters choice. And if you look, you would be quite surprised at how divergent the parameters can be for a given token across protocols, and even worried about the parameters of some.)

  2. So, from where I arrive, I don’t see a difference with a committee for now made mostly of core contributors, and what is supposed to already be in place.

  3. As mentioned, it’s fully data driven. So what is the point of a committee if clear calculations and a framework is in place ?

  4. 4-6 weeks parameters changes is WAY TOO OFTEN. I’ll aim for not more often than every 3 months. Borrowers and lenders need some level of predictability on rates. Remember, some say dynamic rates are not that great because of rates predictability issues, and changing the parameters often make it even more so. I don’t want to have to check the parameters of a market I am in and how its utilization and rates react every 4-6 weeks. Yes I already monitor utilization and rates which are dynamic, but their movements are rather natural and kind of predictable based on the market or events. Changing the parameters very often breaks that predictability of rates changes.

  5. Saying it again. To me that is one of the main task of the team under ‘protocol maintenance/monitoring’ or ‘risk control’ or ‘markets monitoring’, and I am surprise you come now with this. Best in my opinion is to make it very much fully data driven, and open-source the calculations/metrics. All the needed data is public anyway.

  6. I would be more cautious about interpreting levels of utilization as effects of suboptimal parameters. We had plenty of different utilization regimes (some with high utilization) without changing parameters, and mostly driven by other factors.

  7. the real solution to the problem you’re stating is something like ‘algorithmic dynamic rates’
    → dynamic rates are supposed to be the solution to this balance of supply/borrow and create the self-correcting healthy markets.
    → you’re saying it’s not enough (and actually the problem description is really what dynamic rates are supposed to solve)
    → so the real solution is going even further than dynamic rates: ‘algorithmic dynamic rates’ = the parameters are not static numbers but slowly algorithmically evolving numbers based on some metrics