Custody XRPL Approfondie

Pourquoi la custody est le point crucial de la régulation

De tous les services crypto, la custody est celui où les régulateurs appliquent la main la plus lourde. La raison est simple : la custody est le point d'entrée pour les pertes de fonds clients, la fraude et l'abus LCB-FT. Un échange défaillant peut être isolé ; un dépositaire défaillant emporte les actifs des clients avec lui.

Sous MiCA, la custody (Art. 75) exige l'exigence de capital la plus élevée de tous les services CASP (350 K€) plus des obligations strictes de conservation, de ségrégation et d'assurance. Sous FinCEN, la custody déclenche l'enregistrement MSB et souvent des licences de money-transmitter au niveau des États. Sous le régime VASP de la SFC à Hong Kong, la custody doit être à >98 % en cold storage.

La question de savoir si votre service est "custodial" détermine donc si vous avez besoin d'une licence lourde ou légère — ou d'aucune. XRPL vous offre une flexibilité inhabituelle : le protocole supporte plusieurs schémas de custody nativement, et la classification de chaque schéma diffère.

La distinction clé

Custodial

Un tiers détient les clés qui signent les transactions au nom de l'utilisateur. L'utilisateur fait confiance au tiers. Si ce tiers disparaît, les actifs aussi. Tous les hot wallets des échanges centralisés sont custodial. Les IOU émis par gateway sont custodial.

Non-custodial

L'utilisateur contrôle ses propres clés. Aucun tiers ne peut déplacer les fonds sans la signature de l'utilisateur. Les hardware wallets sont non-custodial. Les escrows verrouillés par le temps ou des conditions cryptographiques sont non-custodial — même un registre sans smart contract comme XRPL impose la libération au niveau du protocole.

Zone grise

Là où l'autorité de signature est divisée ou partagée — multi-sig, MPC, configurations regular-key-plus-master-key — les régulateurs n'ont pas émis d'orientations claires. La classification dépend typiquement de : une seule partie peut-elle agir seule ? Si oui, cette partie est le dépositaire. Sinon, la configuration penche vers le non-custodial.

Les 10 méthodes XRPL

XRPL offre dix manières distinctes de structurer qui peut signer. Trois sont clairement custodial, quatre sont clairement non-custodial, trois vivent en zone grise.

Clairement custodial

• Clé unique — le service détient la clé maître du compte XRPL de l'utilisateur. Contrôle total. C'est le modèle par défaut des échanges centralisés.
• IOU / Trust Lines (modèle gateway) — le service émet des jetons adossés à des réserves off-chain, les utilisateurs détiennent des créances. RLUSD suit ce schéma. Déclenche à la fois les règles de custody ET les règles d'émetteur.

Clairement non-custodial

• Escrow — XRP verrouillés par le temps ou une condition cryptographique. Le registre impose la libération. Aucun tiers nécessaire.
• Payment Channels — le déposant verrouille des XRP on-chain, le destinataire collecte des créances signées off-chain. La fermeture du canal est imposée par le protocole.
• Checks — "chèque" on-ledger où le compte de l'expéditeur n'est débité que lorsque le destinataire encaisse.
• Mode NFT Broker (XLS-20) — échange atomique d'offres d'achat et de vente. Le broker ne touche jamais au NFT.
• SignerList minoritaire — multi-sig où le service détient moins de clés que le quorum requis. Ne peut agir seul.

Zone grise

• Regular Key — clé secondaire assignée via SetRegularKey. Si le master reste actif chez l'utilisateur, la classification dépend de l'usage ; si le master est désactivé, le service est custodial.
• SignerList majoritaire — multi-sig où le service détient assez de poids pour atteindre le quorum seul. Généralement custodial ; certains soutiennent le contraire si les politiques opérationnelles exigent la co-signature de l'utilisateur.
• MPC / TSS — signatures à seuil implémentées au niveau applicatif. La clé n'existe jamais en entier. Argument technique fort de non-custodial ; ESMA et FCA n'ont pas tranché.
• MPT (XLS-33) — jetons programmables. L'émetteur peut verrouiller (lsfLocked) ou exiger une autorisation (lsfRequireAuth). Selon l'usage, peut être traité comme IOU (custodial) ou comme Autre crypto-actif.

Concevoir votre architecture pour la conformité

Une architecture défensive part du résultat réglementaire souhaité et remonte aux primitives XRPL. Trois profils cibles courants :

1. Custody institutionnelle — vous VOULEZ être custodial

Embrassez les obligations de l'Art. 75 CASP / MSB et structurez pour la crédibilité institutionnelle. Utilisez MPC ou SignerList majoritaire avec des workflows formels de signature multi-parties. Cold storage >98 % pour les juridictions retail. Ségréguez les comptes clients au niveau du compte XRPL (un compte par client, pas de wallets mutualisés). La voie est coûteuse mais crédible.

2. Infrastructure self-custody — vous NE voulez PAS détenir de clés

Livrez un logiciel ou des services qui aident les utilisateurs à garder eux-mêmes leurs actifs XRPL. Utilisez SignerList minoritaire (le service est 1-sur-3, l'utilisateur détient 2). Combinez avec Regular Key où l'utilisateur conserve toujours le master. L'utilisateur est la seule partie pouvant atteindre le quorum. Vous échappez au CASP mais devenez fournisseur de logiciel.

3. Rails de paiement — primitives du protocole

Pour les cas d'usage de paiement, streaming ou escrow, appuyez-vous sur Escrow, Payment Channels et Checks. Ces primitives sont imposées par le protocole et évitent totalement la custody. Votre exposition CASP glisse vers les "services de transfert" (Art. 82, 50 K€ de capital), plus léger que la custody.

Étude de cas : RLUSD et la gateway IOU

Le stablecoin RLUSD de Ripple est l'implémentation de référence d'une gateway IOU conforme sur XRPL. Standard Custody & Trust Company (chartée par le NYDFS) émet RLUSD via une trust line XRPL. Les utilisateurs détiennent les soldes RLUSD comme des créances on-chain contre le trust.

Choix de conception clés :

• Drapeau RequireAuth sur le compte émetteur — les détenteurs doivent être explicitement autorisés par l'émetteur. KYC on-chain.
• Drapeau freeze — le trust peut geler des trust lines individuelles pour des blocages LCB-FT.
• Drapeau globalFreeze — frein d'urgence gelant toutes les trust lines.
• Adossement 1:1 en dépôts en cash + Treasuries US à court terme, ségrégué des fonds propres de Ripple.
• Émissions séparées sur XRPL et Ethereum — pas de pont, chaque chaîne est une émission indépendante.

Le modèle montre que "custodial" ne signifie pas "centralisé à l'ancienne". Une gateway IOU bien conçue offre la clarté juridique de la custody bancaire traditionnelle avec des primitives de conformité on-chain que les stablecoins ERC-20 doivent rétrofitter via des fonctions admin.