Distribuire un token RPL

Questa pagina porta un token dal nulla a un asset attivo e trasferibile su Rand. RPL è lo standard di token di Rand, introdotto con la chain 14. Se hai già distribuito un ERC-20 o creato un mint SPL, la prima sezione è quella da leggere con calma, perché un token RPL non è né l’uno né l’altro. Token RPL è la pagina concettuale alla base di questa.

1. Che cos’è un token RPL

Un token RPL è una voce nel registro dei token del ledger, non uno smart contract. Non c’è codice da scrivere, compilare o sottoporre ad audit. Creare un token è una sola transazione che aggiunge una riga al registro e, da quel momento, le unità del token sono normali note schermate, custodite nello stesso pool di RAND e spese allo stesso modo.

I simboli non sono univoci. Chiunque può creare un token chiamato USDC, esattamente come su Ethereum e Solana. L’identità di un token è il suo asset id, quindi prima di accettare o listare un token controlla l’id rpl1…, mai il simbolo. La forma testuale ha un checksum: un id digitato in modo errato viene rifiutato, non inviato altrove.

Differenze rispetto a ERC-20 e SPL

Ciò che resta pubblico è il confine: la registrazione di un token, ogni mint e ogni burn, ciascuno con il proprio importo. È ciò che rende la total supply verificabile da chiunque. I trasferimenti tra titolari non rivelano nulla, nemmeno quale token si sia mosso.

2. Prima di iniziare

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 ha come valore predefinito wallet.key.json e può essere impostato una volta per tutte come RAND_KEY; --rpc (o RAND_RPC) indica il nodo con cui comunicare e ha come valore predefinito http://127.0.0.1:8545. I comandi seguenti esplicitano --key. Prima di spendere una prova, verifica che il nodo sia sulla chain 20: il metodo JSON-RPC rand_chainId vi restituisce 20. Il wallet deve essere una build della chain 20, v0.6.8: la chain 20 lega ogni prova e ogni messaggio firmato, compreso quello di un mint di token, al proprio genesis hash, quindi un rand v0.6.7 produce prove e firme che la chain 20 rifiuta.

3. Creare il token

token create accetta gli importi nell’unità più piccola del token. --fixed-supply e --initial sono numeri interi di unità base: con --decimals 2, un importo di 1000000 equivale a 10.000,00 token. Ogni comando successivo (rand send --asset, rand token mint, rand token burn) accetta dalla v0.5.10 le unità di visualizzazione del token, come gli importi in RAND sono espressi in RAND (1.5): il wallet legge decimals dalla riga del registro del token, e un numero di cifre frazionarie superiore a quello del token viene rifiutato. On chain un importo è sempre l’intero in unità base.

Decidi prima una cosa: si potranno mai emettere altre unità? La risposta è fissata nel token alla creazione e non può essere ampliata in seguito.

Un token a supply fissa

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

--to è l’indirizzo rand1… completo che riceve la supply, per esempio l’output di rand address. --fixed-supply è in unità base: 1000000 con 2 decimali sono 10.000,00 EXC.

Il comando legge dal nodo il prossimo index del registro e la commissione di registrazione, costruisce la nota del mint iniziale, prova un bundle di commissione, invia la registrazione e attende il blocco. In caso di successo riporta l’invio, poi stampa una riga della forma index <N>, id <64 hex> (<rpl1…>), quindi committed at height <H>. Annota l’id rpl1…: è l’identità del token, e ogni comando successivo lo richiede.

La commissione predefinita è la base più la commissione di registrazione della chain, 1,001 RAND sulla chain 20, quindi non c’è nulla da calcolare; --fee (in RAND) la aumenta. --no-wait restituisce il controllo non appena la transazione è inviata e omette la riga committed. --cuda prova su una GPU NVIDIA collegata, richiede una build con --features cuda e non ripiega sulla CPU.

Se mentre la tua prova è in corso viene registrato un altro token, questo prende l’index per cui era stata sigillata la tua. Il nodo rifiuta la registrazione e il comando stampa another token took index N first — re-run to register at N+1, con i numeri reali. Una registrazione rifiutata non raggiunge mai un blocco; ciò che si perde è la prova, circa 100 secondi di lavoro. Riesegui il comando e proverà rispetto all’index successivo.

L’intera supply si trova ora in un’unica nota schermata posseduta dall’indirizzo --to. La registrazione e il suo importo sono pubblici; ciò che il destinatario fa poi con la nota non lo è.

Un token mintable

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

Questo scrive una nuova chiave Dilithium2 in exp-authority.key.json (modalità 0600, con rifiuto di sovrascrivere un file esistente) e registra il token con quella chiave come autorità di mint e con un’offerta pari a zero. L’output è lo stesso di due righe di un token a offerta fissa. Va indicato esattamente uno tra --fixed-supply e --authority-key-out.

Per coniare un primo importo nella stessa transazione, aggiungi --initial e --to, che vanno indicati insieme:

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…

Mentre la registrazione è in corso, la chiave si trova in exp-authority.key.json.pending. Viene promossa a exp-authority.key.json quando la chain accetta la registrazione e scartata se la chain la rifiuta. Se la connessione cade con esito sconosciuto, il file resta in .pending: controlla rand token list prima di eliminarlo.

Il file della chiave è il potere di stampare il token. Tienilo offline e con un backup; è distinto dalla chiave di spesa del tuo wallet e non serve mai per inviare o ricevere.

Perché il destinatario del primo mint fa parte dell’id

Una registrazione non è firmata dal suo creatore. Chiunque veda la tua in attesa nella mempool può inviarne una copia, pagata con il proprio bundle di commissioni. Se l’id dell’asset coprisse solo nome, simbolo e importo, quella copia potrebbe indicare l’indirizzo del copiatore come destinatario e arrivare in un blocco per prima: costui possiederebbe l’id e, per un token a offerta fissa, l’intera offerta per sempre.

Per questo l’id è un hash di tutto ciò che compone la registrazione, mint iniziale incluso: il suo importo, il suo destinatario, la sua casualità, il suo tempo e la sua busta cifrata. Una copia con un destinatario diverso produce un id di asset diverso. È un token diverso che per caso condivide il tuo simbolo, e questo è tutto ciò che un simbolo non univoco ha mai promesso. Il tuo id può essere registrato soltanto con il tuo destinatario.

--salt <hex32> imposta il salt di 32 byte che concorre anch’esso all’id. Se lo ometti, il wallet ne sceglie uno a caso. Impostalo quando ti serve un id riproducibile, per esempio per pubblicare l’id prima che il token esista.

Verifica

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 stampa la riga del token come JSON: index, id, id_text (la forma rpl1…), name, symbol, decimals, authority, mint_nonce, total_supply e registered_at. authority è {"kind":"none"} per un token a offerta fissa e {"kind":"key","key":…,"address":…} per uno coniabile. total_supply è una stringa decimale in unità di base. token list stampa enabled, registration_fee, next_index e le righe tokens. Entrambi leggono l’intero elenco del nodo, quindi il nodo non sa a quale token eri interessato.

Oppure via JSON-RPC, dove il parametro può essere l’indice, l’id esadecimale di 64 caratteri o la forma rpl1…:

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

Il risultato è la stessa riga che stampa token info, oppure null se il token non esiste; un id malformato (checksum errato, maiuscole e minuscole miste, lunghezza sbagliata) produce l’errore -32602. rand_getTokens accetta [from_index, limit] e scorre a pagine tutti i token registrati, mentre rand_getTokenSupply restituisce soltanto { total_supply, backings }. Nessuno dei tre richiede una chiave. Vedi JSON-RPC.

Una riga che oggi esiste sulla chain 20 è zUSD, il token bridged all’indice 1. L’explorer serve il registro del nodo senza che tu debba avere un nodo tuo:

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

Sulla chain 14, il 2026-09-20, restituiva "registration_fee": 1000000000, "next_index": 2 e un solo token, qui abbreviato al suo primo backing:

{
  "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
}

Sulla chain 20 la riga ha gli stessi id, id_text, nome, simbolo e backing, ma zUSD è elencato nel genesis anziché registrato all’altezza 256 (registered_at 0), e la sua offerta è partita da 99 zUSD: 22 bloccati su Ethereum USDT, 22 su BSC USDT, 30 su Tron USDT e 25 su Solana USDT, riportati dalla chain 19. (Quella della chain 19 era partita da 10 zUSD, tutti su Solana; quella della chain 18 da 9 su Tron e 1 su Solana.) Ogni riga di backing riporta inoltre i campi della finestra mobile minted_in_window, mint_window_secs e mint_headroom.

La copia di registration_fee dell’explorer è un numero JSON; l’RPC del nodo la restituisce, come ogni importo, come stringa decimale. Sulla chain 20, come su ogni chain dalla 15, anche rand_getTokens del nodo riporta max_tokens (4096), burn_registration_fee e bound_note_value (entrambi true) (token RPL).

4. Coniare e cedere l’autorità

Solo un token con un’autorità Key può essere coniato, e solo da quella chiave.

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

--amount è espresso nelle unità di visualizzazione del token: 5000 di questo token a 0 decimali equivale a 5.000 unità di base, e 1.5 di un token a 6 decimali equivarrebbe a 1.500.000. Prima di costruire una nota o una prova, il wallet legge la riga del token e rifiuta se il token non è autorizzato con Key o se --authority-key non è la chiave indicata dal registro. In caso di successo segnala l’invio e stampa minted <amount> (<base units> units) of asset <index> to <address>. --fee (predefinita 0,001 RAND), --no-wait e --cuda funzionano come per token create.

Un mint aggiunge una nota per il destinatario e aumenta l’offerta totale. L’importo e la chiave pubblica del destinatario viaggiano in chiaro: un mint è per progetto un evento pubblico, come un deposito attraverso il bridge. Quando il destinatario sposta la nota, questa diventa schermata come tutto il resto. Il wallet che paga la commissione (--key) e la chiave che autorizza il mint (--authority-key) sono chiavi diverse e possono essere detenute da persone diverse.

Ogni mint è firmato sull’id della chain, sull’id dell’asset e su un contatore tenuto dal registro, e sulla chain 20 anche sull’hash del genesis (rand-rpl-mint-2), così un mint non può essere riprodotto su questa chain né copiato su un’altra, nemmeno su una che condivida l’id della chain. set-authority è vincolato allo stesso modo.

Per spostare l’autorità su una nuova chiave, o per rinunciarvi definitivamente:

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 prende un file di chiave e cede il token alla chiave pubblica di quel file; va indicato esattamente uno tra --new-key e --renounce. Il comando stampa asset <index>'s mint authority is now <public key hex>, oppure asset <index>'s mint authority is renounced for good. Ciascuno costa la base di 0,001 RAND e un giro di proving. --renounce trasforma il token in un token a offerta fissa all’offerta attuale. È irreversibile: un’autorità può passare da chiave a chiave o da una chiave a nessuno, e nient’altro. Un token creato con offerta fissa non può mai diventare coniabile.

5. Usarlo

Inviare

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

Questo invia 250 unità del token nelle unità di visualizzazione: 250 EXP a 0 decimali, oppure 250,00 EXC (25.000 unità di base) a 2. Il destinatario e l’importo sono posizionali, come per RAND. Prima di generare qualsiasi prova, il wallet stampa una riga, to fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <symbol> (<base units> units), e chiede send? [y/N]. Confronta l’impronta con quella del destinatario e le unità di base con quanto intendevi. --yes salta la domanda, e uno script deve passarlo: senza, uno stdin che non è un terminale viene rifiutato. --asset accetta l’indice, l’id rpl1… o l’id esadecimale di 64 caratteri, e se lo ometti viene inviato RAND. --memo <text> sigilla fino a 510 byte di testo per il destinatario dentro la busta del pagamento, cosa che la chain 18 è la prima chain a consentire; nulla sulla chain mostra che un memo sia presente. --fee è sempre in RAND e ha come predefinito 0,001; --no-wait e --cuda si applicano. Un id viene risolto nel suo indice a partire dall’intero elenco del registro del nodo, e un indice numerico non raggiunge mai il nodo, quindi al nodo non viene detto quale token sta per muoversi. È lo stesso rand send che sposta RAND, e lo stesso proving. La transazione pubblica quattro nullifier, quattro commitment, una commissione in RAND, un tempo, quattro buste cifrate, la prova del bundle e, dalla chain 17, un commitment di autorizzazione e la sua prova, qualunque asset si sia mosso. Un osservatore non può distinguere un trasferimento di token da un pagamento in RAND, non può dire di quale token si tratti e non vede né mittente, né destinatario, né importo.

La commissione è pagata in RAND dallo stesso bundle, quindi il wallet che invia deve possedere un po’ di RAND. Il wallet lo verifica prima di iniziare il proving.

Controllare un saldo

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

L’argomento è un indice del registro. Per un token il wallet stampa asset <index> balance: <N> units, in unità di base. rand notes elenca ogni nota che il wallet ha aperto, con il suo indice asset. Il wallet trova le proprie note scansionando la chain con la sua viewing key. Sulla chain nulla contiene un saldo da consultare per suo conto.

Burn

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

L’asset e l’importo sono posizionali: l’asset come indice, rpl1… o esadecimale, l’importo nelle unità di visualizzazione del token, come lo legge send --asset. --fee ha come predefinito 0,001 RAND; --no-wait e --cuda si applicano.

Un burn distrugge unità e riduce l’offerta totale. Come un mint, è un confine pubblico: l’importo e il token sono visibili, il detentore no. Un token bridged come zUSD non si brucia in questo modo: token burn lo rifiuta prima del proving, e il token esce tramite rand bridge-burn, che rilascia la moneta che lo garantisce.

6. Verificarlo sull’explorer

randscan.org mostra a chiunque il lato pubblico di un token: la sua registrazione, i suoi mint e burn e la sua offerta totale. Ogni token è elencato su randscan.org/tokens, e la pagina di un singolo token è /tokens/<rpl1…>, /tokens/<64 hex> oppure /tokens/<index>; randscan.org/tokens/1 è zUSD. Gli stessi dati sono disponibili in GET /api/v1/tokens e GET /api/v1/tokens/:id; quest’ultimo include la transazione di deploy del token e la cronologia della sua offerta, fatta di registrazione, mint e burn (Explorer API).

La pagina pubblica di un trasferimento mostra nessun asset, nessun importo e nessuna parte coinvolta, perché la chain non li possiede. Per provare un pagamento a un terzo, come un revisore, una controparte o un exchange, gli si consegna una chiave:

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 stampa una riga per ogni output di quella transazione che questo wallet ha inviato, ricevuto o conservato come resto: l’output (da bundle:0 a bundle:3, i quattro slot del bundle), il ruolo, l’importo (in RAND, oppure N (asset I) per un token) e la chiave per-transazione con cui quell’output è stato sigillato. Si consegna la chiave della riga sent. Funziona per qualsiasi transazione passata, perché il wallet recupera la chiave dalla chain.

Si incolla una chiave di transazione nella pagina della transazione su randscan per aprire quell’output; l’explorer risolve l’indice dell’asset nel registro e mostra il token per nome, con i suoi decimali applicati. Una viewing key si inserisce su randscan.org/viewing. L’explorer non conserva alcuna chiave e non decifra nulla sul proprio server. Tramite JSON-RPC la stessa divulgazione è rand_checkTransaction(hash, key). Nessuna delle due chiavi può spendere alcunché. Una viewing key non può essere ritirata una volta condivisa, quindi è preferibile una chiave di transazione quando si deve provare un solo pagamento.

7. Token bridged

zUSD (“Shielded USD”) è anch’esso un token RPL, con un’autorità Bridge: le sue unità vengono coniate solo quando i guardiani attestano un deposito di USDT o USDC su Ethereum, Binance Smart Chain, Tron o Solana, e la sua offerta è sempre pari a quanto vi è bloccato. È stato registrato sulla chain 14 con una transazione all’altezza 256, all’indice 1, con sette backing, e il genesis di ogni chain successiva, chain 20 inclusa, lo elenca di nuovo con lo stesso id, rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx. La chain 15 ha riportato i 10 zUSD ancora in circolazione quando la chain 14 si è fermata, le chain da 16 a 19 sono partite con gli stessi 10 zUSD, e la chain 20 è partita con i 99 zUSD in circolazione sulla chain 19. Sulla chain 20 il bridge trattiene 10 bps di ogni deposito e di ogni riscatto, in zUSD, a favore di una nota di tesoreria (Bridge). zUSD è un paniere: i suoi backing sono messi in comune al valore nominale, quindi chi lo detiene sopporta il rischio di ogni moneta elencata, non solo di quella che ha depositato (Token RPL). La sua offerta varia a ogni deposito e a ogni riscatto; rand token info 1 oppure /tokens/1 dell’explorer indica la cifra corrente.

La sua storia sulla chain 14, una testnet precedente (verificata sull’explorer il 2026-09-20). Questa tabella è la storia della chain 14: la chain 14 è ritirata, quindi queste transazioni non si trovano nell’explorer della chain 20:

La pagina del trasferimento mostrava ciò che mostra qualsiasi trasferimento di token: quattro nullifier, quattro commitment e una commissione, e nulla che indichi che zUSD si sia mosso.

Per mostrare che cosa rivela una chiave, le note di rilascio v0.5 del fullnode hanno pubblicato due chiavi per quel trasferimento della chain 14, ricavate da un wallet dimostrativo creato allo scopo, che non contiene nient’altro:

Sulla chain 14 la chiave di transazione apriva quell’output nella pagina del trasferimento, e tramite JSON-RPC bastava una sola chiamata (verificato il 2026-09-20). La chiamata ha la stessa forma sulla chain 20 per una transazione propria; con questi valori della chain 14 un nodo della chain 20 risponde null (verificato il 2026-10-01), perché non ha mai contenuto quella transazione:

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

Non pubblicare mai la viewing key di un wallet che usi: mostra l’intera cronologia di quel wallet, per sempre.

Un indirizzo ordinario non può creare un token bridged. rand token create rifiuta un’autorità Bridge, e registrare un token bridged, o aggiungere una moneta dietro uno già esistente, richiede un quorum firmato dell’insieme di guardiani post-quantistici del bridge. Un token che si dichiara zUSD senza questo è solo un altro token con un simbolo preso in prestito, ed è un motivo in più per verificare l’id rpl1…. I token bridged hanno sempre 8 decimali su Rand.

Bridge tratta depositi, riscatti e l’insieme di guardiani.