Risk Framework
How Avana proposes, reviews, and executes risk changes across the Hub and LP Collateral Spokes.
Overview
The Avana Risk Framework defines how parameter changes are proposed, checked, and executed across the Hub and LP Collateral Spokes. It covers the controls used when the protocol adjusts supply and borrow caps, LT/LTV settings, interest-rate inputs, market status, and other parameters that depend on prices, utilization, pool depth, concentration, volatility, peg behavior, circuit breakers, position health, and related state.
LP collateral is not one homogeneous asset class. Stable LPs, correlated-asset LPs, weighted pools, concentrated liquidity, and other AMM designs can each have their own spoke-specific valuation path, liquidation path, and failure mode. The framework exists so those differences are reflected in the update process instead of being hidden behind a single generic risk setting.
Three roles stay separate throughout that process: Avana Risk Initiator, Avana Risk Guardian, and Avana Risk Defender. The party that recommends a routine change is not the same party that independently checks it, and the role that can act during an emergency is intentionally narrower than the routine path.
Operating rule: reducing risk should be easier than expanding it.
Core Principles
Role Separation
The framework assigns proposing, reviewing, and emergency containment to different actors so one party does not control the full path alone.
Constrained Execution
Routine risk changes execute only when they remain inside predefined policy bounds and pass validation checks.
Public Consistency
The update described publicly should be the same update that is actually queued for execution.
Spoke Awareness
Each LP collateral spoke carries its own listing rules, oracle assumptions, liquidation path, and risk profile.
Defensive Asymmetry
The process is intentionally biased so reducing risk is faster and simpler than expanding it.
Roles
Avana Risk Initiator
The role that prepares and recommends routine risk changes for the Hub and LP Collateral Spokes.
- Publish the rationale and classify the update as defensive or growth-oriented
- Submit routine updates into the timelocked execution path
- Recommend supply caps, borrow caps, LT/LTV, reserve factor, and interest-rate changes inside approved ranges
- Initiate spoke-level de-risking and pool onboarding inside preapproved spoke templates
Avana Risk Guardian
The independent reviewer with veto authority over queued routine changes.
- Verify that the queued update matches the public disclosure
- Check that the action stays inside approved policy bounds
- Reject updates based on invalid oracle, liquidity, or liquidation assumptions
- Cancel a queued update during the timelock window when it creates obvious spoke-level or hub-level instability
Avana Risk Defender
The emergency-only role used to contain incidents when the normal timelocked path is too slow.
- Reduce borrow caps or supply caps to defensive levels
- Freeze new borrowing on a spoke or freeze collateral usage for a pool, template, or spoke
- Disable a specific adapter or borrow path when predefined failure conditions are met
- Block new debt origination under emergency conditions without being used for routine optimization or growth actions
Update Flow
Routine changes follow a fixed path so the protocol can distinguish normal parameter maintenance from emergency containment. The standard sequence is public notice, submission, bound checks, timelock, Guardian review, and execution if the proposal is not vetoed.
Public Notice
The Risk Initiator publishes the intended change, why it is needed, and the scope it is expected to affect.
Submission
The Risk Initiator places the proposed change into the execution path used by the framework.
Validation
Framework checks confirm that the update stays inside predefined constraints and approved policy bounds.
Timelock
If validation passes, the change enters a timelock window instead of executing immediately.
Guardian Review
During timelock, the Risk Guardian reviews the exact queued payload and can cancel it if needed.
Execution
If the change survives review, it executes automatically after the timelock expires.
Emergency Path
If emergency conditions are met, the Risk Defender can use a separate defensive path with narrower authority.
Parameter Classes
Parameter changes do not all carry the same risk, so the framework groups them by how much authority they should require and how quickly they should be able to move.
Defensive Changes
These are the fastest routine changes because they reduce protocol exposure.
- Lowering borrow caps
- Lowering supply caps
- Reducing LTV or liquidation threshold
- Freezing borrow or collateral usage
- Tightening spoke settings
Routine Bounded Changes
These follow the standard Initiator -> Guardian -> timelock route inside approved bounds.
- Modest cap increases
- Modest parameter tuning inside approved ranges
- Adding new pools inside an existing spoke template
Governance-Level Changes
These are outside the routine framework and require a higher-level decision path.
- Creating a new spoke family
- Enabling a new LP primitive
- Adding a new oracle model
- Enabling a new liquidation adapter
- Materially expanding the risk surface beyond preapproved assumptions
Public Disclosure
Every routine update should be published before submission in a format that lets developers, users, and reviewers compare the notice with the exact action that is later queued.
Minimum disclosure standard
- Affected spoke
- Affected pools or templates
- Current parameters
- Proposed parameters
- Reason for the update
- Whether the update is defensive or growth-oriented
- Expected submission timing
- Expected timelock window
- Relevant dependencies or assumptions
Consistent disclosure makes it easier to review a proposal for scope creep, mismatched assumptions, or simple execution mistakes.
Emergency Actions
Emergency actions are for containment, not routine tuning. They should be used rarely, kept as narrow as possible, and structured so the protocol can return to the standard path once the immediate risk is understood. The Risk Defender should only act when a defined or highly probable failure condition makes the normal timelocked route unsafe.
Emergency triggers
- Oracle inconsistency
- Liquidation path degradation
- Abnormal pool behavior
- Wrapper dependency failure
- Adapter-level compromise
- Sudden spoke-level instability
Required post-action disclosure
- The trigger
- The action taken
- The intended duration
- The path back to normal operation
Emergency authority exists only for defined or highly probable failure cases where waiting on the normal timelock path is unsafe. It is not a path for routine growth or optimization.
Recommendation, review, and emergency containment remain separate because LP collateral is a collection of markets with different structures and failure modes, not one interchangeable asset list.