Price Oracles
How the protocol turns LP position state into credit-relevant collateral values.
Overview
Avana prices LP collateral by reconstructing the position and valuing the assets inside it. For fungible LPs, the protocol derives value from external asset prices and pool balance reconstruction. For concentrated liquidity, it decomposes the position by liquidity, range, current tick, token exposure, and accrued fees.
The result is discounted into recoverable collateral value. Borrow power is based on what the position can realistically support under the market's risk assumptions, not on an optimistic net asset value.
That distinction between mark value and recoverable value is what keeps the oracle useful for lending instead of just analytics. ERC-20 LPs, NFT LPs, and multi-asset pools can share one high-level interface only because each class goes through its own validation and manipulation-resistance checks before the value reaches the spoke.
LP collateral value depends on:
- The prices of the underlying assets
- The pool reserves or inventory split
- Fee accrual
- For concentrated liquidity, the current tick relative to the position range
- Whether the position is in-range or mostly one-sided
Oracle Interface: IOracle
Borrow Spokes need one contract surface even though LP formats differ a lot across DEXs. `IOracle` provides that common shape and keeps principal value, accrued fees, and reserved buffers separate so later risk logic does not have to guess which part of the position it is looking at:
function getValue(uint256 tokenId, address asset)
external view returns (
uint256 fullValue,
uint256 feeValue,
uint256 reserveValue
);The interface hides DEX-specific plumbing from the spoke. That lets the same caller handle ERC-20 LPs, NFT LPs, and multi-asset pools through one return shape while still leaving room for conservative, collateral-family-specific treatment behind the scenes.
Multi-Layer Architecture
LP valuation is a staged process rather than a single spot-price read. The oracle path moves through the following steps:
Price underlying assets from external robust oracles
Start from resilient external feeds for the underlying assets so collateral does not inherit the full noise or manipulability of raw pool spot state.
Derive LP value conservatively
Rebuild fungible LP balances or decompose concentrated-liquidity positions from reserves, liquidity, range, and fees using a deterministic path that the spoke can reason about.
Haircut for impermanent loss and liquidation slippage
Discount the reconstructed mark to a recoverable collateral value that assumes stress, slippage, and imperfect exits rather than a clean redemption at theoretical NAV.
Cap exposure by LP family and pool depth
Apply controls based on LP family, pool class, and available depth so thinner or more complex markets do not receive the same borrow limits as deeper and simpler ones.
Liquidate based on recoverable unwind value, not optimistic NAV
Use the value that can reasonably be realized through the unwind path when granting borrow power and deciding liquidation, rather than the best-case mark value.
DEX-Specific Handling
Different DEXs expose different pieces of state, and the oracle uses those inputs to reconstruct the position and verify pricing. Pool-derived data is not accepted blindly as a direct collateral mark.
| DEX / LP Type | Oracle Source | Notes |
|---|---|---|
| Curve Stable/Stable ERC-20 LPs | External stablecoin feeds + pool-state checks + TWAP verification | External prices anchor the assets while pool balances and fee accrual determine discounted collateral value. |
| Uniswap V2 ERC-20 LPs | Chainlink + reserve reconstruction + TWAP verification | Standard LP tokens are valued from reconstructed underlying balances, with TWAP used as a manipulation-resistant cross-check. |
| Uniswap V3 NFT LPs | Chainlink + position decomposition + tick/TWAP checks | The NFT is decomposed by liquidity, active range, and current price, then haircut for recoverable liquidation value. |
| Balancer Multi-Asset LPs | Chainlink + weighted inventory reconstruction | Multi-token pools use external prices and weighted pool inventory to estimate conservative collateral value. |
| SushiSwap / Aerodrome | Chainlink + reserve reconstruction + TWAP verification | Pool-derived observations verify reconstructed value and help resist same-transaction abuse in lower-liquidity markets. |
| PancakeSwap | Chainlink + block-based TWAP verification | External prices remain the anchor while block-based observations validate position state and unwind assumptions. |
TWAP Computation by DEX
TWAPs are verification inputs. They sit beside external asset prices and deterministic position reconstruction to check whether the pool state being observed is consistent with a credible unwind path. They help reject suspicious or short-lived distortions, but they do not replace the broader oracle model on their own.
Uniswap V2 & SushiSwap
On-chain cumulative price data over a 1-hour window is used to cross-check the reconstructed reserve picture and reduce sensitivity to flash swaps or other short-lived pool distortions.
Uniswap V3
Position-aware checks incorporate tick range, liquidity distribution, and accrued fees so the protocol can verify the decomposed token exposure of each NFT LP rather than treating the NFT as a black box.
Balancer
Weighted token observations are combined with pool weights to validate multi-asset inventory splits before the oracle assigns a conservative collateral value.
Curve
Stablecoin observations are used mainly to detect stale feeds, reserve drift, and short-term anomalies while external prices remain the primary anchor.
Trader Joe & Aerodrome
Cumulative price observations over a 30-60 minute window help validate lower-liquidity pool state and resist same-transaction manipulation during collateral checks.
Safety & Manipulation Prevention
- Deviation Thresholds
New loans or liquidations can be paused when pool-derived verification data moves too far away from external reference prices beyond
maxDifference. - maxPoolPriceDifference
This keeps pool-implied state aligned with underlying token prices and limits instantaneous pool manipulation or same-transaction oracle abuse.
- Open Interest Caps
Exposure is capped by LP family, pool depth, and collateral complexity so thinner markets receive tighter borrow limits.
- Recovery Haircuts
The oracle discounts theoretical LP value for impermanent loss, unwind slippage, and stressed liquidation assumptions before any borrow power is granted.
- Oracle Sentinel
Oracle Sentinel watches feed health and verification inputs and can trigger fallback behavior when data is stale, compromised, or inconsistent with position-state checks.
Configurable Oracle Parameters
Pool-specific oracle settings are configured per token through setTokenConfig. The table below shows the parameters that define how a token and its associated pool should be checked:
| Parameter | Description |
|---|---|
| Token | Collateral token address |
| AggregatorV3Interface | Chainlink feed for underlying token |
| maxFeedAge | Maximum acceptable age for Chainlink feed |
| Pool | Specific DEX pool (Uniswap V3, Balancer, Curve, etc.) |
| twapSeconds | Window for TWAP computation |
| Mode | Oracle operational mode (standard/fallback) |
| maxDifference | Max allowed deviation between DEX and verification price |
In practice, oracle behavior comes from the combination of external asset pricing, LP reconstruction logic, recoverable-value treatment, and the per-token settings configured through setTokenConfig.