Oracles de prix
Comment le protocole transforme l'état d'une position LP en valeurs de collatéral pertinentes pour le crédit.
Vue d'ensemble
Avana valorise le collatéral LP en reconstruisant la position et en valorisant les actifs qu'elle contient. Pour les LP fongibles, le protocole dérive la valeur à partir des prix externes des actifs et de la reconstruction des soldes du pool. Pour la liquidité concentrée, il décompose la position selon la liquidité, la fourchette, le tick actuel, l'exposition en tokens et les frais accumulés.
Le résultat est décoté en valeur de collatéral récupérable. La capacité d'emprunt repose sur ce que la position peut réalistement soutenir sous les hypothèses de risque du marché, et non sur une valeur nette d'actifs optimiste.
Cette distinction entre valeur mark et valeur récupérable est ce qui rend l'oracle utile pour le prêt, et pas seulement pour l'analytique. Les LP ERC-20, LP NFT et pools multi-actifs peuvent partager une interface de haut niveau uniquement parce que chaque classe passe ses propres contrôles de validation et de résistance à la manipulation avant que la valeur n'atteigne le Spoke.
LP collateral value depends on:
- Les prix des actifs sous-jacents
- Les réserves du pool ou la répartition d'inventaire
- Fee accrual
- Pour la liquidité concentrée, le tick actuel par rapport à la fourchette de la position
- Si la position est in-range ou surtout unilatérale
Interface oracle : IOracle
Les Borrow Spokes ont besoin d'une surface de contrat unique même si les formats LP diffèrent beaucoup entre DEX. `IOracle` fournit cette forme commune et sépare la valeur du principal, les frais accumulés et les buffers réservés, pour que la logique de risque ultérieure n'ait pas à deviner quelle partie de la position elle regarde :
function getValue(uint256 tokenId, address asset)
external view returns (
uint256 fullValue,
uint256 feeValue,
uint256 reserveValue
);L'interface masque la plomberie spécifique au DEX pour le Spoke. Cela permet au même appelant de traiter les LP ERC-20, LP NFT et pools multi-actifs via une seule forme de retour, tout en laissant place à un traitement prudent spécifique à la famille de collatéral en arrière-plan.
Architecture multi-couches
La valorisation LP est un processus par étapes plutôt qu'une simple lecture de prix spot. Le chemin d'oracle traverse les étapes suivantes :
Valoriser les actifs sous-jacents via des oracles externes robustes
Partir de feeds externes résilients pour les actifs sous-jacents afin que le collatéral n'hérite pas pleinement du bruit ou de la manipulabilité de l'état spot brut du pool.
Dériver la valeur LP de façon prudente
Reconstruire les soldes LP fongibles ou décomposer les positions à liquidité concentrée à partir des réserves, de la liquidité, de la fourchette et des frais, via un chemin déterministe que le Spoke peut raisonner.
Haircut pour perte impermanente et slippage de liquidation
Décoter le mark reconstruit en une valeur de collatéral récupérable qui suppose stress, slippage et sorties imparfaites, plutôt qu'un rachat propre au NAV théorique.
Plafonner l'exposition par famille LP et profondeur de pool
Appliquer des contrôles selon la famille LP, la classe de pool et la profondeur disponible, pour que les marchés plus fins ou plus complexes ne reçoivent pas les mêmes limites d'emprunt que les marchés plus profonds et plus simples.
Liquidation basée sur la valeur de débouclage récupérable, pas sur un NAV optimiste
Utiliser la valeur raisonnablement réalisable via le chemin de débouclage pour accorder la capacité d'emprunt et décider de la liquidation, plutôt que la valeur mark au meilleur des cas.
Traitement spécifique au DEX
Différents DEX exposent différentes pièces d'état, et l'oracle utilise ces entrées pour reconstruire la position et vérifier le pricing. Les données dérivées du pool ne sont pas acceptées aveuglément comme mark de collatéral direct.
| DEX / type de LP | Source d'oracle | Notes |
|---|---|---|
| LP Curve Stable/Stable ERC-20 | Feeds externes de stablecoins + contrôles d'état du pool + vérification TWAP | Les prix externes ancrent les actifs, tandis que les soldes du pool et l'accumulation de frais déterminent la valeur de collatéral décotée. |
| LP Uniswap V2 ERC-20 | Chainlink + reconstruction des réserves + vérification TWAP | Les tokens LP standards sont valorisés à partir des soldes sous-jacents reconstruits, le TWAP servant de contre-vérification résistante à la manipulation. |
| LP Uniswap V3 NFT | Chainlink + décomposition de position + contrôles tick/TWAP | Le NFT est décomposé selon la liquidité, la fourchette active et le prix actuel, puis haircut pour la valeur de liquidation récupérable. |
| LP Balancer multi-actifs | Chainlink + reconstruction d'inventaire pondéré | Les pools multi-tokens utilisent les prix externes et l'inventaire pondéré du pool pour estimer une valeur de collatéral prudente. |
| SushiSwap / Aerodrome | Chainlink + reconstruction des réserves + vérification TWAP | Les observations dérivées du pool vérifient la valeur reconstruite et aident à résister aux abus same-transaction sur les marchés à plus faible liquidité. |
| PancakeSwap | Chainlink + vérification TWAP basée sur les blocs | Les prix externes restent l'ancre, tandis que les observations basées sur les blocs valident l'état de la position et les hypothèses de débouclage. |
Calcul TWAP par DEX
Les TWAP sont des entrées de vérification. Ils se placent à côté des prix externes des actifs et de la reconstruction déterministe de position pour vérifier si l'état de pool observé est cohérent avec un chemin de débouclage crédible. Ils aident à rejeter les distorsions suspectes ou de courte durée, mais ne remplacent pas à eux seuls le modèle d'oracle plus large.
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
Les contrôles sensibles à la position intègrent la fourchette de ticks, la distribution de liquidité et les frais accumulés afin que le protocole puisse vérifier l'exposition en tokens décomposée de chaque LP NFT, plutôt que de traiter le NFT comme une boîte noire.
Balancer
Les observations de tokens pondérés sont combinées aux poids du pool pour valider les répartitions d'inventaire multi-actifs avant que l'oracle n'attribue une valeur de collatéral prudente.
Curve
Les observations de stablecoins servent surtout à détecter les feeds obsolètes, la dérive des réserves et les anomalies de court terme, tandis que les prix externes restent l'ancre principale.
Trader Joe & Aerodrome
Les observations de prix cumulatives sur une fenêtre de 30-60 minutes aident à valider l'état des pools à plus faible liquidité et à résister à la manipulation same-transaction pendant les contrôles de collatéral.
Sécurité & prévention de la manipulation
- Seuils de déviation
Les nouveaux prêts ou liquidations peuvent être mis en pause lorsque les données de vérification dérivées du pool s'écartent trop des prix de référence externes au-delà de
maxDifference. - maxPoolPriceDifference
Cela garde l'état implicite du pool aligné avec les prix des tokens sous-jacents et limite la manipulation instantanée du pool ou l'abus d'oracle same-transaction.
- Plafonds d'open interest
L'exposition est plafonnée par famille LP, profondeur de pool et complexité du collatéral, afin que les marchés plus fins reçoivent des limites d'emprunt plus strictes.
- Recovery Haircuts
L'oracle décote la valeur LP théorique pour la perte impermanente, le slippage de débouclage et les hypothèses de liquidation sous stress avant d'accorder toute capacité d'emprunt.
- Oracle Sentinel
Oracle Sentinel surveille la santé des feeds et les entrées de vérification, et peut déclencher un comportement de fallback lorsque les données sont obsolètes, compromises ou inconsistantes avec les contrôles d'état de position.
Paramètres d'oracle configurables
Les paramètres d'oracle spécifiques au pool sont configurés par token via setTokenConfig. Le tableau ci-dessous montre les paramètres qui définissent comment un token et son pool associé doivent être contrôlés :
| Paramètre | Description |
|---|---|
| Token | Adresse du token de collatéral |
| AggregatorV3Interface | Feed Chainlink pour le token sous-jacent |
| maxFeedAge | Âge maximal acceptable pour le feed Chainlink |
| Pool | Pool DEX spécifique (Uniswap V3, Balancer, Curve, etc.) |
| twapSeconds | Fenêtre pour le calcul TWAP |
| Mode | Mode opérationnel de l'oracle (standard/fallback) |
| maxDifference | Déviation maximale autorisée entre le prix DEX et le prix de vérification |
En pratique, le comportement de l'oracle vient de la combinaison du pricing externe des actifs, de la logique de reconstruction LP, du traitement de valeur récupérable, et des paramètres par token configurés viasetTokenConfig.