Actifs générant des revenus : quelle sécurité ? Solv Guard enferme-t-elle les risques imbriqués ?
TechFlow SélectionTechFlow Sélection
Actifs générant des revenus : quelle sécurité ? Solv Guard enferme-t-elle les risques imbriqués ?
Avec Solv Guard, maman n'a plus à s'inquiéter quand je joue aux poupées russes du DeFi.
Dédié à des analyses Web3 approfondiesQuand on évoque la vague actuelle de DeFi, quelle est votre première impression ? Bien sûr, c’est l’emboîtement ! Emboîtement ! Emboîtement !
Mais cet emboîtement n’est qu’une apparence. Le véritable changement réside dans la transformation du paradigme au niveau d’émission des actifs. Auparavant, lorsqu’on utilisait le DeFi, les actifs liquides étaient principalement des actifs natifs fondamentaux comme l’ETH. Mais aujourd’hui, ces actifs liquides sont souvent encapsulés : stETH, USDe, puffETH, rzETH, et bien d’autres encore, dont le nombre ne cesse de croître. En termes modernes, on les appelle des actifs porteurs de rendement. Les actifs sous-jacents assurent la sécurité économique d’Ethereum, tandis que les rendements peuvent provenir d’autres sources financières. Toutefois, la sécurité reste une préoccupation constante : chaque protocole peut émettre un nouvel actif, mais les actifs natifs sont toujours gérés via des portefeuilles multisignatures ou des tiers centralisés, laissant subsister des points de défaillance unique.
On peut dire que ce problème constitue aujourd’hui le dilemme des principaux protocoles DeFi émergents et de leurs utilisateurs. Existe-t-il donc une solution de sécurité universelle applicable à tous les protocoles DeFi de ce type ? À ce jour, la seule réponse disponible est Solv Guard, un mécanisme de sécurité généralisé développé par l’équipe derrière Solv Protocol, un protocole de rendement et de liquidité multi-chaînes. Dans cet article, j’analyserai en profondeur cette solution en retraçant l’évolution historique de la gestion d’actifs dans le DeFi.
I. L’été DeFi : des actifs entièrement contrôlés par algorithmes
L’été 2020 du DeFi fut un mythe pour le monde Crypto. Des projets comme Uniswap, Bancor, Aave, Compound et MakerDAO ont jeté les bases du développement du DeFi. Grâce aux AMM (market makers automatisés) et au « minage de liquidité », la finance traditionnelle a pu découvrir le caractère révolutionnaire et rationnel de la crypto. Du point de vue du rendement utilisateur et de la gestion d’actifs, ces systèmes reposaient sur des pools de liquidité simples. Les utilisateurs devaient interagir manuellement avec chaque pool, effectuer des dépôts et retraits sur plusieurs plateformes. Comme chaque pool était isolé, il était difficile pour les utilisateurs d’optimiser rapidement leurs placements vers les taux les plus élevés, rendant les opérations complexes et les gains potentiels limités.
Face à ce problème, Yearn a introduit l’agrégateur de rendement (communément appelé « gun vault »), permettant aux utilisateurs de confier leurs actifs à un contrat intelligent qui redistribue automatiquement les fonds entre différents pools pour optimiser le rendement. En somme, l’agrégateur représente un modèle de gestion passive d’actifs. À cette époque, que ce soit pour les swaps, le prêt ou les « gun vaults », la sécurité des fonds et le rendement restaient limités par les contraintes des pools de base. Autrement dit, si l’agrégation simplifiait la gestion pour l’utilisateur, la logique sous-jacente des pools n’avait pas évolué.
II. L’ère PoS d’Ethereum : rendement génératif et gestion active d’actifs
Avec la transition d’Ethereum du PoW au PoS, le staking ETH a ouvert de nouvelles possibilités pour le DeFi. Prenons l’exemple de Lido : le 1er décembre 2020, la Beacon Chain d’Ethereum est lancée, et Lido voit le jour le même mois. Sous le mécanisme PoS, un nœud nécessite un staking minimal de 32 ETH. Lido permet aux utilisateurs disposant de moins de 32 ETH de participer au staking en regroupant leurs fonds, augmentant ainsi la sécurité du réseau principal. Lido résout également le problème de liquidité lié au staking : puisque les ETH bloqués perdent leur utilité immédiate, certains utilisateurs hésitent à staker, ce qui nuit à la sécurité du réseau. Lido propose donc un actif porteur de rendement, le stETH, échangeable contre les ETH stakés, résolvant ainsi simultanément les problèmes de sécurité et de liquidité.
L’apparition de Lido a impulsé un nouveau modèle de gestion d’actifs : la « gestion active ». Contrairement aux interactions directes avec des pools ou des agrégateurs passifs, c’est désormais un gestionnaire professionnel qui prend en charge la gestion des actifs. Ce modèle omniprésent en finance traditionnelle a été repensé par Lido dans l’univers DeFi. On peut considérer Lido comme un exemple de CeDeFi : les utilisateurs confient leurs actifs à un composant centralisé, adoptant une approche semi-centralisée qui offre des sources de rendement de meilleure qualité. Récemment, Lido prévoit toutefois de déployer son module Simple DVT sur le réseau principal, visant à décentraliser davantage le processus de staking. Après trois ans d’évolution, ce modèle de staking actif est devenu dominant dans le DeFi :
-
À la fin de l’année dernière, Blast, porté par Toshi, a popularisé ce modèle, captant 1 milliard de dollars en un mois grâce à un simple multisig.
-
Le secteur du restaking, lui, atteint déjà 14,8 milliards de dollars sur Ethereum, avec la plupart des projets adoptant initialement une gestion multisig.
-
L’infrastructure de restaking Bitcoin BounceBit délègue la gestion de liquidité à des tiers comme Ceffu, MainNet Capital, Antalpha et Fireblocks via un « règlement hors marché ».
-
Le protocole de stablecoin décentralisé Ethena fait de même, confiant sa garde à Cobo, Ceffu et Copper.
-
Ondo Finance, spécialisé dans les obligations américaines (RWA), adopte une structure de fonds classique, confiant ses fonds à des dépositaires régulés comme Clear Street.
-
......
III. De Compound à Solv Guard : comment gérer les actifs ?
Analysons d’abord les transformations intervenues au niveau des actifs dans les protocoles DeFi, car le modèle de rendement génératif a profondément modifié la structure des actifs DeFi.
Durant l’été DeFi, les protocoles reposaient exclusivement sur des contrats intelligents pilotés par algorithmes, où les utilisateurs pouvaient retirer leurs actifs à tout moment, détenant uniquement des actifs natifs de base. Ces modèles ne répondent plus aujourd’hui aux attentes en matière de rendement. Après une phase de croissance, les rendements des différents protocoles se sont homogénéisés, et les différences s’amenuisent. Par ailleurs, les protocoles purement algorithmiques sont statiques et incapables de gérer des schémas complexes de génération de revenus. En réalité, les actifs porteurs de rendement adoptent une architecture en deux couches : les actifs sous-jacents (BTC, ETH, USDT, etc.) et les actifs supérieurs (stETH, USDe, jetons LRT, etc.). Cette structure élargit continuellement les sources de revenus, contrairement aux protocoles traditionnels dont les revenus proviennent uniquement du staking ou du minage. Dans ce cadre, les différences entre les pools de liquidité sous-jacents s’accroissent. En tant que couche de liquidité, les actifs porteurs de rendement entretiennent une relation d’ancrage avec les actifs de base, avec des cycles de rachat variés.
Cette nouvelle structure binaire expose à de nouveaux risques de contrepartie. Fondamentalement, la « gestion active d’actifs » consiste à réutiliser les fonds des utilisateurs tout en émettant un jeton ancré servant d’actif liquide. Même si des méthodes sécurisées comme les multisigs, le règlement hors marché ou la supervision centralisée sont utilisées, un écart centralisé persiste. Imaginons : l’utilisateur A envoie des fonds au protocole B, qui les réaffecte à du restaking, les confie à un tiers ou les trade sur des CEX. Dans ce cas, le contrôle d’utilisation des fonds est entièrement transféré au projet et à ses gardiens. Autrement dit, ces protocoles mainstream combinant CeFi et DeFi présentent tous un risque de contrepartie lié au « gestionnaire d’actifs ».
La question devient alors celle de surveiller et limiter ce « gestionnaire d’actifs ». Quelles solutions existent sur le marché ? À ce jour, la seule réponse viable que j’ai identifiée est Solv Guard, un mécanisme de sécurité généralisé conçu par Solv Protocol, un protocole de rendement et liquidité multi-chaînes. Il est spécifiquement conçu pour personnaliser les stratégies de transaction selon les pools, en imposant un cadre personnalisé de permissions au gestionnaire d’actifs — destination des fonds, usage autorisé, droits d’opération, etc. — empêchant efficacement tout abus opaque des fonds.
Cette idée n’est pas sortie de nulle part. Compound, durant l’été DeFi, en fut le précurseur. Les connaisseurs savent que le mécanisme cToken de Compound fut le premier actif porteur de rendement. Son module de gouvernance proposait déjà une solution de sécurité face aux risques liés au cToken. Dans les versions v2 et v3, on trouve le composant « Pause Guardian ». Celui-ci n’est activé qu’en cas de vulnérabilité inconnue, avec une seule fonction : désactiver temporairement le minting, l’emprunt, le transfert et le liquidation. C’est un « arbitre » qui suspend la partie en cas d’urgence, sans pouvoir la relancer. Lors de la faillite de Silicon Valley Bank ayant entraîné la désindexation de l’USDC, il a ainsi suspendu temporairement les dépôts d’USDC sur Compound v2.
Compound a pensé à sécuriser les actifs, mais n’a pas séparé ce module. Solv va plus loin en extrayant et généralisant ce système de permissions. Car le DeFi a évolué vers l’ère de la gestion active, où les actifs porteurs de rendement deviendront la pierre angulaire de la prochaine génération de DeFi. Les sources de rendement ne se limiteront plus aux pools de minage, intégrant aussi la finance traditionnelle. Face à cette évolution, Solv Guard vise à devenir un mécanisme de sécurité universel, applicable à tous les protocoles similaires.
IV. Fonctionnement, fonctions et caractéristiques de Solv Guard
Après ce long rappel historique, passons au cœur du sujet. Expliquons pourquoi Solv Guard est un mécanisme de sécurité universel, comment il fonctionne, et quelles sont ses fonctionnalités et atouts.
Si l’on devait définir Solv Guard, ce serait une couche intermédiaire entre les actifs de base et ceux des utilisateurs, ajoutant une sécurité supplémentaire aux contrats intelligents. C’est à la fois un outil et un produit, pouvant devenir un composant standardisé pour toute l’industrie.
Fonctionnement
Actuellement, Solv Guard est construit sur le portefeuille intelligent Safe. Safe possède naturellement des capacités multisig, qui constituent une partie intégrante du mécanisme de sécurité de Solv Guard. Ce dernier limite précisément ces permissions multisig à un cadre défini.
Dans la pratique, Solv Guard attribue à chaque Vault un Vault Guardian, qui définit les adresses cibles et leurs permissions. Safe et Solv Guard vérifient ensuite la validité des transactions avant de les autoriser.
Comme illustré ci-dessous, la configuration des permissions repose sur trois éléments : les contrats autorisés, les fonctions autorisées, et la nécessité ou non d’une ACL (liste de contrôle d’accès). Autrement dit, vous pouvez préciser qui a le droit d’opérer les fonds, vers quel contrat ils doivent être envoyés, dans quels actifs investir, et quand et par qui le retrait peut être effectué.
Prenons Uniswap : si le gestionnaire souhaite utiliser nos fonds pour fournir de la liquidité et percevoir des frais, ces frais seront notre source de rendement. Comment définir Solv Guard ? D’abord, limiter qui peut investir et retirer les fonds. Ensuite, spécifier l’adresse du contrat Uniswap, car les fonds doivent y être dirigés. Pour fournir de la liquidité ETH/USDT, il faut fixer l’adresse du pool LP ainsi que celles des contrats ETH et USDT, et n’autoriser que ces deux jetons, empêchant le gestionnaire d’opérer sur d’autres jetons.
Bien sûr, le gestionnaire pourrait aussi acheter des obligations américaines, d’autres actifs ou faire du trading dérivé. Solv Guard intègre déjà des autorisations pour Uniswap V3, GMX V2, Compound, Lido, Ethena, PancakeSwap, etc.
Mécanisme de gouvernance
Comme le Pause Guardian de Compound, Solv Guard dispose d’un mécanisme de gouvernance séparant droit de gouvernance et droit d’utilisation.
Comme indiqué ci-dessous, le Solv Vault Guardian exécute les actions, mais le pouvoir de gouvernance revient au Governor, contrôlé par la communauté ou le gestionnaire, avec possibilité d’ajouter un TimeLock pour garantir la transparence et le choix des utilisateurs. Les droits du Governor incluent : mettre à jour le Guardian (en cas de bug empêchant le retrait), ajouter/supprimer des autorisations, autoriser ou interdire les transferts de jetons natifs, gérer la liste blanche, transférer les droits de gouvernance, hériter automatiquement des droits si nécessaire, ou désactiver définitivement la gouvernance.
Évolutions futures
À ce jour, Solv Guard est la première solution inspirée par Compound et bénéficiant du modèle de sécurité intrinsèque de Safe, ce qui lui a permis une adoption rapide.
Prochainement, Solv Guard s’étendra au développement généralisé de contrats intelligents, formant un cadre standard de sécurité pour renforcer l’ensemble des contrats. Par exemple, la nouvelle version de Solv Vault n’utilisera plus nécessairement le portefeuille Safe multisig, mais conservera le cadre Guard pour protéger les flux de traitement des actifs, améliorant ainsi la sécurité globale tout en conservant une stratégie de sécurité flexible. À terme, cela pourrait inciter des contrats populaires comme Compound à adopter ou s’inspirer de Solv Guard, rendant le contrôle de sécurité plus standardisé et transparent.
ERC-3525
Revenons aux actifs porteurs de rendement : je dois mentionner ERC-3525, car le cadre de Solv Guard y est étroitement lié. ERC-3525 est un standard de jeton semi-fongible proposé par les membres fondateurs de Solv Protocol, combinant les caractéristiques d’ERC-20, ERC-721 et ERC-1155. Il convient particulièrement aux monnaies, titres, bons, obligations, options, contrats à terme, stratégies d’assurance, etc., avec une forte composable.
La structure ERC-3525 comprend id, value, slot et address. Chaque slot peut contenir plusieurs id, chacun avec sa propre valeur. En termes simples, chaque slot est un compte principal contenant plusieurs sous-comptes, entre lesquels les transferts sont possibles.
* Pour en savoir plus sur ERC-3525, lire l’article : « ERC-3525 sous-estimé : la clé de l’adoption massive du Web3 ? »
Solv Guard supporte principalement les actifs émis via ERC-3525, car ce standard permet de gérer une infinité d’actifs sous-jacents (comme ERC-20) via un seul contrat. Comme mentionné précédemment, dans la gestion active, les actifs sous-jacents sont distribués dans de nombreux pools. En définissant chaque slot comme un pool, un seul contrat ERC-3525 peut gérer une multitude de pools. Pour différentes demandes d’utilisateurs — par exemple, des périodes de rachat variables — ERC-3525 permet de gérer diverses tâches via un seul contrat.
En résumé, ERC-3525 s’adapte parfaitement à la gestion active et aux actifs porteurs de rendement, avec un coût de développement moindre et une sécurité accrue. Toutefois, Solv n’oblige pas les projets à utiliser ERC-3525 ; il reste compatible avec ERC-20.
Conclusion
En arrivant ici, vous comprenez que l’équipe Solv élabore une norme et un cadre de sécurité universels, non pas ex nihilo, mais en réponse à un besoin criant issu de l’évolution historique de la gestion d’actifs DeFi. Les actifs porteurs de rendement deviennent effectivement le nouveau paradigme dominant. Nous ne pouvons ni nier le rôle des tiers centralisés dans le DeFi, ni leur accorder aveuglément notre confiance. La solution ? Placer les gestionnaires de fonds de ces modèles/protocoles dans la « cage » de Solv Guard, en ajoutant une couche de sécurité pour protéger l’ensemble de l’écosystème DeFi.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
Foresight News
