Guide de sécurité écologique de Pharos : Gestion des risques de bout en bout pour l'intégration des actifs RWA

null

Cet article vise à fournir aux développeurs de l’écosystème Pharos une référence plus pratique et approfondie pour l’intégration des RWA. Nous tentons, du point de vue de la logique métier et de l’architecture de gestion des risques, de reconstituer les défis complexes et les solutions lors de la mise en chaîne d’actifs du monde réel (RWA).

Introduction

L’écosystème Pharos s’efforce de devenir une infrastructure reliant les actifs financiers traditionnels au monde Web3. Contrairement aux actifs cryptographiques natifs, les actifs du monde réel (RWA) combinent des droits réels hors chaîne et des propriétés de transaction en chaîne. Cette double nature détermine que leur frontière de sécurité ne peut se limiter au niveau des contrats intelligents, mais doit s’étendre à chaque étape de la vérification de propriété, de synchronisation des données et de régulation conforme.

Après une analyse approfondie des principaux projets RWA[1], nous examinerons, sous trois dimensions — modèles d’architecture, principaux risques et stratégies d’intégration — les voies clés pour que les développeurs Pharos construisent des applications RWA robustes.

1. Pourquoi Pharos est-il adapté aux RWA ?

Pharos est une couche 1 conçue pour une échelle de type Internet. Pour les développeurs RWA, il n’est pas nécessaire de se plonger dans les détails du consensus sous-jacent, il suffit de se concentrer sur la résolution de deux enjeux centraux : la compensation des actifs et les calculs complexes.

Exécution parallèle et confirmation en sous-seconde (Block-STM) La gestion sérielle des transactions par les EVM traditionnels peut provoquer des congestions lors de distributions ou rééquilibrages importants de RWA. Pharos introduit le moteur d’exécution parallèle Block-STM, permettant une finalité en sous-seconde.

Cela signifie que la réception de fonds hors chaîne et la compensation en chaîne peuvent être pratiquement synchronisées, éliminant ainsi le risque de fluctuation de change et de slippage liés à “T+1”.

Architecture Dual-VM (EVM + WASM) Pharos supporte nativement deux environnements d’exécution : EVM et WASM.

Niveau EVM : connectivité. Les protocoles de prêt Solidity existants, les codes DEX peuvent être déployés directement pour supporter les actifs RWA.

Niveau WASM : calculs. Les RWA impliquent des logiques complexes telles que la fiscalité des intérêts, la gestion hiérarchique des risques et la liste blanche de conformité, qui sont coûteuses et inefficaces à exécuter en Gas sur EVM. Ces calculs intensifs peuvent être migrés vers des modules WASM pour une haute performance et un faible coût en gestion des risques en chaîne.

2. Deux logiques opérationnelles pour les RWA

Avant de concevoir un protocole RWA sur Pharos, les développeurs doivent clarifier deux principaux modes de circulation d’actifs et leur flux de fonds :

Mode chaîne vers hors chaîne

C’est le mode le plus courant : levée de fonds en chaîne, gestion financière hors chaîne. L’investisseur stake des stablecoins (ex : USDC) en chaîne → l’équipe du projet convertit en fiat (USD) après collecte → investissement dans des actifs liquides hors chaîne (ex : obligations américaines) → les intérêts générés reviennent en chaîne et sont distribués aux détenteurs de tokens.

Exemple : $STBT$ de Matrixdock. Les investisseurs qualifiés minent $STBT$ (ancré 1:1 sur une obligation à court terme US), les fonds étant utilisés par le projet pour acheter des obligations, avec un rendement annuel d’environ 4,8%.

Mode d’actifs en chaîne

Ce mode se concentre sur la titrisation et la fragmentation d’actifs spécifiques. Le projet verrouille un actif hors chaîne (ex : immobilier) et l’évalue → émet des tokens ERC-20 correspondant à des parts → les investisseurs achètent avec des stablecoins → le projet maintient et exploite l’actif hors chaîne → les flux de trésorerie (ex : loyers) sont distribués périodiquement en chaîne.

Exemple : tokenisation immobilière de RealT. Par exemple, une propriété à Détroit évaluée à 65 900 USD est divisée en 1300 tokens, permettant aux investisseurs d’obtenir des dividendes locatifs en achetant ces tokens.

3. Carte des risques et stratégies d’intégration Pharos

Les risques critiques des RWA ne résident pas dans le code, mais dans la connexion entre le hors chaîne et le en chaîne. La majorité des projets RWA présentent des défauts structurels en matière d’authentification, de fixation d’actifs et de transparence des données. Lors de la construction d’applications sur Pharos, il faut prioriser la prévention des risques “gris rhinocéros” suivants.

Conformité d’identité transparente

Les projets prétendent être conformes, mais restent souvent formels. Selon les statistiques, moins de la moitié des projets ont une vérification KYC efficace, et certains projets renommés (ex : RealT) ont vu leur étape de vérification vidéo facilement trompée avec une simple photo. Certains projets insistent sur AML dans leur whitepaper, mais en pratique, il suffit de connecter un portefeuille pour échanger, rendant impossible le suivi des fonds.

Recommandations pour le développement sur Pharos :

Ne pas limiter la vérification d’identité au front-end web. Intégrer un mécanisme de liste blanche au niveau du contrat intelligent, pour que seules les adresses vérifiées via DID (identité décentralisée) ou KYC hors chaîne puissent appeler mint ou transfer. Par exemple, réécrire les fonctions transfer et transferFrom d’ERC-20 pour que seules celles des adresses en liste blanche puissent les utiliser.

Pour les transactions d’actifs de grande valeur, introduire une authentification à 2 facteurs (2FA) pour prévenir le vol d’actifs par fuite de clé privée. Des études montrent que peu de projets ont mis en œuvre cette mesure.

Dépendance aux stablecoins et mécanisme de circuit-breaker

Les stablecoins sont le sang des RWA : près de 90 % des projets dépendent de stablecoins pour la compensation. Mais ils ignorent souvent le risque de déconnexion, comme lors de l’incident SVB avec USDC ou le risque de déconnexion d’USDe$STBT . En cas de déconnexion, le projet dispose-t-il d’un fonds de réserve dédié pour gérer la crise ?

Recommandations pour le développement sur Pharos :

Les oracles ne doivent pas se limiter à fournir des prix, mais agir comme déclencheurs de gestion des risques. Lorsqu’un stablecoin (ex : USDC/USDT) s’écarte de son ancrage de plus de 5 %, le contrat doit automatiquement suspendre la mint et la redemption pour éviter une attaque d’arbitrage.

Lors de la conception du pool de liquidités, envisager le support de plusieurs stablecoins ou d’un panier de devises pour réduire le risque systémique d’un seul actif. Éviter autant que possible les stablecoins algorithmiques complexes, qui sont plus susceptibles de déconnecter.

Ponts de données et vérification de la véracité

Le plus grand “boîte noire” des RWA réside dans la vérification que les actifs en chaîne correspondent réellement à des biens physiques hors chaîne. Beaucoup de projets ne font que publier quelques PDF sur leur site, ou ont même utilisé des vidéos en boucle pour simuler une surveillance en temps réel. Le rapport de valeur nette d’actifs d’OpenEden a aussi été en retard d’un mois.

Recommandations pour le développement sur Pharos :

Utiliser des oracles comme Chainlink pour se connecter directement aux API des banques ou auditeurs qui détiennent les actifs hors chaîne. Les développeurs doivent viser à faire enregistrer la valeur nette d’actifs (NAV) en chaîne à la minute, plutôt que de se fier uniquement aux rapports mensuels ou trimestriels du projet.

Le risque de déviation de valorisation est fréquent. Intégrer plusieurs sources d’oracles pour que le prix en chaîne reflète au mieux le marché hors chaîne.

Isolation et transparence des entités juridiques

Le défaut de paiement d’actifs hors chaîne est un risque majeur pour les RWA, comme l’incident de Goldfinch avec un défaut de crédit de 5,9 millions de dollars[2]. La clé pour isoler ce risque réside dans la structure SPV, mais peu de projets déclarent publiquement utiliser cette structure, et la plupart ne divulguent pas le nom des entités enregistrées. Lors de la crise Goldfinch, cela a directement entraîné une chute de 20 % du token, avec des pertes importantes pour les investisseurs.

Recommandations pour le développement sur Pharos :

Dans les métadonnées ou la documentation du projet, obliger à divulguer le nom légal et le lieu d’enregistrement du SPV détenant les actifs.

S’assurer que chaque pool d’actifs est associé à un SPV distinct. Dans la conception des contrats sur Pharos, les fonds de différents pools doivent être logiquement complètement isolés, pour éviter qu’un défaut d’actif unique ne cause la défaillance de toute la liquidité du protocole.

Liquidité après la fausse prospérité

La liquidité est le maillon le plus facilement falsifiable mais aussi le plus susceptible de s’effondrer dans un projet RWA[4]. Beaucoup de projets dépendent fortement des subventions des market makers lors du lancement. Une fois ces subventions terminées ou arrêtées, la profondeur du marché secondaire chute brutalement, avec disparition instantanée des ordres d’achat. De plus, la faible fréquence d’évaluation hors chaîne (mensuelle ou trimestrielle NAV) et la haute fréquence des transactions en chaîne (secondes) créent un décalage temporel naturel. Lorsqu’un gros volume de vente apparaît en chaîne, le pool AMM ne peut pas rapidement ajuster le prix en l’absence de valeur de référence en temps réel, ce qui entraîne un écart important par rapport à la valeur nette, créant un trou de liquidité. La figure ci-dessous $GFI illustre un exemple : lors d’un run, le prix du token chute rapidement de 1 USD à 0,5 USD en quelques heures[2].

Recommandations pour le développement sur Pharos :

Ne pas miser toute la liquidité sur les marchés secondaires DEX ou CEX. Intégrer dans le contrat une file d’attente de rachat/rachat. Lorsqu’un prix en marché secondaire s’écarte fortement de la NAV (ex : discount > 3 %), permettre aux détenteurs de contourner le marché secondaire et de demander directement le rachat des actifs sous-jacents du SPV, géré par le contrat intelligent.

S’inspirer du système de réserves des banques traditionnelles : lors de l’émission (Mint), réserver un certain pourcentage (ex : 5-10 %) de stablecoins comme tampon de liquidité en chaîne. Ces fonds ne servent pas à acheter des actifs hors chaîne, mais à effectuer des rachats instantanés automatiques en cas de crise de liquidité, pour maintenir le prix au minimum.

Risque d’héritage des vulnérabilités EVM natives

Pharos offre une compatibilité totale avec EVM, ce qui signifie que les développeurs bénéficient de la commodité de Solidity tout en héritant des vecteurs d’attaque classiques. Les contrats RWA, en raison de leur conformité, contiennent souvent de nombreuses fonctions à haut niveau de privilège (ex : blacklist, forceTransfer, pause), rendant la gestion des permissions et la mise à niveau par proxy des failles critiques plus sensibles que dans la DeFi.

Recommandations pour le développement sur Pharos :

Respecter strictement les bibliothèques standards : ne pas réinventer la roue. Utiliser OpenZeppelin’s AccessControl ou Ownable2Step pour la gestion des permissions. En cas de vol de la clé privée d’un administrateur à cause d’une faille dans la logique personnalisée, cela peut entraîner des litiges juridiques sur la propriété des actifs physiques hors chaîne.

Contrôle de mise à niveau par proxy : les contrats RWA sont souvent déployés en mode upgradeable (UUPS/Transparent). Lors de la mise à jour, vérifier rigoureusement les conflits de slots de stockage (Storage Slot) pour éviter que des variables ne soient écrasées, ce qui pourrait désynchroniser la table de mappage des actifs.

Protection contre la re-entrée : lors de la distribution de rendement ou du rachat, même pour les adresses en whitelist, ajouter un ReentrancyGuard sur toutes les fonctions externes (Call) pour prévenir toute exploitation par des contrats malveillants via des callbacks.

4. Conclusion

En rétrospective, le développement du secteur RWA a été marqué par beaucoup de fausses prospérités, reposant sur des emballages UI ou la simple maintenance de liquidité par market makers. Dans l’écosystème Pharos, nous prônons une approche de développement plus résiliente.

Les développeurs doivent prendre conscience que : la sécurité des RWA ne réside pas uniquement dans le code des contrats intelligents, mais aussi dans la vérification de propriété hors chaîne et la gestion du décalage de liquidité. La finalité en sous-seconde de Pharos nous donne la confiance pour gérer des opérations financières complexes, mais cela impose une rigueur accrue dans l’intégration : écrire la vérification KYC/AML dans la logique de base, faire respecter la réserve de sécurité par le code, et maximiser la transparence des données d’actifs.

À l’avenir, la compétition entre protocoles RWA ne sera plus une question de TVL, mais de véracité des actifs et de robustesse du système. La boucle de sécurité ultime, celle qui garantit la fiabilité, est la responsabilité de chaque bâtisseur de l’écosystème Pharos.