Gestion des clés RWA tokenisés : passphrase, multisig ou MPC

Pourquoi le détenteur de la clé compte plus que le ticker

Lorsqu’un fonds se décrit comme « adossé 1:1 à des bons du Trésor américains à courte échéance » via un token comme OUSG ou USDY, la créance juridique porte sur un véhicule ad hoc à l’abri de la faillite, pas sur le token. Le token n’est qu’une écriture comptable qui pointe vers le compte bancaire de ce SPV. Ce qui détermine réellement si le token est remboursable, qui peut déplacer les liquidités sous-jacentes et qui est payé lors d’une liquidation, c’est l’ensemble des clés privées attachées au portefeuille de trésorerie on-chain. Tout le reste, le nom de l’auditeur, l’avis juridique, l’attestation, n’est que de la paperasse qui suit les clés.

C’est pourquoi deux produits ayant la même composition, par exemple deux fonds monétaires tokenisés qui détiennent tous deux BUIDL de BlackRock ou des bons du Trésor comparables, peuvent présenter des profils de risque radicalement différents. L’un peut gérer sa trésorerie via un Gnosis Safe 4-of-7 détenu par des dirigeants nommément identifiés chez un dépositaire qualifié, avec des politiques de rotation et un examen indépendant des transactions. L’autre peut utiliser un multisig 2-of-4 dans lequel trois des signataires sont des prestataires du même émetteur. Les symboles des tokens semblent identiques. Le scénario de reprise en cas de crise ne l’est pas.

Pour un allocateur professionnel, un distributeur ou un auditeur, la question « qui contrôle les clés ? » est la première à résoudre avant de parler de rendement, de liquidité ou de juridiction. Le reste de cet article présente les trois schémas de contrôle que vous rencontrerez réellement, ce pour quoi chacun est vraiment efficace, et les endroits où chacun échoue discrètement.

Clés contrôlées par l’opérateur : le point de défaillance unique discret

Le dispositif le plus souvent présenté comme « institutionnel » reste celui des clés contrôlées par l’opérateur. Une petite équipe, souvent deux ou trois personnes chez l’émetteur, un administrateur de fonds ou un fournisseur de services managés, détient la phrase de récupération ou le dispositif de signature matériel du portefeuille de trésorerie. Parfois, le portefeuille est un multisig, mais les mêmes deux ou trois personnes physiques occupent tous les emplacements requis. L’étiquette « multisig » passe l’audit parce que le seuil de signature paraît diversifié, mais les personnes derrière ces emplacements sont concentrées.

Les risques ne sont pas théoriques. Dans l’industrie crypto au sens large, des portefeuilles à opérateur unique ont été vidés par phishing, ingénierie sociale visant les détenteurs de sauvegardes et malversations internes. Dans un contexte de RWA tokenisés, les conséquences sont pires, car les actifs sont censés être des créances sur une entité réglementée. Une clé compromise peut vider la trésorerie on-chain plus vite qu’un tribunal ne peut geler le compte bancaire qui la garantit. Une fois que des stablecoins ou des bons du Trésor tokenisés quittent le portefeuille, le recouvrement dépend de l’analyse on-chain et de la bonne volonté des plateformes centralisées, pas de l’enveloppe juridique.

Les structures de SPV à l’abri de la faillite ne protègent que contre l’insolvabilité de l’émetteur. Elles ne font rien contre un signataire compromis, un signataire contraint dans une juridiction hostile, ou un détenteur de clé qui disparaît tout simplement. Si vous ne pouvez pas nommer les personnes physiques qui détiennent chaque fragment, dire où elles vivent et expliquer ce qui se passe si deux d’entre elles sont indisponibles le même jour, vous n’avez pas encore une histoire de conservation institutionnelle. Vous avez une histoire marketing.

La passphrase, ou « 25e mot », et ce qu’elle protège réellement

Une passphrase BIP-39 est un mot supplémentaire, généralement de 8 à 30 caractères, ajouté à la seed phrase standard de 12 ou 24 mots. La seed seule ne suffit pas à déplacer des fonds ; la seed et la passphrase sont toutes deux nécessaires. Comme la passphrase n’est jamais inscrite dans la sauvegarde de la seed et ne quitte jamais la mémoire du signataire, elle transforme une sauvegarde volée en objet inutile. C’est son véritable rôle.

Ce que la passphrase ne fait pas, c’est répartir la confiance. Elle renforce la sécurité d’un signataire contre le vol, la perte et la contrainte portant sur la sauvegarde physique. Elle ne vous aide pas à construire un quorum au sein d’un conseil, d’un SPV ou chez un administrateur de fonds. Si l’unique signataire est compromis et révèle à la fois la seed et la passphrase, la passphrase n’offre aucune protection. Elle est aussi impitoyable : oubliez-la, et le wallet est perdu pour toujours, sans service de récupération, sans assistance téléphonique, sans décision de justice capable de le retrouver.

Pour les émetteurs de RWA tokenisés, la passphrase doit donc être comprise comme une couche de renforcement pour des signataires individuels au sein d’un dispositif plus large, et non comme une architecture de custody à elle seule. C’est la bonne réponse à la question « que se passe-t-il si une seed phrase fuit depuis un coffre bancaire ? » C’est la mauvaise réponse à la question « comment s’assurer qu’aucun initié seul ne peut déplacer la trésorerie ? »

Wallets multisig : répartir l’autorité entre des êtres humains

Un wallet multisig, généralement un smart contract m-sur-n comme Gnosis Safe pour les chaînes EVM, exige m signatures distinctes parmi un ensemble de n adresses autorisées pour approuver une transaction. Une configuration 3-sur-5 signifie que trois des cinq signataires nommés doivent signer. Chaque signataire peut être un hardware wallet, un produit de custody institutionnelle, ou même un smart account exploité par une autre équipe. Comme le wallet lui-même est un smart contract, la politique, l’ensemble des signataires et chaque signature sont visibles on-chain, ce qui est à la fois une fonctionnalité et une empreinte.

Les véritables forces du multisig sont opérationnelles. Vous pouvez exiger que plusieurs dirigeants, un administrateur de fonds et un examinateur indépendant signent tous avant tout mouvement de valeur. Vous pouvez faire tourner les signataires en soumettant une transaction on-chain qui remplace une ancienne clé par une nouvelle, la rotation elle-même étant contrôlée par le seuil existant. Vous pouvez superposer une séparation des rôles : un ensemble de signataires approuve les petits transferts courants ; un ensemble plus large est requis pour tout montant au-dessus d’un plafond défini. C’est pourquoi presque toutes les trésoreries crédibles de RWA tokenisés, y compris le programme OUSG d’ONDO et les arrangements de distribution de BUIDL, passent par un multisig au niveau du protocole plutôt que par un seul compte détenu en externe.

Les véritables faiblesses sont tout aussi réelles. Le multisig répartit l’autorité entre des personnes, pas entre des éléments de clé. Si trois des cinq signataires sont des employés du même émetteur, l’étiquette « distribué » est cosmétique. Les changements de seuil sont également lents : faire tourner un signataire compromis peut lui-même nécessiter la signature d’un quorum, ce qui convient jusqu’au moment où le quorum inclut lui-même la clé compromise. Enfin, chaque adresse de signataire est publique, ce qui signifie qu’un attaquant recourant à la contrainte sait exactement qui cibler. Pour les trésoreries de grande valeur, c’est pourquoi les programmes sérieux associent le multisig au cold storage, à une répartition géographique des signataires et à des cosignataires indépendants tels que des dépositaires qualifiés ou des cabinets d’avocats.

Threshold et MPC : répartir la clé elle-même

Les schémas de signature threshold et le multiparty computation franchissent l’étape suivante. Au lieu de n clés privées indépendantes qui doivent être réunies pour signer, la clé privée est générée sous forme de n parts, distribuée entre les parties, puis utilisée pour produire une signature sans jamais être reconstituée. Chaque partie détient une part inutile à elle seule. Un seuil t de ces parts peut signer conjointement ; un nombre inférieur ne le peut pas. Les familles courantes incluent threshold ECDSA, threshold EdDSA et des protocoles de Fireblocks, Anchorage, BitGo, ainsi que plusieurs stacks open-source.

Pour les institutions, l’intérêt est opérationnel. Aucun initié ne possède jamais une clé complète, il n’y a donc pas de seed phrase à voler ni de hardware wallet à contraindre. Les signataires peuvent fonctionner sur des serveurs renforcés dans différentes juridictions, avec une politique appliquée par logiciel plutôt que par un rituel humain. Les transactions peuvent être approuvées via des workflows d’entreprise familiers : un dirigeant se connecte à une console, la demande est acheminée via des règles de conformité, et un seuil de nœuds de calcul produit une signature valide. Cela se rapproche beaucoup plus de ce qu’un dépositaire régulé, une équipe de trésorerie bancaire ou un grand gestionnaire d’actifs attend d’un cold storage ségrégué.

Le compromis est la complexité. Les stacks MPC sont plus difficiles à auditer qu’un multisig dont l’intégralité du code source est publique. Les cérémonies de génération de clés, c’est-à-dire les événements où les parts sont créées et distribuées, doivent être menées avec des preuves vidéo, des observateurs indépendants et des sources d’entropie documentées, sinon les parts résultantes sont plus faibles qu’elles n’en ont l’air. Il y a également eu de véritables cas d’échec de récupération : au moins une grande plateforme d’échange a publiquement révélé qu’une erreur de rotation de clé MPC avait rendu des fonds de clients inaccessibles jusqu’à un effort de reconstruction manuelle de plusieurs mois. MPC réduit la surface d’attaque pour le vol ; il n’élimine pas le mode de défaillance d’une gestion ratée du cycle de vie des clés. Le cadrage honnête est que MPC est la bonne réponse pour les flux institutionnels à haut volume et pilotés par des politiques, tandis que le multisig reste la bonne réponse pour les mouvements de trésorerie lents et peu fréquents, où la transparence de la politique de signature compte davantage que le débit.

Comment lire les déclarations de custody d’un émetteur

Lorsqu’un émetteur de RWA tokenisés publie une déclaration de custody ou de risque, les questions utiles sont concrètes. Premièrement, quelle est l’adresse on-chain du wallet de trésorerie, et de quel type s’agit-il : EOA, multisig ou smart account ? Vous pouvez le vérifier sur un explorateur de blocs en quelques secondes. Deuxièmement, qui sont les signataires nommés, et à quel point sont-ils indépendants ? Recherchez la présence d’un dépositaire qualifié, d’un administrateur de fonds et d’un administrateur non affilié. Troisièmement, quel est le seuil, et quelle est la politique de rotation ? Un 3-sur-7 avec rotation documentée est significativement différent d’un 2-sur-3 où les trois personnes se trouvent dans le même canal Slack.

Quatrièmement, où les liquidités sous-jacentes sont-elles détenues, et existe-t-il un véritable SPV à l’abri de la faillite entre l’émetteur et le compte bancaire ? Les Treasuries tokenisés qui regroupent les actifs au niveau de l’émetteur, plutôt qu’au sein d’un véhicule ségrégué, exposent les détenteurs aux créanciers de l’ensemble de l’émetteur. Cinquièmement, quel est le scénario de récupération si deux détenteurs de clés sont indisponibles le même jour ? Un programme doté d’un plan de succession écrit et testé est fondamentalement différent d’un programme qui découvrirait les lacunes lors d’une véritable panne. Ce ne sont pas des questions théoriques ; elles font la différence entre un fonds tokenisé qui paie les rachats en période de crise et un fonds qui devient silencieux.

Clés opérationnelles vs clés de gouvernance : une séparation que la plupart des émetteurs négligent

L’une des distinctions les plus importantes dans la garde des actifs RWA tokenisés est celle entre les clés opérationnelles et les clés de gouvernance. Les clés opérationnelles servent aux flux courants : règlements des souscriptions et des rachats, transferts de frais, rééquilibrage entre plateformes. Elles devraient passer par un multisig ou un MPC avec un plafond faible par transaction et un cycle de rotation rapide. Les clés de gouvernance sont les contrôles d’urgence : fonctions de pause, fonctions de mise à niveau, changements de pointeur qui redirigent un jeton vers un nouvel actif sous-jacent. Elles devraient être placées derrière un seuil plus élevé, un rythme plus lent et des signataires plus indépendants.

La séparation de ces deux couches est ce que la plupart des émetteurs « institutionnels » négligent, parce qu’il est moins coûteux de confier les deux pouvoirs à la même petite équipe. Résultat, une attaque de phishing contre un ingénieur d’exploitation junior peut conduire non seulement à une mauvaise transaction, mais aussi à une mise à niveau du contrat lui-même. Pour un professionnel qui évalue un produit, demander si les clés opérationnelles et de gouvernance sont séparées, et si elles partagent des signataires, est l’un des moyens les plus rapides de distinguer le marketing de la substance.

Comment suivre la gestion des clés RWA de la bonne manière

La gestion des clés RWA évolue discrètement, au fil des votes de gouvernance, des rotations de signataires et des rapports d’audit qui font rarement la une. Suivre qui contrôle réellement quel portefeuille, et si ces contrôles ont changé, est un exercice perdu d’avance si vous vous fiez uniquement aux annonces. Zippfeed fait remonter les titres RWA avec une classification de sentiment étiquetée bullish, neutral ou bearish, ainsi qu’une note d’importance, pour que vous puissiez repérer les changements de garde, les départs de signataires et les votes de gouvernance avant qu’ils n’apparaissent dans un rapport trimestriel.