Rand Protocol

Sans permission · Confidentiel · Post-quantique

Des règlements confidentiels pour les stablecoins USD de Binance Smart ChainSolanaTronEthereumBinance Smart ChainSolana, Tron, Ethereum, Binance Smart Chain

Transférez des USDT ou des USDC depuis Solana, Tron, Ethereum ou Binance Smart Chain vers Rand, où ils deviennent des zUSD : des dollars numériques que seuls l'expéditeur et le destinataire peuvent voir. Encaissez vers l'une des quatre chaînes, dollar pour dollar moins 0,1 % à l'entrée et 0,1 % à la sortie, prélevés en zUSD sur Rand, de sorte que même les frais restent confidentiels. Conçu pour rester confidentiel face aux ordinateurs quantiques.

Confidentiel pour le marché, ouvert à votre auditeur
De À USDT Frais
Acme Treasury Shenzhen Parts Co. Facture fournisseur 184,200.00 0.001
Acme Treasury M. Okafor Salaire, septembre 9,450.00 0.001
Acme Treasury L. Tanaka Salaire, septembre 12,800.00 0.001
Acme Treasury Northgate OTC desk Transaction de bloc 2,500,000.00 0.001

Quiconque dispose d'un explorateur de blocs peut lire ceci : vos fournisseurs, vos salaires, le volume de vos transactions.

Rand est confidentiel comme un compte bancaire, conçu pour une économie moderne qui fonctionne avec des stablecoins. Le réseau n'enregistre qu'une preuve que chaque paiement est équilibré, ainsi que ses frais. Vous conservez la clé de consultation (viewing key) : votre auditeur ou votre régulateur peut donc toujours consulter vos écritures. Les noms et les montants sont donnés à titre d'illustration.

Cas d'usage

Là où la confidentialité est une exigence métier

Les blockchains publiques publient tout : chaque ordre est un signal et chaque position une divulgation, et les institutions qui détiennent le plus de capital ont refusé ce compromis.

Les 53 cas d'usage, par secteur
Performances

Mesurées sur le réseau en production

Chaque chiffre ci-dessous provient du nœud en fonctionnement, et non d'une projection : le nœud complet sur les chaînes testnet 13 à 15, avec une preuve générée sur un ordinateur portable ordinaire au profil de production. Comment ils ont été mesurés →

Système de preuve
STARK
FRI sur Goldilocks · sans trusted setup · jeu de contraintes 8 depuis la chaîne 18
Vérification
~32 ms
preuve de transfert, clé chaude, un cœur d'ordinateur portable · pas encore mesurée sur les hôtes de validateurs
Preuve
~40 s
un transfert de n'importe quel actif sur un ordinateur portable, sur tous ses cœurs · une preuve d'autorisation de 2 à 6 s et une preuve de lot de 32 à 45 s, mesurées sur la chaîne 20
Chaînes
4
ETH · BSC · TRON · SOL
Temps de bloc
1,2 s
mesuré sur la chaîne 15, et de nouveau environ 1,2 s sur la chaîne 20 (l'explorateur, 2026-10-01) · HotStuff BFT chaîné
Validateurs
26
sur la chaîne 21 du testnet, exploitée par l'équipe · un quorum est de 18
Appel privé
6–31 s
pour prouver un programme sur un ordinateur portable · 6 à 9 s au palier 12, 24 à 31 s au palier 14, mesurés sur la chaîne 20
Programmes
RISC-V
programmes invités jusqu'au palier 14 · EVM/SVM traduits, démontrés sur la chaîne 13 retirée, non appelables actuellement

Combien de temps prend un transfert de zUSD ou de RPL

Environ 45 secondes entre rand send et la finalité, dont presque tout est consacré à la preuve, générée sur la machine de l'expéditeur. La preuve est la même pour RAND, zUSD et chaque jeton RPL : aucun actif n'est donc plus rapide ou plus lent qu'un autre, et aucun ne peut être distingué par son délai. Un retrait de zUSD, l'enregistrement d'un jeton RPL et son émission comportent chacun une seule preuve et prennent le même temps. Un dépôt de zUSD attend en outre les confirmations de la chaîne source et les signatures des gardiens, qui dépendent de cette chaîne.

  1. 1. Preuve
    ~40 s
    sur l'ordinateur portable de l'expéditeur, tous les cœurs · lot de 32 à 45 s et autorisation de 2 à 6 s mesurés sur la chaîne 20, ou sur un prover que l'expéditeur associe
  2. 2. Vérification
    ~32 ms
    à l'admission, hors de la boucle de consensus · clé chaude, un cœur d'ordinateur portable
  3. 3. Inclusion
    ~1,2 s
    le bloc suivant, à l'intervalle moyen mesuré
  4. 4. Finalité
    ~3,6 s
    trois blocs de plus sous l'engagement à trois chaînes ; aucune réorganisation ensuite

La preuve est locale par conception : la clé de dépense ne quitte jamais le portefeuille. Coût de la preuve · fonctionnement de la preuve

Réserves et zUSD en circulation

Stablecoins verrouillés
—
chaque stablecoin accepté, sur les quatre chaînes
USDT verrouillés
—
Tether USD
USDC verrouillés
—
USD Coin
Offre de zUSD
—
le total du registre de jetons, à parité un pour un avec ce qui est verrouillé

Lecture du bridge depuis l'explorateur… Comment fonctionne la réserve →

Vue d'ensemble

Qu'est-ce que Rand ?

Rand est un réseau de paiement confidentiel pour les stablecoins en dollars. Déposez des USDT ou des USDC depuis Solana, Tron, Ethereum ou Binance Smart Chain et recevez le même montant, moins des frais de pont de 0,1 %, sous forme de zUSD, un dollar numérique que seuls vous et votre contrepartie pouvez voir. Retirez à tout moment, vers l'une des quatre chaînes, moins les mêmes frais.

Les blockchains publiques publient chaque solde et chaque paiement, c'est pourquoi les entreprises n'y placent ni la paie, ni les conditions fournisseurs, ni leurs opérations de marché. Le registre de Rand ne contient ni comptes ni soldes : il n'y a donc rien à lire pour un concurrent. La même confidentialité s'étend à des programmes entiers, et pas seulement aux paiements : la logique métier reste donc confidentielle elle aussi.

Chaque zUSD est adossé à de vrais USDT ou USDC détenus sur la chaîne d'origine, dans des réserves que chacun peut vérifier à tout moment. Il n'y a pas de nouvel émetteur auquel se fier. Il y a une dépendance, que nous énonçons clairement : un groupe indépendant de gardiens confirme les dépôts et les retraits sur chaque chaîne, et les papiers exposent ce que ce groupe peut et ne peut pas faire.

Réserve

Une réserve alimentée par chaque chaîne où le dollar circule déjà

Les USDT et USDC circulent nativement sur de nombreuses chaînes, et exiger qu'ils soient émis à nouveau partout où Rand en a besoin ferait dépendre la capacité de réserve d'une décision de déploiement qui ne nous appartient pas. À la place, chaque pièce est verrouillée dans un contrat de garde sur sa chaîne d'origine et attestée par un ensemble de gardiens à seuil t-sur-n, dont plus des deux tiers signent ; Rand frappe des zUSD contre l'agrégat, sous forme de note que la chaîne calcule à partir du montant attesté. La sortie suit le même chemin en sens inverse, et la branche d'entrée ne lie pas la branche de sortie : des USDT verrouillés sur Tron peuvent ressortir en USDT sur Ethereum, à condition que cette branche détienne des réserves pour les couvrir.

  1. 1
    Verrouillage

    Les USDT ou USDC sont déposés dans le contrat de garde sur Solana, Tron, Ethereum ou Binance Smart Chain et y sont immobilisés.

  2. 2
    Frappe

    Les gardiens attestent le verrouillage au seuil t ; n'importe qui soumet l'attestation, et Rand ajoute une note de dépôt pour le destinataire.

  3. 3
    Transfert

    Les zUSD circulent dans le pool shielded sous forme de notes, dissimulant l'expéditeur, le destinataire et le montant.

  4. 4
    Remboursement

    Une destruction (burn) dépense les notes et émet un message ; les gardiens l'attestent et la custodie libère des USDT ou des USDC sur la jambe que désigne le détenteur, pour le montant diminué de 0,1 % de frais.

Chaîne Acceptés Standard Custodie Hypothèse de confiance
Ethereum USDT · USDC ERC-20 Contrat de verrouillage Correction du programme ∧ seuil de gardiens
Binance Smart Chain USDT · USDC BEP-20 Contrat de verrouillage Correction du programme ∧ seuil de gardiens
Tron USDT TRC-20 Contrat de verrouillage Correction du programme ∧ seuil de gardiens
Solana USDT · USDC SPL Programme de custodie Correction du programme ∧ seuil de gardiens
Invariant de réserve

L'offre totale de zUSD ne dépasse jamais la somme des réserves détenues sur l'ensemble des jambes.

S ≤ Σc ∈ C Rc

Le document sur le stablecoin démontre que l'invariant est préservé à chaque transition d'état, chaque Rc étant un solde publiquement lisible sur sa propre chaîne. La garantie est conditionnelle : elle tient tant que moins de t gardiens sont compromis, car l'attestation est la preuve qu'un verrouillage a eu lieu sur cette jambe. Le blindage (shielding) masque la répartition de l'offre, non sa quantité ; le total reste donc auditable. Mais sur ces jambes, il procure une détection plutôt qu'une prévention, et les soldes ne sont pas observables conjointement entre chaînes à un instant donné.

Ce que cela coûte

Si la réserve et le jeton résident sur des chaînes différentes, la garantie effective est min(solvabilité de la réserve, intégrité du pont) plutôt que la seule solvabilité de la réserve.

C'était à l'origine l'argument contre un pont, et il n'est pas retiré. Verrouiller des réserves sur d'autres chaînes admet délibérément le terme d'intégrité du pont, en échange d'une capacité de réserve qu'aucune décision d'émission isolée ne peut contraindre. Le seuil de gardiens est par conséquent porteur : la compromission de t gardiens permet de créer des unités sans verrouillage correspondant, et l'exposition qui en résulte est bornée par la custodie propre à chaque chaîne.

Rand réglant les transactions sur sa propre chaîne, aucune jambe n'est colocalisée avec l'émission et chaque jambe porte ce terme. Le zUSD est fongible d'une jambe à l'autre : un détenteur ne peut donc choisir de ne détenir que la part d'une seule jambe, car une unité est une créance sur l'ensemble. Il mutualise aussi deux émetteurs : quelle que soit la pièce déposée, un zUSD porte à la fois le risque de Tether et celui de Circle. Éviter tout cela revient à détenir la pièce là où elle se trouve déjà et à renoncer au blindage, ce qui constitue un coût réel que nous ne pouvons pas supprimer par la conception.

Post-quantique

Cryptographie sur réseaux euclidiens normalisée

ML-DSA (Dilithium) pour les signatures des validateurs et ML-KEM (Kyber) pour le chiffrement des notes, tous deux normalisés par le NIST. Des engagements Poseidon2, choisis plutôt que Pedersen parce que la propriété de dissimulation de Pedersen est computationnelle et se réduit à une hypothèse de logarithme discret que l'algorithme de Shor résout en temps polynomial. Une STARK transparente pour la vérification, dont la solidité repose sur une fonction de hachage résistante aux collisions et qui ne requiert ni configuration de confiance (trusted setup) ni courbe à couplage.

La classification ci-dessous est celle qui fait foi : les propriétés irrévocables sont violées rétroactivement par un adversaire qui acquiert la capacité à un moment ultérieur quelconque, tandis que les propriétés renouvelables sont rétablies à chaque usage et peuvent être migrées avant l'arrivée de ce moment.

Lire la réconciliation post-quantique dans le document →
Signatures de consensus
ML-DSA · Dilithium2
Renouvelable · post-quantique
Confidentialité des notes
ML-KEM · Kyber768
Irrévocable · post-quantique
Dissimulation des engagements
Poseidon2
Irrévocable · post-quantique
Solidité des preuves
STARK · FRI
Renouvelable · post-quantique
Hachage
BLAKE3 · Poseidon2
Blocs et état · notes, arbre et preuves
Règlement
Rand · HotStuff BFT chaîné
Quorums pondérés par la mise, validation en trois chaînes

Le document énonce la sécurité quantique par primitive et par rôle — un hachage de transcription de 384 bits, des hachages de 256 bits résistants à la seule préimage, des signatures Dilithium2, un chiffrement des notes ML-KEM-768, la solidité de FRI sur un corps d'extension — sous les hypothèses Module-LWE, Module-SIS et SHA-3 / BLAKE3 modélisées comme des oracles aléatoires quantiques. Le hachage de transcription du nœud est aujourd'hui Poseidon2, un écart de configuration que recensent les docs développeur. L'énoncé par rôle remplace l'affirmation de 128 bits à l'échelle du protocole des versions antérieures, qui contredisait la borne quantique de collision de 85 bits d'un hachage de 256 bits et a été retirée plutôt que nuancée.

Commencez à construire sur Rand

Lisez les documents, exécutez un nœud, forkez le code source. Le protocole est ouvert, la cryptographie est publiée, et ses limites sont énoncées ouvertement.