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 markets differ in their asset mix, valuation methods, liquidation routes, and failure modes. Stable, correlated, weighted, and concentrated-liquidity pools can therefore require different risk parameters. The framework applies those differences when reviewing updates to a spoke or pool.
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: exposure-reducing actions follow a more direct path than changes that expand protocol risk.
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
Public disclosure identifies the parameter change submitted for execution so reviewers can compare the notice with the queued payload.
Spoke Awareness
Each LP collateral spoke carries its own listing rules, oracle assumptions, liquidation path, and risk profile.
Defensive Asymmetry
The framework gives exposure-reducing actions a more direct path than changes that expand protocol risk.
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 are grouped by their effect on risk. Each class defines the required authority and execution path, from bounded routine updates to changes that require broader governance approval.
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
Public notice precedes submission in the routine update flow. It records the affected markets and proposed parameters so developers and reviewers can compare the stated change with the payload queued for execution.
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
Comparing these fields with the queued payload reveals differences in the affected markets, parameter values, timing, or assumptions before execution.
Emergency Actions
The Risk Defender's emergency path is limited to containing defined or highly probable failures when waiting for the normal timelock would be unsafe. Its narrower authority allows defensive actions such as restricting borrowing or disabling an affected adapter. Routine parameter changes continue to use the Initiator and Guardian process.
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.
The separation of proposing, review, and emergency roles applies across LP markets, while each market retains its own valuation assumptions, risk limits, and liquidation behavior.