Avant de parler de propriété ou de garde, il faut poser une distinction plus fondamentale : le bien et sa représentation numérique ne sont pas la même chose. Toute la pédagogie XRPL repose là-dessus.
Un token sur XRPL n'est pas le bien. C'est une représentation du bien. Ces deux objets sont distincts, reliés par un pont juridique ou contractuel. Comprendre cette dualité, c'est comprendre tout XRPL.
Existe dans le monde physique ou juridique, indépendamment de toute blockchain.
Existe sur le ledger XRPL. Un token (IOU, MPT, NFT) qui pointe vers le bien.
Pas de pont. Le token est l'actif. Pas de dualité.
Deux objets, un pont juridique solide. Le standard du tokenisé sérieux.
Le token prétend représenter ce qui n'existe pas (ou plus). Scam classique.
Rappel : ces trois concepts s'appliquent à la représentation numérique (l'objet manipulé sur XRPL — la property au sens "ce qui est possédé"), pas au bien réel sous-jacent.
Le titre juridique sur l'actif. Reconnu par un tribunal, opposable aux tiers, transmissible par héritage.
« Cet actif m'appartient au regard de la loi. »
La responsabilité formalisée de garder et protéger l'actif pour le compte d'autrui. Un rôle, pas un fait.
« Je suis en charge de protéger cet actif. »
Le contrôle matériel. Sur XRPL : qui détient les clés privées à l'instant T. Aucune dimension juridique.
« Je peux bouger cet actif, là, maintenant. »
| Configuration | Ownership | Custody | Possession |
|---|---|---|---|
|
Trésorerie startup en self-custody
Stablecoins payés par clients B2B
|
La société | La société | CEO + CFO (multisig) |
|
Programme de fidélité tokenisé
Points clients émis par un retailer
|
Le client | L'app de la marque | L'app de la marque |
|
Facture tokenisée (affacturage)
MPT représentant une créance B2B
|
L'investisseur-acheteur | Plateforme régulée (PSAN) | Plateforme régulée |
|
SaaS facturé en stablecoin XRPL
Encaissement client international
|
L'éditeur SaaS | PSP crypto (ou wallet ops) | PSP crypto |
|
Part de fonds tokenisée
Money market fund on-chain
|
L'investisseur | Custodian régulé | Custodian régulé |
|
Compromission d'une clé ops
Phishing d'un dirigeant signataire
|
La société (juridiquement) | — compromise — | L'attaquant |
Un investisseur achète une part de fonds tokenisée. Le custodian régulé reçoit le MPT sur XRPL, le KYC est validé, le titre juridique est enregistré au nom de l'investisseur.
Un token immobilier est volé. Sur le ledger XRPL, le hacker a la possession et peut le revendre. La loi reconnaît toujours le propriétaire d'origine. Conflit : la blockchain dit A, le tribunal dit B.
XRPL fournit des fonctionnalités natives — pas des smart contracts à coder, mais des primitives intégrées au protocole — qui permettent à un émetteur régulé de maintenir l'alignement entre possession on-chain et ownership juridique. Voici les six leviers à connaître.
Le détenteur doit explicitement accepter chaque type de token. L'émetteur connaît tous ses porteurs.
Attestations on-chain (KYC, accréditation, majorité) émises par une autorité. Vérifiables sans révéler la donnée brute.
Espaces de circulation restreints aux porteurs de credentials valides. Indispensable pour les RWA conformes.
L'émetteur peut geler un token sur un compte (décision de justice, sanctions, suspicion de fraude). Le token reste, mais ne bouge plus.
L'émetteur peut récupérer un token émis (correction d'erreur, vol, décision de justice). Le ledger rattrape la loi.
Tokens structurés avec métadonnées et règles intégrées (transférabilité, plafonds, conditions). La conformité dans le token lui-même.
Les trois couches ne pèsent pas le même poids juridique. Custody est la plus régulée. Ownership hérite du droit classique. Possession n'a pas de statut direct, mais déclenche des obligations par ricochet. Ce panorama est indicatif (juridiction UE dominante) — toujours valider avec un avocat sur ton cas précis.
La qualification juridique de ton token détermine la pile d'obligations qui s'empile au-dessus. Cet arbre est une première grille de tri (cadre UE/MiCA dominant) — la qualification définitive nécessite un avis juridique formel.
Pour chaque token que tu manipules dans ton produit : qui en est propriétaire, qui en a la garde, qui en a la possession technique ? Et quelle qualification juridique s'applique à ce token ?
Si tu ne peux pas répondre clairement aux quatre questions, tu n'es pas prêt à lancer.
Une grille simple, qui évite des problèmes complexes.
Tout le travail de conception d'un produit XRPL consiste à rapprocher la possession on-chain de l'ownership juridique. KYC, custodians régulés, freeze, clawback, credentials existent précisément pour ça. La qualification juridique du token détermine la pile d'obligations qui s'empile par-dessus la techno.
"Not your keys, not your coins" est vrai. Mais incomplet.
Chaque primitive (trustline, credential, freeze, clawback, MPT, permissioned domain) est un outil pour maintenir la cohérence entre les trois couches. Et chaque qualification (security, EMT, ART, utility, other) déclenche une pile d'obligations distincte. Ton architecture produit doit expliciter, pour chaque flux, quelle primitive garantit quel alignement, et sous quel régime juridique.
Si tu ne sais pas où se trouvent ownership, custody et possession dans ton produit, et sous quel régime il opère, tu ne sais pas ce que tu vends.
Before discussing property or custody, a more fundamental distinction must be established: the asset and its digital representation are not the same thing. All XRPL pedagogy rests on this.
A token on XRPL is not the asset. It is a representation of the asset. These two objects are distinct, connected by a legal or contractual bridge. Understanding this duality is understanding all of XRPL.
Exists in the physical or legal world, independent of any blockchain.
Exists on the XRPL ledger. A token (IOU, MPT, NFT) that points to the asset.
No bridge. The token is the asset. No duality.
Two objects, a solid legal bridge. The standard for serious tokenization.
The token claims to represent something that does not (or no longer) exists. Classic scam.
Reminder: these three concepts apply to the digital representation (the object handled on XRPL — the property in the sense of "what is owned"), not to the underlying real asset.
The legal title to the asset. Recognized by a court, enforceable against third parties, transferable by inheritance.
"This asset belongs to me under the law."
The formalized responsibility of keeping and protecting the asset on behalf of another. A role, not a fact.
"I am responsible for protecting this asset."
Material control. On XRPL: who holds the private keys at time T. No legal dimension.
"I can move this asset, right now."
| Configuration | Ownership | Custody | Possession |
|---|---|---|---|
|
Startup treasury in self-custody
Stablecoins paid by B2B clients
|
The company | The company | CEO + CFO (multisig) |
|
Tokenized loyalty program
Customer points issued by a retailer
|
The customer | The brand's app | The brand's app |
|
Tokenized invoice (factoring)
MPT representing a B2B receivable
|
The investor-buyer | Regulated platform (CASP / MSB) | Regulated platform |
|
SaaS billed in XRPL stablecoin
International customer collection
|
The SaaS vendor | Crypto PSP (or ops wallet) | Crypto PSP |
|
Tokenized fund share
On-chain money market fund
|
The investor | Regulated custodian | Regulated custodian |
|
Operational key compromise
Phishing of a signatory executive
|
The company (juridiquement) | — compromised — | The attacker |
An investor buys a tokenized fund share. The regulated custodian receives the MPT on XRPL, KYC is validated, the legal title is registered in the investor's name.
A real-estate token is stolen. On the XRPL ledger, the hacker has possession and can resell it. The law still recognizes the original owner. Conflict: the blockchain says A, the court says B.
XRPL provides native features — not smart contracts to code, but primitives built into the protocol — that allow a regulated issuer to maintain alignment between on-chain possession and legal ownership. Here are the six levers to know.
The holder must explicitly accept each token type. The issuer knows all its holders.
On-chain attestations (KYC, accreditation, age) issued by an authority. Verifiable without revealing the raw data.
Circulation spaces restricted to holders of valid credentials. Essential for compliant RWAs.
The issuer can freeze a token on an account (court order, sanctions, fraud suspicion). The token stays but can no longer move.
The issuer can claw back an issued token (error correction, theft, court order). The ledger catches up with the law.
Structured tokens with metadata and built-in rules (transferability, caps, conditions). Compliance in the token itself.
The three layers do not carry the same legal weight. Custody is the most regulated. Ownership inherits from classic law. Possession has no direct status but triggers obligations indirectly. This overview spans both EU (MiCA) and US (BitLicense, FinCEN, state trust charters) frameworks — always validate with a lawyer for your specific jurisdiction.
The legal qualification of your token determines the stack of obligations that piles on top. This tree is a first sorting grid (EU/MiCA framework dominant) — definitive qualification requires formal legal advice.
For every token you handle in your product: who is the owner, who has custody, who has technical possession? And what legal qualification applies to that token?
If you cannot clearly answer all four questions, you are not ready to launch.
A simple grid that avoids complex problems.
All the design work of an XRPL product consists of bringing closer on-chain possession and legal ownership. KYC, regulated custodians, freeze, clawback, credentials exist precisely for this. The legal qualification of the token determines the stack of obligations that piles on top of the tech.
"Not your keys, not your coins" is true. But incomplete.
Each primitive (trustline, credential, freeze, clawback, MPT, permissioned domain) is a tool to maintain consistency across the three layers. And each qualification (security, EMT, ART, utility, other) triggers a distinct stack of obligations. Your product architecture must specify, for each flow, which primitive guarantees which alignment, and under which legal regime.
If you don't know where ownership, custody and possession sit in your product, and under which regime it operates, you don't know what you're selling.