Intro
LP collateral cannot be supported with a generic lending design. It requires a system that can handle active liquidity positions, changing collateral composition, market specific valuation, and liquidation paths that are very different from standard token collateral. That is the architectural challenge Avana is built to solve.
Avana is being designed around Aave v4’s hub and spoke model because LP backed borrowing needs two things at once. It needs access to shared liquidity, and it needs market specific logic that can be isolated from the rest of the system. The hub provides the common capital layer. The spokes define how individual collateral markets behave. For LP collateral, that separation is not just elegant design. It is necessary.
Context
At the center of the architecture is the liquidity hub. This is the layer intended to hold borrowable assets and coordinate shared liquidity across supported markets. It is responsible for the common monetary functions of the system, including reserve management, utilization tracking, and credit allocation across authorized spokes. In practice, the hub is what allows Avana to plug LP collateral into a broader lending framework without forcing every collateral type to share the same assumptions. A stable LP market, a concentrated liquidity market, and a more volatile AMM pair should not all be governed the same way simply because they draw from the same pool of liquidity.
Model
That is where the spoke layer becomes essential. Avana’s borrow spokes are designed to handle the LP specific side of the system. They are the point where collateral is registered, valued, risk adjusted, monitored, and, if necessary, liquidated. This is where the protocol defines how different pool types are treated, how collateral capacity is determined, and how market specific liquidation logic is applied. In other words, the spoke is where LP collateral stops being an abstract concept and becomes a real lending market with its own rules.
Value
This distinction matters because LP positions are structurally different from conventional collateral. A Uniswap concentrated liquidity position does not behave like a fungible LP token from a stable pool. A Balancer weighted pool does not behave like a Curve correlated asset position. Even within the same venue, risk can change depending on pool composition, concentration, liquidity depth, and the relationship between the underlying assets. Avana’s architecture is designed so that those differences can be handled directly rather than averaged away into a single generic collateral model.
Risk
A major part of that design is the valuation system. LP collateral only works if the protocol can determine what a position is worth and what it is worth as collateral under stress. That is not the same question. Avana is being designed to value positions through a layered approach that combines position math, external price references, and pool specific risk treatment. The first step is understanding what the LP position actually contains at the current market state. The second is pricing those assets using reliable oracle inputs. The third is adjusting that raw value through collateral logic that reflects the actual risk of the pool rather than simply its notional size. This is one of the central ideas behind Avana’s model: not every dollar inside an LP position should translate into the same borrowing power.
Flow
That is also why oracle design sits so close to the core of the system. For LP collateral, the protocol cannot rely on a single number or a simplistic asset feed. It needs to understand both the underlying token values and the market conditions surrounding the pool. Avana is being designed around a dual source philosophy, where external price feeds and AMM derived pricing work together to produce more reliable position valuation. The point is not just to get a price. It is to reduce the chance that temporary dislocations, stale updates, or local pool distortions create unsafe collateral assumptions.
System
Liquidation design is the other major architectural challenge. Liquidating LP collateral is not the same as seizing a token balance and selling it. The protocol must account for the fact that the collateral is an active liquidity position that may contain uncollected fees, concentrated exposure, and venue specific exit behavior. A serious LP collateral system therefore needs a liquidation path that can unwind the position in a controlled way, convert the resulting assets, and settle debt without introducing avoidable loss. Avana’s architecture is being shaped around that requirement. The spoke is not only where collateral is admitted and valued. It is also where liquidation logic is specialized for the underlying market structure.
Users
This is one of the reasons the hub and spoke model is so important for Avana. The hub does not need to understand every AMM design in order to provide shared liquidity. The spoke does not need to own the entire reserve system in order to support specialized collateral. Each layer does what it is best suited to do. The result is a cleaner system, stronger isolation, and a more realistic path to scaling LP collateral pool by pool rather than forcing every market into a monolithic design from day one.
Outlook
From an integration perspective, this architecture also creates room for a broader ecosystem around the protocol. Analytics, liquidation infrastructure, vault strategies, and external interfaces can all be built around a system where collateral logic is legible and market boundaries are clear. That composability matters because Avana is not simply trying to support one LP format. The long term goal is to create a framework where different forms of AMM liquidity can become borrowable collateral without sacrificing the discipline required to support them safely.
Takeaway
In that sense, the architecture is not just a backend decision. It is the product thesis expressed technically. Avana exists to make LP positions usable as collateral on top of Aave v4. To do that credibly, the protocol needs shared liquidity, isolated market logic, robust valuation, and liquidation paths built for active AMM positions rather than passive token balances. The hub and spoke architecture is what makes that design possible.