Le Problème des Vaults en Temps Réel
Chaque part de vault représente une créance sur les actifs sous-jacents. La question est de savoir si le prix utilisé pour émettre et rembourser ces parts est réellement correct.
En finance traditionnelle, la valeur liquidative (NAV) évolue lentement. La plupart des fonds utilisent une tarification prospective, où les dépôts sont réglés ultérieurement via des fenêtres d'entrée en file d'attente, limitant ainsi naturellement le risque de prix obsolètes.
La DeFi change complètement cela. Pour que les parts de vault restent composables sur les marchés de prêt, les boucles de levier et les systèmes financiers on-chain, les dépôts doivent se faire atomiquement tandis que les stratégies sous-jacentes et les systèmes comptables se mettent à jour de manière asynchrone à travers les chaînes, les plateformes et les environnements d'exécution.
Cela crée un écart dangereux entre ce que le vault possède réellement et ce que le vault croit posséder.
Dès lors que le capital peut se déplacer en continu, la NAV cesse d'être une fonction de reporting pour devenir une infrastructure centrale. Chaque dépôt, remboursement, rééquilibrage et règlement dépend de l'intégrité du prix utilisé à cet instant précis. Une NAV obsolète n'est pas un problème cosmétique ; c'est un événement de transfert de valeur.
Si les dépôts sont tarifés sur la base de soldes obsolètes, les nouveaux utilisateurs subventionnent les détenteurs existants. Si les remboursements sont réglés sur la base de prix obsolètes, les utilisateurs qui se retirent extraient de la valeur du vault. Et si une stratégie subit des pertes avant que les mises à jour de la NAV ne rattrapent leur retard, de nouveaux dépôts peuvent acheter par inadvertance des stocks dépréciés à des prix antérieurs aux pertes. Aucun de ces échecs n'apparaît dans le rendement annoncé, mais ils comptent.
C'est le problème d'infrastructure caché derrière la DeFi institutionnelle, et c'est exactement pourquoi Concrete a construit un système de gestion de la NAV en temps réel conçu pour la finance asynchrone on-chain.
La plupart des systèmes de vault ont été construits sur cette hypothèse : les stratégies étaient entièrement on-chain, et la génération de rendement était programmatique. Le capital se déplaçait via des smart contracts, les positions se mettaient à jour de manière déterministe, et la comptabilité pouvait être codée en dur directement dans le vault. Tant que les stratégies vivaient entièrement sur la chaîne, la NAV restait relativement simple à calculer car le vault avait toujours une visibilité immédiate sur ses positions et soldes sous-jacents.
Cette hypothèse se brise dès que les vaults évoluent au-delà des stratégies de smart contracts.
Les systèmes de vault modernes reposent de plus en plus sur une exécution active, des allocations pilotées par des curateurs, un déploiement cross-chain et des sources de rendement off-chain qui ne peuvent pas être reflétées en temps réel sur la chaîne. Les stratégies opèrent désormais à travers des ponts, des plateformes de perpetuals, des marchés monétaires, des systèmes de restaking et des pools de liquidité, chacun avec des délais de règlement, des retards de reporting et des caractéristiques de liquidité différents. Dans certains cas, l'état de la position concernée peut dépendre de registres de dépositaires, de données de plateforme, de règlements cross-chain ou de registres d'exécution off-chain qui ne peuvent pas être reflétés sur la chaîne à la même vitesse qu'un simple solde de token.
Le résultat est que le capital se déplace en continu tandis que l'état sous-jacent du vault se met à jour de manière asynchrone, créant un écart dangereux entre ce que le vault possède réellement et ce que le vault croit posséder.
Dans cet écart, la valeur fuit.
La latence de tarification n'est pas un frottement opérationnel, c'est un transfert de risque caché. Plus la DeFi se déplace rapidement, plus l'intégrité comptable devient importante.
Gestion de la NAV pour la Finance On-Chain
Concrete aborde la NAV comme un problème de système plutôt que comme une simple mise à jour d'oracle ou comptable. L'architecture combine des modèles de lissage, des seuils de risque dynamiques, une vérification indépendante, des contrôles de dépôt et des mécanismes de pause automatisés dans un cadre unifié conçu pour maintenir la précision de la tarification du vault même dans des conditions de marché volatiles.
Le premier défi est le bruit. Les données de prix brutes sont intrinsèquement imparfaites. Les retards de pont, les API obsolètes, les dislocations temporaires de liquidité et les événements de règlement asynchrones peuvent tous fausser la comptabilité à court terme. Concrete lisse les observations de la NAV à l'aide d'une moyenne mobile exponentiellement pondérée (EWMA), permettant aux observations récentes de porter plus de poids tout en filtrant les pics isolés et les anomalies transitoires.(2) L'objectif n'est pas de supprimer la volatilité ; c'est de limiter l'influence des irrégularités de données isolées sur la tarification du vault.
Mais le lissage seul ne suffit pas car chaque vault se comporte différemment. Une stratégie de carry delta-neutre a un profil de volatilité complètement différent d'un vault de restaking à effet de levier. Un mouvement de 50 points de base peut être insignifiant pour une stratégie et catastrophique pour une autre. Concrete calibre chaque vault de manière indépendante en liant les seuils de pause à des mesures de volatilité glissantes dérivées d'un modèle d'écart-type sur deux semaines.(3) Les seuils se resserrent automatiquement pendant les périodes stables et s'élargissent pendant les environnements volatils, permettant à la gestion des risques de s'adapter dynamiquement au comportement de la stratégie sous-jacente plutôt que de reposer sur des hypothèses statiques.
Vérification Avant Règlement
Même alors, la vitesse sans vérification n'est pas une infrastructure institutionnelle. Chaque mise à jour de la NAV dans Concrete passe par un processus de vérification à trois parties. Un Proposeur de Transaction calcule la mise à jour proposée en utilisant les données de stratégie et de comptabilité. Un Signataire Indépendant valide la mise à jour par rapport à une source comptable distincte. Enfin, le smart contract lui-même rejette les mises à jour en dehors des limites comptables prédéfinies.(4) Par conception, aucun opérateur unique, y compris Concrete, ne peut modifier unilatéralement la comptabilité du vault en dehors des limites imposées par le smart contract. Le but du système n'est pas simplement la redondance opérationnelle ; c'est de réduire le risque que des données erronées, des rapports obsolètes ou des erreurs d'opérateur affectent directement la couche de tarification contre laquelle les utilisateurs effectuent des transactions.
L'intégrité de la tarification, cependant, n'est que la moitié du problème. Même des systèmes comptables parfaitement vérifiés ne peuvent éliminer la latence entre les événements de marché et les mises à jour de règlement.
La vérification garantit que la NAV déclarée est correcte. L'intégrité du règlement garantit que les utilisateurs effectuent des transactions contre cette NAV de manière équitable tandis que l'état sous-jacent du vault continue de se mettre à jour de manière asynchrone.
L'objectif n'est pas d'éliminer complètement la latence. L'objectif est d'empêcher une incertitude temporaire de se transformer en fuite de valeur permanente.
Protéger le Prochain Déposant
Cela devient le plus important lors d'événements de pertes matérielles, c'est là que la plupart des systèmes de pause de la DeFi sont fondamentalement mal compris. Les mécanismes de pause sont souvent présentés comme des garde-fous opérationnels qui protègent les protocoles ou les opérateurs. En réalité, ils existent pour protéger le prochain déposant.
Si une stratégie subit une perte matérielle avant que la NAV ne soit complètement mise à jour, le pire résultat possible est de permettre à de nouveaux dépôts de continuer à entrer dans le vault à un prix obsolète. Ces utilisateurs achètent effectivement des stocks dépréciés sans s'en rendre compte. L'architecture de pause de Concrete est conçue spécifiquement pour ce scénario. Lorsque les écarts entre la couche d'observation en direct et le modèle de tarification lissé dépassent les seuils ajustés à la volatilité, le système est conçu pour interrompre les dépôts jusqu'à ce que l'intégrité de la tarification soit rétablie.(5) Le but n'est pas la commodité opérationnelle ; c'est de réduire le risque que les pertes soient involontairement mutualisées entre les participants.
Les retraits introduisent le même problème en sens inverse. Si le capital reste déployé après qu'une demande de retrait a été initiée, il continue de générer des rendements et reste exposé au risque. Traiter les utilisateurs comme étant sortis avant que les positions ne soient effectivement dénouées crée un décalage entre l'exposition économique et la réalité comptable.
L'architecture de vault asynchrone de Concrete utilise des files d'attente de retrait par époque compatibles ERC-4626 qui règlent les remboursements sur la NAV au moment du règlement, et non sur la NAV au moment de la demande.(6) Le principe est simple : si les fonds sont toujours exposés au risque de la stratégie, ils doivent également rester exposés aux variations de NAV qui en résultent. Tout le reste crée des opportunités d'arbitrage et un transfert de valeur inéquitable entre les participants.
Le Produit, C'est la Stack
Ce qui importe, ce n'est pas une couche de contrôle individuelle, mais la manière dont les couches se renforcent mutuellement. Le lissage sans seuils adaptatifs devient trop rigide. Les seuils sans vérification introduisent un risque opérationnel. La vérification sans contrôles de dépôt expose toujours les utilisateurs pendant les fenêtres de latence. Les plafonds de dépôt sans systèmes de pause permettent toujours des événements de tarification altérée. Et les systèmes de pause sans une architecture de retrait cohérente laissent toujours fuir de la valeur lors du remboursement.
Le produit n'est pas l'EWMA. Le produit n'est pas les plafonds de dépôt. Le produit n'est pas la comptabilité automatisée.
Le produit, c'est la stack.
Les allocateurs institutionnels n'évaluent pas les vaults uniquement sur le rendement. Ils évaluent l'intégrité comptable, les contrôles opérationnels, la précision de la tarification et la conception de l'atténuation des pertes. C'est la couche d'infrastructure nécessaire pour que la DeFi mûrisse au-delà des flux de capitaux spéculatifs et évolue vers une infrastructure financière programmable capable de supporter des capitaux à l'échelle institutionnelle.
Le système de Concrete est conçu pour que les mises à jour de la NAV soient vérifiées indépendamment, les anomalies de tarification soient filtrées avant le règlement, l'exposition aux dépôts soit limitée dynamiquement, les événements de pertes matérielles déclenchent des mécanismes de pause sur les nouveaux flux entrants, et les retraits soient réglés sur des états comptables en direct plutôt que sur des instantanés obsolètes. Ces systèmes ne sont pas des fonctionnalités optionnelles ajoutées aux vaults après coup. Ce sont des exigences fondamentales pour rendre la finance programmable digne de confiance à grande échelle.
L'Avenir de l'Infrastructure des Vaults
La DeFi a résolu la transparence avant de résoudre la comptabilité. Cela est en train de changer.
Alors que les vaults évoluent vers une infrastructure financière programmable opérant à travers les chaînes, les stratégies et les couches de liquidité, la qualité de l'infrastructure devient plus importante que le rendement affiché. La prochaine phase de la DeFi ne sera pas définie par qui déclare le rendement le plus rapidement. Elle sera définie par qui peut rendre ces chiffres dignes de confiance.
La NAV en temps réel n'est pas simplement une amélioration de l'expérience utilisateur. C'est une infrastructure fondamentale pour le capital institutionnel. Car plus le capital se déplace rapidement sur la chaîne, plus l'intégrité comptable devient importante.
Les vaults ne sont plus des enveloppes de rendement passives. Ce sont des systèmes financiers programmables, et les systèmes financiers programmables nécessitent une confiance programmable.
Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil en investissement, juridique, fiscal, financier, ni une offre ou sollicitation de quelque nature que ce soit. Les descriptions de l'architecture, des contrôles et des objectifs de conception de Concrete sont illustratives ; elles n'éliminent pas les risques associés aux smart contracts, aux protocoles DeFi, aux conditions de marché, aux défaillances d'oracle ou de données, aux défaillances opérationnelles, aux infrastructures tierces ou à la performance des contreparties. Concrete ne garantit pas qu'un rendement cible, une précision de la NAV, un comportement de pause ou tout autre résultat du système sera atteint. Les déclarations prospectives reflètent les attentes actuelles de Concrete et ne constituent pas des garanties de résultats futurs. La participation aux vaults Concrete comporte des risques, y compris un risque de perte totale. Pour les divulgations complètes des risques, voir https://concrete.xyz/disclaimershttps://concrete.xyz/disclaimers).
- Dans cet article, « NAV » désigne la valeur comptable opérationnelle utilisée pour tarifer les parts de vault, les dépôts, les remboursements et le règlement au niveau de la stratégie. Elle peut différer de la NAV des états financiers, des registres du dépositaire ou des valeurs de protocole tiers, et peut être soumise à une méthodologie et un calendrier propres au vault.
- Une moyenne mobile exponentiellement pondérée donne plus de poids aux observations récentes tout en intégrant encore les données plus anciennes. Les paramètres spécifiques, y compris le taux de décroissance et les fenêtres d'observation, sont calibrés par vault et peuvent être mis à jour par Concrete au fil du temps en fonction des caractéristiques de la stratégie, des conditions de marché et des données opérationnelles. Le lissage EWMA réduit l'influence des anomalies de prix à court terme mais n'élimine pas le risque de tarification.
- Les fenêtres de volatilité, les largeurs de seuil et les paramètres de pause sont calibrés par vault, sont sujets à modification à la discrétion de Concrete et dépendent de l'exactitude des données d'entrée. Aucun modèle de seuil ne peut anticiper toutes les conditions de marché.
- Les rôles décrits (Proposeur de Transaction, Signataire Indépendant et validation on-chain) opèrent au sein des smart contracts de vault de Concrete et sont soumis à des contrôles multisig et de timelock. La vérification réduit mais n'élimine pas le risque de mises à jour incorrectes de la NAV, y compris les risques résultant de clés compromises, de données d'entrée erronées ou de vulnérabilités des smart contracts. L'historique des audits de Concrete est disponible à docs.concrete.xyz/audits.
- Le comportement de pause dépend d'un calibrage précis des seuils et de l'exactitude de la couche d'observation sous-jacente. Les pauses peuvent ne pas être déclenchées dans tous les scénarios de perte, et la conception vise à réduire, et non à éliminer, le risque que les nouveaux déposants effectuent des transactions à des prix obsolètes.
- Les vaults de Concrete sont construits selon le standard de vault ERC-4626, avec des extensions de file d'attente de retrait asynchrone par époque mises en œuvre au niveau du contrat. Le calendrier de règlement dépend du profil de liquidité de la stratégie sous-jacente et peut être soumis à des barrières au niveau du vault, à des événements de suspension et à d'autres conditions énoncées dans la documentation applicable du vault.
