Einen RPL-Token bereitstellen

Diese Seite führt einen Token von null zu einem aktiven, übertragbaren Asset auf Rand. RPL ist Rands Token-Standard, neu auf Chain 14. Wenn Sie einen ERC-20 deployt oder einen SPL-Mint erstellt haben, sollten Sie den ersten Abschnitt langsam lesen, denn ein RPL-Token ist keines von beiden. RPL-Token ist die Konzeptseite hinter dieser Seite.

1. Was ein RPL-Token ist

Ein RPL-Token ist ein Eintrag im Token-Register des Ledgers, kein Smart Contract. Es gibt keinen Code zu schreiben, zu kompilieren oder zu auditieren. Einen Token zu erstellen ist eine einzige Transaktion, die dem Register eine Zeile hinzufügt. Von da an sind die Einheiten des Tokens gewöhnliche abgeschirmte Notes, die im selben Pool wie RAND gehalten und auf dieselbe Weise ausgegeben werden.

Symbole sind nicht eindeutig. Jeder kann einen Token namens USDC erstellen, genau wie auf Ethereum und Solana. Die Identität eines Tokens ist seine Asset-ID. Prüfen Sie daher die rpl1…-ID, bevor Sie einen Token annehmen oder listen, niemals das Symbol. Die Textform hat eine Prüfsumme: Eine falsch getippte ID wird abgelehnt und nicht an eine andere Stelle gesendet.

Wie er sich von ERC-20 und SPL unterscheidet

Öffentlich bleibt die Grenze: die Registrierung eines Tokens, jeder Mint und jeder Burn, jeweils mit seinem Betrag. Dadurch ist die Gesamtmenge für jeden überprüfbar. Überweisungen zwischen Inhabern verraten nichts, auch nicht, welcher Token bewegt wurde.

2. Bevor Sie beginnen

rand --key wallet.key.json keygen     # writes the spend key; refuses to overwrite
rand --key wallet.key.json address    # your rand1… address
rand --key wallet.key.json faucet     # testnet only, allowlisted wallets only: asks a validator node to mint 100 RAND to this wallet
rand --key wallet.key.json balance    # scans the tree, prints the spendable value and the unspent note count

--key ist standardmäßig wallet.key.json und kann einmalig als RAND_KEY gesetzt werden; --rpc (oder RAND_RPC) benennt den Node, mit dem gesprochen wird, und ist standardmäßig http://127.0.0.1:8545. Die folgenden Befehle schreiben --key ausdrücklich aus. Bevor Sie einen Beweis aufwenden, prüfen Sie, ob der Node auf Chain 20 ist: Die JSON-RPC-Methode rand_chainId gibt dort 20 zurück. Die Wallet muss ein Chain-20-Build sein, v0.6.8: Chain 20 bindet jeden Beweis und jede signierte Nachricht, auch die eines Token-Mints, an ihren Genesis-Hash, sodass ein rand v0.6.7 Beweise und Signaturen erzeugt, die Chain 20 ablehnt.

3. Den Token erstellen

token create nimmt seine Beträge in der kleinsten Einheit des Tokens. --fixed-supply und --initial sind ganze Zahlen in Basiseinheiten: Bei --decimals 2 entspricht ein Betrag von 1000000 10,000.00 Token. Jeder spätere Befehl (rand send --asset, rand token mint, rand token burn) nimmt seit v0.5.10 die Anzeigeeinheiten des Tokens, so wie RAND-Beträge in RAND angegeben werden (1.5): Die Wallet liest decimals aus der Registerzeile des Tokens, und mehr Nachkommastellen, als der Token hat, werden abgelehnt. On-chain ist ein Betrag stets die Ganzzahl in Basiseinheiten.

Entscheiden Sie zuerst eines: Dürfen jemals weitere Einheiten ausgegeben werden? Die Antwort wird bei der Erstellung im Token festgelegt und kann später nicht erweitert werden.

Ein Token mit fester Gesamtmenge

rand --key wallet.key.json token create \
  --name "Example Credits" \
  --symbol EXC \
  --decimals 2 \
  --fixed-supply 1000000 \
  --to rand1…

--to ist die vollständige rand1…-Adresse, die die Gesamtmenge erhält, zum Beispiel die Ausgabe von rand address. --fixed-supply ist in Basiseinheiten: 1000000 bei 2 Dezimalstellen sind 10,000.00 EXC.

Der Befehl liest den nächsten Index des Registers und die Registrierungsgebühr vom Node, baut die Note des anfänglichen Mints, beweist ein Gebühren-Bundle, reicht die Registrierung ein und wartet auf den Block. Bei Erfolg meldet er die Einreichung, gibt dann eine Zeile der Form index <N>, id <64 hex> (<rpl1…>) aus und danach committed at height <H>. Notieren Sie sich die rpl1…-ID: Sie ist die Identität des Tokens, und jeder spätere Befehl verlangt sie.

Die Standardgebühr ist die Basisgebühr plus die Registrierungsgebühr der Chain, auf Chain 20 also 1.001 RAND, es ist somit nichts zu berechnen; --fee (in RAND) erhöht sie. --no-wait kehrt zurück, sobald die Transaktion eingereicht ist, und überspringt die committed-Zeile. --cuda beweist auf einer angeschlossenen NVIDIA-GPU, braucht einen Build mit --features cuda und fällt nicht auf die CPU zurück.

Wird ein anderer Token registriert, während Ihrer bewiesen wird, nimmt er den Index, für den Ihrer versiegelt wurde. Der Node lehnt die Registrierung ab, und der Befehl gibt another token took index N first — re-run to register at N+1 mit den tatsächlichen Zahlen aus. Eine abgelehnte Registrierung erreicht nie einen Block; verloren geht das Beweisen, etwa 100 Sekunden Arbeit. Führen Sie den Befehl erneut aus, und er beweist gegen den nächsten Index.

Die gesamte Menge liegt nun in einer abgeschirmten Note, die der --to-Adresse gehört. Die Registrierung und ihr Betrag sind öffentlich; was der Empfänger danach mit der Note tut, ist es nicht.

Ein mintbarer Token

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json

Dadurch wird ein neuer Dilithium2-Schlüssel in exp-authority.key.json geschrieben (Modus 0600, eine bestehende Datei wird nicht überschrieben). Das Token wird mit diesem Schlüssel als Mint-Berechtigung und einem Angebot von null registriert. Die Ausgabe besteht aus denselben zwei Zeilen wie bei einem Token mit festem Angebot. Genau eine der Optionen --fixed-supply und --authority-key-out muss angegeben werden.

Um in derselben Transaktion eine erste Menge zu prägen, fügen Sie --initial und --to hinzu, die nur zusammen angegeben werden dürfen:

rand --key wallet.key.json token create \
  --name "Example Points" \
  --symbol EXP \
  --decimals 0 \
  --authority-key-out exp-authority.key.json \
  --initial 5000 \
  --to rand1…

Solange die Registrierung unterwegs ist, liegt der Schlüssel unter exp-authority.key.json.pending. Er wird zu exp-authority.key.json befördert, sobald die Chain die Registrierung akzeptiert, und verworfen, wenn die Chain sie ablehnt. Bricht die Verbindung bei unbekanntem Ausgang ab, bleibt die Datei unter .pending liegen: Prüfen Sie rand token list, bevor Sie sie löschen.

Die Schlüsseldatei ist die Macht, das Token zu drucken. Bewahren Sie sie offline und gesichert auf; sie ist vom Spend-Schlüssel Ihres Wallets getrennt und wird zum Senden oder Empfangen nie benötigt.

Warum der Empfänger der ersten Prägung Teil der ID ist

Eine Registrierung wird nicht von ihrem Urheber signiert. Jeder, der Ihre Registrierung im Mempool warten sieht, kann eine Kopie davon einreichen und mit seinem eigenen Gebührenbündel bezahlen. Würde die Asset-ID nur Name, Symbol und Menge abdecken, könnte diese Kopie die Adresse des Kopierenden als Empfänger nennen und vor Ihnen in einen Block gelangen: Er besäße die ID und bei einem Token mit festem Angebot für immer das gesamte Angebot.

Deshalb ist die ID ein Hash über alles in der Registrierung, einschließlich der ersten Prägung: ihre Menge, ihren Empfänger, ihre Zufallswerte, ihre Zeit und ihren verschlüsselten Umschlag. Eine Kopie mit einem anderen Empfänger ergibt eine andere Asset-ID. Es ist ein anderes Token, das zufällig Ihr Symbol teilt, und mehr hat ein nicht eindeutiges Symbol nie versprochen. Ihre ID kann nur mit Ihrem Empfänger registriert werden.

--salt <hex32> setzt den 32-Byte-Salt, der ebenfalls in die ID einfließt. Lassen Sie ihn weg, wählt das Wallet zufällig einen. Setzen Sie ihn, wenn die ID reproduzierbar sein muss, zum Beispiel um die ID zu veröffentlichen, bevor das Token existiert.

Bestätigen

rand token info rpl1…          # by id: rpl1… or 64 hex characters
rand token info 2              # or by the index `token create` printed
rand token list --limit 20     # one page of the registry; --from <index> pages on

token info gibt die Zeile des Tokens als JSON aus: index, id, id_text (die Form rpl1…), name, symbol, decimals, authority, mint_nonce, total_supply und registered_at. authority ist {"kind":"none"} bei einem Token mit festem Angebot und {"kind":"key","key":…,"address":…} bei einem prägbaren. total_supply ist eine Dezimalzeichenkette in Basiseinheiten. token list gibt enabled, registration_fee, next_index und die tokens-Zeilen aus. Beide lesen die gesamte Liste des Nodes, sodass der Node nicht erfährt, für welches Token Sie sich interessiert haben.

Oder über JSON-RPC, wobei der Parameter der Index, die 64-stellige Hex-ID oder die Form rpl1… sein kann:

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1,
  "method": "rand_getToken",
  "params": ["rpl1…"]
}'

Das Ergebnis ist dieselbe Zeile, die token info ausgibt, oder null, wenn kein solches Token existiert; eine fehlerhafte ID (falsche Prüfsumme, gemischte Groß- und Kleinschreibung, falsche Länge) ergibt den Fehler -32602. rand_getTokens nimmt [from_index, limit] und blättert durch alle registrierten Tokens, und rand_getTokenSupply gibt allein { total_supply, backings } zurück. Keine dieser Methoden benötigt einen Schlüssel. Siehe JSON-RPC.

Eine Zeile, die heute auf Chain 20 existiert, ist zUSD, das überbrückte Token an Index 1. Der Explorer stellt die Registry des Nodes ohne eigenen Node bereit:

curl -s https://randscan.org/api/v1/tokens

Auf Chain 14 lieferte das am 2026-09-20 "registration_fee": 1000000000, "next_index": 2 und ein Token, hier auf sein erstes Backing gekürzt:

{
  "index": 1,
  "id": "32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f",
  "id_text": "rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx",
  "name": "Shielded USD",
  "symbol": "zUSD",
  "decimals": 8,
  "authority": {
    "kind": "bridge",
    "backings": [
      { "chain": 2, "token": "000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7",
        "decimals": 6, "locked": "0", "minted_today": "0", "mint_day": 20716,
        "mint_cap_per_day": "10000000000000" }
    ]
  },
  "mint_nonce": 0,
  "total_supply": "0",
  "registered_at": 256
}

Auf Chain 20 hat die Zeile dieselben id, id_text, denselben Namen, dasselbe Symbol und dieselben Backings, aber zUSD ist im Genesis aufgeführt, statt bei Höhe 256 registriert zu werden (registered_at 0), und sein Angebot begann bei 99 zUSD: 22 gesperrt auf Ethereum USDT, 22 auf BSC USDT, 30 auf Tron USDT und 25 auf Solana USDT, übernommen von Chain 19. (Das von Chain 19 begann bei 10 zUSD, alle auf Solana; das von Chain 18 mit 9 auf Tron und 1 auf Solana.) Jede Backing-Zeile enthält außerdem die Felder des gleitenden Fensters minted_in_window, mint_window_secs und mint_headroom.

Die Kopie von registration_fee im Explorer ist eine JSON-Zahl; der eigene RPC des Nodes liefert sie, wie jeden Betrag, als Dezimalzeichenkette. Auf Chain 20 liefert rand_getTokens des Nodes, wie auf jeder Chain seit 15, zusätzlich max_tokens (4096), burn_registration_fee und bound_note_value (beide true) (RPL tokens).

4. Prägen und die Berechtigung übergeben

Nur ein Token mit einer Key-Berechtigung kann geprägt werden, und nur von diesem Schlüssel.

rand --key wallet.key.json token mint \
  --asset rpl1… \
  --to rand1… \
  --amount 5000 \
  --authority-key exp-authority.key.json

--amount steht in den Anzeigeeinheiten des Tokens: 5000 bei diesem Token ohne Dezimalstellen sind 5.000 Basiseinheiten, und 1.5 bei einem Token mit 6 Dezimalstellen wären 1.500.000. Bevor das Wallet eine Note oder einen Beweis erstellt, liest es die Zeile des Tokens und lehnt ab, wenn das Token nicht per Key autorisiert ist oder wenn --authority-key nicht der Schlüssel ist, den die Registry nennt. Bei Erfolg meldet es die Einreichung und gibt minted <amount> (<base units> units) of asset <index> to <address> aus. --fee (Standard 0.001 RAND), --no-wait und --cuda funktionieren wie bei token create.

Eine Prägung hängt eine Note für den Empfänger an und erhöht das Gesamtangebot. Die Menge und der öffentliche Schlüssel des Empfängers liegen offen auf der Leitung: Eine Prägung ist absichtlich ein öffentliches Ereignis, genau wie eine Einzahlung über die Bridge. Sobald der Empfänger die Note bewegt, ist sie wie alles andere abgeschirmt. Das Wallet, das die Gebühr zahlt (--key), und der Schlüssel, der die Prägung autorisiert (--authority-key), sind verschiedene Schlüssel und können von verschiedenen Personen gehalten werden.

Jede Prägung wird über die Chain-ID, die Asset-ID und einen von der Registry geführten Zähler signiert, auf Chain 20 zusätzlich über den Genesis-Hash (rand-rpl-mint-2), sodass eine Prägung auf dieser Chain nicht wiedergegeben und nicht auf eine andere übertragen werden kann, auch nicht auf eine, die dieselbe Chain-ID teilt. set-authority ist auf dieselbe Weise gebunden.

So übertragen Sie die Berechtigung auf einen neuen Schlüssel oder geben sie endgültig auf:

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --new-key next-authority.key.json

rand --key wallet.key.json token set-authority \
  --asset rpl1… \
  --authority-key exp-authority.key.json \
  --renounce

--new-key nimmt eine Schlüsseldatei und übergibt das Token an den öffentlichen Schlüssel dieser Datei; genau eine der Optionen --new-key und --renounce muss angegeben werden. Der Befehl gibt asset <index>'s mint authority is now <public key hex> oder asset <index>'s mint authority is renounced for good aus. Jeder Aufruf kostet die Basis von 0.001 RAND und eine Beweisrunde. --renounce macht das Token bei seinem aktuellen Angebot zu einem Token mit festem Angebot. Das ist unumkehrbar: Eine Berechtigung kann von Schlüssel zu Schlüssel oder von einem Schlüssel an niemanden übergehen, und sonst nichts. Ein Token, das mit festem Angebot erstellt wurde, kann nie prägbar werden.

5. Verwenden

Senden

rand --key wallet.key.json send rand1… 250 --asset rpl1…

Das sendet 250 des Tokens in Anzeigeeinheiten: 250 EXP bei 0 Dezimalstellen oder 250.00 EXC (25.000 Basiseinheiten) bei 2. Empfänger und Menge sind positionsabhängig, wie bei RAND. Bevor etwas bewiesen wird, gibt das Wallet eine Zeile aus, to fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <symbol> (<base units> units), und fragt send? [y/N]. Prüfen Sie den Fingerabdruck gegen den des Empfängers und die Basiseinheiten gegen das, was Sie gemeint haben. --yes überspringt die Frage, und ein Skript muss es übergeben: Ohne diese Option wird ein stdin, das kein Terminal ist, abgelehnt. --asset nimmt den Index, die ID rpl1… oder die 64-stellige Hex-ID; lassen Sie es weg, wird RAND gesendet. --memo <text> versiegelt bis zu 510 Byte Text für den Empfänger im Umschlag der Zahlung, was Chain 18 als erste Chain erlaubt; nichts auf der Chain zeigt, dass ein Memo vorhanden ist. --fee ist immer in RAND und beträgt standardmäßig 0.001; --no-wait und --cuda gelten. Eine ID wird anhand der gesamten Registry-Liste des Nodes zu ihrem Index aufgelöst, und ein numerischer Index erreicht den Node gar nicht, sodass dem Node nicht mitgeteilt wird, welches Token gleich bewegt wird. Das ist dasselbe rand send, das RAND bewegt, und derselbe Beweis. Die Transaktion veröffentlicht vier Nullifier, vier Commitments, eine RAND-Gebühr, eine Zeit, vier verschlüsselte Umschläge, den Bündelbeweis und seit Chain 17 ein Autorisierungs-Commitment samt Beweis, gleich welches Asset bewegt wurde. Ein Beobachter kann eine Token-Überweisung nicht von einer RAND-Zahlung unterscheiden, nicht erkennen, welches Token es war, und sieht weder Sender noch Empfänger noch Menge.

Die Gebühr wird in RAND aus demselben Bündel bezahlt, das sendende Wallet muss also etwas RAND halten. Das Wallet prüft das, bevor es mit dem Beweisen beginnt.

Kontostand prüfen

rand --key wallet.key.json asset-balance 2     # one token, by index
rand --key wallet.key.json asset-balance       # a row for every token this wallet holds

Das Argument ist ein Registry-Index. Für ein Token gibt das Wallet asset <index> balance: <N> units aus, in Basiseinheiten. rand notes listet jede Note auf, die das Wallet geöffnet hat, mit ihrem asset-Index. Das Wallet findet seine Noten, indem es die Chain mit seinem Viewing-Schlüssel durchsucht. Nichts auf der Chain hält einen Kontostand bereit, den es nachschlagen könnte.

Verbrennen

rand --key wallet.key.json token burn rpl1… 100

Asset und Menge sind positionsabhängig: das Asset als Index, rpl1… oder Hex, die Menge in den Anzeigeeinheiten des Tokens, wie send --asset sie liest. --fee beträgt standardmäßig 0.001 RAND; --no-wait und --cuda gelten.

Ein Verbrennen vernichtet Einheiten und senkt das Gesamtangebot. Wie eine Prägung ist es eine öffentliche Grenze: Die Menge und das Token sind sichtbar, der Halter nicht. Ein überbrücktes Token wie zUSD wird nicht auf diese Weise verbrannt: token burn lehnt es vor dem Beweisen ab, und es verlässt die Chain über rand bridge-burn, das die dahinterliegende Münze freigibt.

6. Im Explorer prüfen

randscan.org zeigt die öffentliche Seite eines Tokens für alle: seine Registrierung, seine Mints und Burns sowie seine Gesamtmenge. Jeder Token ist unter randscan.org/tokens aufgeführt, und die Seite eines Tokens lautet /tokens/<rpl1…>, /tokens/<64 hex> oder /tokens/<index>; randscan.org/tokens/1 ist zUSD. Dieselben Daten liefern GET /api/v1/tokens und GET /api/v1/tokens/:id, letzteres mit der Deploy-Transaktion des Tokens und seinem Mengenverlauf aus Registrierung, Mints und Burns (Explorer API).

Die öffentliche Seite einer Überweisung zeigt keinen Asset, keinen Betrag und keine Beteiligten, weil die Chain sie nicht kennt. Um einer anderen Person eine Zahlung nachzuweisen, etwa einer Prüferin, einer Gegenpartei oder einer Börse, geben Sie ihr einen Schlüssel:

rand --key wallet.key.json tx-key <TX_HASH>    # the keys for one transaction
rand --key wallet.key.json viewing-key         # the wallet's viewing key, 64 hex characters

tx-key gibt eine Zeile pro Ausgabe dieser Transaktion aus, die dieses Wallet gesendet, empfangen oder als Wechselgeld behalten hat: die Ausgabe (bundle:0 bis bundle:3, die vier Slots des Bundles), die Rolle, den Betrag (in RAND oder N (asset I) bei einem Token) und den Schlüssel pro Transaktion, unter dem diese Ausgabe versiegelt wurde. Geben Sie den Schlüssel der Zeile sent weiter. Er funktioniert für jede zurückliegende Transaktion, weil das Wallet den Schlüssel aus der Chain wiederherstellt.

Fügen Sie einen Transaktionsschlüssel auf der Seite der Transaktion in randscan ein, um diese Ausgabe zu öffnen; der Explorer löst den Asset-Index gegen das Register auf und zeigt den Token mit seinem Namen und angewandten Dezimalstellen. Ein Viewing-Key gehört auf randscan.org/viewing. Der Explorer hält keinen Schlüssel und entschlüsselt auf seinem Server nichts. Über JSON-RPC ist dieselbe Offenlegung rand_checkTransaction(hash, key). Keiner der beiden Schlüssel kann etwas ausgeben. Ein Viewing-Key lässt sich nach der Weitergabe nicht zurücknehmen; nehmen Sie daher einen Transaktionsschlüssel, wenn nur eine Zahlung nachzuweisen ist.

7. Bridged Tokens

zUSD („Shielded USD”) ist ebenfalls ein RPL-Token, mit einer Bridge-Autorität: Seine Einheiten werden nur geprägt, wenn Guardians eine Einzahlung von USDT oder USDC auf Ethereum, Binance Smart Chain, Tron oder Solana bestätigen, und seine Menge entspricht stets dem, was dort gesperrt ist. Er wurde auf Chain 14 per Transaktion bei Höhe 256 registriert, bei Index 1, mit sieben Backings, und das Genesis jeder seither folgenden Chain, Chain 20 eingeschlossen, führt ihn unter derselben ID erneut auf: rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. Chain 15 übernahm die 10 zUSD, die beim Stopp von Chain 14 noch ausstanden, die Chains 16 bis 19 starteten mit denselben 10 zUSD, und Chain 20 startete mit den 99 zUSD, die auf Chain 19 ausstanden. Auf Chain 20 nimmt die Bridge 10 bps auf jede Einzahlung und jede Rücknahme, in zUSD, an eine Treasury-Note (Bridge). zUSD ist ein Korb: Seine Backings werden zum Nennwert gepoolt, sodass ein Inhaber das Risiko jeder aufgeführten Münze trägt, nicht nur der von ihm eingezahlten (RPL tokens). Seine Menge bewegt sich mit jeder Einzahlung und Rücknahme; rand token info 1 oder /tokens/1 im Explorer nennt den aktuellen Wert.

Sein Verlauf auf Chain 14, einem früheren Testnet (im Explorer geprüft am 2026-09-20). Diese Tabelle ist die Historie von Chain 14: Chain 14 ist eingestellt, daher stehen diese Transaktionen nicht im Explorer von Chain 20:

Die Seite der Überweisung zeigte, was jede Token-Überweisung zeigt: vier Nullifier, vier Commitments und eine Gebühr, und nichts, was darauf hindeutet, dass zUSD bewegt wurde.

Um zu zeigen, was ein Schlüssel offenlegt, veröffentlichten die Release Notes der Fullnode v0.5 zwei Schlüssel für diese Überweisung auf Chain 14, aus einem eigens dafür angelegten Demo-Wallet, das sonst nichts enthält:

Auf Chain 14 öffnete der Transaktionsschlüssel diese Ausgabe auf der Seite der Überweisung, und über JSON-RPC genügte ein Aufruf (geprüft am 2026-09-20). Der Aufruf hat auf Chain 20 für eine eigene Transaktion dieselbe Form; mit diesen Werten von Chain 14 antwortet ein Node von Chain 20 mit null (geprüft am 2026-10-01), da er diese Transaktion nie gehalten hat:

curl -s https://rpc.randprotocol.org -H 'content-type: application/json' -d '{
  "jsonrpc": "2.0", "id": 1, "method": "rand_checkTransaction",
  "params": ["e6ddaca3c852e6c861524a55d00a0fbdcaff6867544b9f19b9bf60ce263c32ed",
             "7f68f57c4f33a3f0fe419f4d1a5df2875461339dbc454af8ced50cbd7f40e4ef"] }'

Veröffentlichen Sie niemals den Viewing-Key eines Wallets, das Sie verwenden: Er zeigt dessen gesamte Historie, für immer.

Eine gewöhnliche Adresse kann keinen Bridged Token erzeugen. rand token create weist eine Bridge-Autorität zurück, und die Registrierung eines Bridged Tokens oder das Hinzufügen einer Münze zu einem bestehenden erfordert ein signiertes Quorum des postquantensicheren Guardian-Sets der Bridge. Ein Token, der sich ohne dies zUSD nennt, ist nur ein weiterer Token mit geliehenem Symbol, ein Grund mehr, die rpl1…-ID zu prüfen. Bridged Tokens haben auf Rand stets 8 Dezimalstellen.

Bridge behandelt Einzahlungen, Rücknahmen und das Guardian-Set.