Intro
LP collateral cannot be governed with the same assumptions as a generic lending market. It is not one collateral class, one liquidation path, or one oracle model repeated across a larger asset list. It is a family of markets with different pool structures, different failure modes, different liquidity conditions, and different ways of behaving under stress. That is why Avana needs a risk framework that is closer to an operating system than to a flat list of parameters. The goal is not simply to set caps and thresholds. The goal is to manage a protocol where the nature of the collateral itself varies meaningfully from market to market.
Context
The Avana Risk Framework is designed around that reality. It governs how the protocol interprets market data and protocol state across the hub and all LP collateral spokes, including volatility, peg stability, utilization, liquidity depth, collateral concentration, oracle quality, market status, supply and borrow caps, LTV and liquidation thresholds, interest rate models, and position health. That sounds broad because it is broad. In a protocol supporting LP collateral, risk management cannot be reduced to one static formula. It has to remain aware of the collateral family, the market environment, and the operating state of the system at the same time.
Model
The framework’s most important design choice is role separation. Avana deliberately separates routine risk recommendation, independent review, and emergency containment into three roles: the Risk Initiator, the Risk Guardian, and the Risk Defender. This is not procedural theatre. It reflects a simple principle: the actor recommending growth or parameter changes should not be the same actor deciding whether that change is safe, and emergency containment should remain narrower than routine optimization. In other words, it should always be easier to reduce risk quickly than to expand it casually.
Value
The Risk Initiator is the primary recommending authority for routine updates. That includes proposing changes to caps, collateral settings, interest rate parameters, and pool onboarding inside approved market templates. The role is meant to make the case for changes publicly, classify them as defensive or growth-oriented, and submit them into the normal execution path. The Guardian then acts as the independent review and veto layer. Its role is to confirm that what was publicly disclosed is what is actually queued, check whether the action stays inside approved policy bounds, and cancel changes during the timelock window if they rely on invalid oracle, liquidity, or liquidation assumptions. Finally, the Defender is the narrow emergency role. It exists to reduce caps, freeze borrowing, disable a compromised adapter, or otherwise contain risk when waiting for the routine path would be unsafe.
Risk
This separation matters more in LP collateral markets than in simpler systems because the risk surface is more dynamic and more heterogeneous. A stable LP market is not the same as a concentrated liquidity market. A weighted pool is not the same as a correlated-asset pool. Even inside one spoke family, pool quality can vary enough that routine growth decisions and defensive containment decisions should not share the same governance posture. Avana’s framework is built so that each spoke can remain aware of its own oracle assumptions, liquidation logic, admissibility rules, and operational constraints. That is what spoke awareness means in practice. The protocol is not governed as if all LP markets were interchangeable.
Flow
The standard update flow is intentionally simple: public notice, submission, validation against predefined bounds, timelock, Guardian review, and execution if not vetoed. This structure gives developers, users, and governance participants a way to see the rationale for routine changes before they happen and to compare what was promised against what was actually queued. In a protocol built around complex collateral, public consistency matters. If the policy narrative and the executable change diverge, the review process has already failed.
System
Not all parameter changes should move through the same path. Defensive changes such as lowering caps, tightening collateral treatment, or freezing borrowing should be the easiest to execute because they reduce exposure. Routine bounded changes such as modest tuning within approved ranges belong in the standard path. But governance-level changes, such as creating new spoke families, enabling new LP primitives, introducing new oracle models, or adding new liquidation adapters, should remain outside the routine framework. Those moves expand the protocol’s risk surface materially and should be treated as such. This is one of the clearest ways the framework enforces defensive asymmetry. Growth is not forbidden. It is simply required to carry more review weight than containment.
Users
Emergency actions are where that philosophy becomes most visible. Oracle inconsistency, liquidation path degradation, abnormal pool behavior, wrapper failure, adapter compromise, or sudden spoke-level instability are all reasons the Defender may need to act before the normal process runs its course. But even here the framework is careful. Emergency authority is narrow, defensive, and reversible. It is not meant to become a shadow governance path for routine optimization. It is a safety mechanism for moments when the protocol’s assumptions are breaking faster than timelock governance can respond.
Outlook
The deeper point is that Avana risk governance is not just about who approves which number. It is about matching governance structure to collateral complexity. LP backed lending cannot be governed responsibly with flat assumptions and casual parameter drift. It requires market templates, bounded execution, transparent disclosure, and a clear distinction between normal growth, defensive adjustment, and emergency containment. That is what makes the Risk Framework so important to the Avana model. It is the system that allows different LP markets to be supported under one protocol without pretending they all deserve the same treatment.
Takeaway
That is also why governance is part of the protocol’s trust layer rather than a side topic. Oracle design tells users how collateral is valued. Liquidation design tells them how failure is resolved. Smart Agents tell them how the system operates under stress. The Risk Framework tells them how those assumptions evolve over time. In a protocol built around LP collateral, that evolution matters as much as the initial design. If Avana is going to support a family of active and heterogeneous collateral types, it needs a governance model built with the same discipline as the markets themselves.