Paper
Il Rand Protocol è descritto in forma scritta. Sei documenti sono attuali: il paper del protocollo nella sua terza bozza, il paper dell'implementazione di riferimento, scritto sul nodo che la rete di test esegue, il rapporto sul bridge, il paper su zUSD, il dollaro shielded, l'analisi di sicurezza autonoma e il riepilogo per gli investitori. Ogni PDF è la fonte canonica: scaricalo, citalo, verificalo. Dove il progetto ha dei limiti, i paper li dichiarano anziché ometterli.
- WhitepaperSTARKProof of Stake · BFTEVMPost-quantistico
Rand Protocol
Calcoli arbitrari confidenziali
Bozza 3 · agosto 2026, aggiornata a settembre 2026 · 73 pagine
Presentiamo Rand, una blockchain proof-of-stake il cui consenso Byzantine Fault Tolerant (BFT) offre una finalità deterministica rapida e in cui ogni transazione è una prova a conoscenza zero. Il peso nel consenso deriva esclusivamente dallo stake vincolato: nessun calcolo conferisce potere di voto, sceglie un leader o decide un fork. Ciò che la chain contiene, invece, è una grande quantità di proving eseguito accanto al consenso: ogni wallet produce una STARK per la propria transazione e, una volta abilitata l'aggregazione delle prove a livello di blocco, gli aggregator vincolati guadagnano RAND dimostrando STARK ricorsive sulle prove degli utenti. I validator guadagnano le commissioni dei blocchi che propongono; la semantica degli smart contract è quella della Ethereum Virtual Machine (EVM). Il paper spiega lo schema a conoscenza zero in sé: come un calcolo diventa una tabella, la tabella un insieme di polinomi e i polinomi una prova di circa 1,4 MB per trasferimento che qualsiasi validator verifica in millisecondi. Rand è una chain generale per smart contract che non prevede alcun tipo di transazione trasparente: ogni calcolo, un trasferimento di token o una chiamata arbitraria a un contratto, viene eseguito in modo confidenziale per costruzione. Gli utenti detengono RAND shielded, pagano il gas con esso ed eseguono codice arbitrario i cui input, operandi e stato intermedio non compaiono mai on-chain, mentre i validator verificano una singola STARK che attesta la correttezza dell'esecuzione. L'EVM fornisce la semantica rispetto alla quale l'esecuzione viene dimostrata, come guest interprete all'interno del circuito, così che il bytecode Solidity esistente giri senza modifiche; non è un percorso di esecuzione trasparente accanto a quello shielded.
Questa revisione propone inoltre, come direzione di ricerca non implementata, la Verifiable Prover Attribution (VPA). La chain in esecuzione non la usa: i suoi wallet dimostrano le proprie transazioni, il leader è scelto in round robin, la mempool non è cifrata e il suo unico ruolo di proving vincolato è il registro degli aggregator, dove viene pagato il primo aggregato finalizzato che copre un bundle; la Parte II si apre con questo stato, e i suoi teoremi sono enunciati sulla proposta, non sul sistema distribuito. La bozza originale dimostrava che il circuito di una transazione privata era soddisfatto, ma non diceva nulla su come le prove vengano assegnate ai prover, con quale ordinamento un prover dimostri un batch, o come un verifier venga a sapere che l'entità che invia una prova è quella che l'ha calcolata nelle condizioni che il protocollo incentiva. Una STARK certifica che il circuito è stato soddisfatto; non certifica le condizioni in cui lo è stato. Mostriamo che questa lacuna apre tre superfici d'attacco concrete — collusione tra prover e validator, MEV lato prover e lavoro Sybil/non attribuibile — formalizziamo ciascuna e proponiamo di chiuderle con un beacon di assegnazione ricalcolabile, un ordinamento canonico con una mempool sigillata (cifrata a soglia) e un'attestazione post-quantistica che accompagna la prova. Riformuliamo di conseguenza l'affermazione della bozza secondo cui «le transazioni private eliminano il front-running» come teorema condizionale, le cui condizioni la chain in esecuzione non soddisfa: su quella chain il contenuto è nascosto, ma l'ordinamento non è protetto.
Riconciliamo inoltre tre incoerenze interne dell'analisi di sicurezza originale: (i) la contraddizione tra la solidità alle collisioni quantistiche di circa 85 bit (limite BHT) e l'affermazione di 128 bit post-quantistici dell'abstract e delle tabelle dei parametri, corretta nel design con un hash del transcript a 384 bit più un teorema esplicito di separazione della sicurezza per primitiva (l'implementazione usa ancora un hash del transcript a 256 bit, ≈85 bit quantistici); (ii) la VRF di selezione del leader non specificata, che è violabile con Shor se istanziata su una curva ellittica, per la quale specifichiamo un beacon post-quantistico commit–reveal con sortition crittografica basata su hash (non implementato: la chain in esecuzione ruota i leader in round robin e non ha alcuna VRF); e (iii) il campo Goldilocks sotto-specificato, per il quale imponiamo un'estensione di grado k e leghiamo la solidità di FRI al numero di query e al budget di grinding. Questa revisione migra inoltre il livello di esecuzione dalla Solana Virtual Machine alla Ethereum Virtual Machine (EVM), portando gli asset ERC-20 e i contratti Solidity sotto il modello di transazione shielded, e introduce il regolamento del gas in batch: poiché un addebito di gas per singola transazione in RAND shielded è esso stesso un'impronta deanonimizzante della chiamata EVM (e quindi del contratto ERC-20 toccato), il gas viene vincolato a livelli di quantizzazione pubblici all'interno del circuito e dedotto come un unico addebito aggregato per batch, così che l'impronta on-chain sia un totale per batch anziché una deduzione per account e per chiamata. Infine, forniamo una roadmap di migrazione di crypto-agility che parte con le SNARK, passa a STARK trasparenti e si consolida fino alla piena sicurezza post-quantistica in circa 18 mesi di calendario (circa 14 mesi sul percorso critico parallelizzato), con ogni transizione condizionata in modo da essere una modifica di parametri anziché un fork di consenso.
Questa revisione di agosto 2026 estende il modello shielded dai trasferimenti di valore al calcolo arbitrario confidenziale: generalizziamo la relazione di trasferimento a una relazione di esecuzione universale su una macchina virtuale dimostrata con STARK, specifichiamo topologie di proving GPU locali e delegate con il loro esatto confine di confidenzialità, e collochiamo il design rispetto al panorama attuale dei sistemi di prova (Groth16, PLONK, Halo2, HyperPlonk, STARK basate su FRI), delle zkVM general-purpose (RISC Zero, SP1, Cairo/Stwo, Miden, Jolt, OpenVM), dei rollup zkEVM e delle chain per la privacy (Aztec, Aleo, Miden, Zcash), le cui insidie nel pagamento del gas e nella delega ai prover motivano direttamente i design RAND shielded-gas e VPA. Analizziamo il mercato dei prover che il livello di incentivi implica, mostrando che il costo per prova è determinato dall'utilizzo e non dall'energia e che la domanda di proving di una rete satura è soddisfatta da poche decine di GPU: la decentralizzazione dei prover va quindi giustificata con la liveness e la confidenzialità anziché con un budget di sicurezza, poiché la solidità non dipende dall'insieme dei prover. Infine, specifichiamo come il collaterale esogeno in dollari, USDT e USDC, venga importato su Rand come z-asset shielded da un bridge lock-and-mint attestato, che offre al pool shielded un'unità di conto stabile senza richiedere agli emittenti di effettuare un deployment nativo, una dipendenza commerciale che altrimenti subordinerebbe la narrazione dei pagamenti del protocollo alla roadmap di una terza parte. Isoliamo la proprietà che rende solido un simile bridge ed è la più facile da omettere: un quorum di guardian attesta che un messaggio è stato pubblicato su una chain osservata, non che il bridge ne sia l'autore, per cui su un livello di messaggistica permissionless la validità della firma non implica l'autorizzazione e il vincolo dell'emittente è determinante. Dimostriamo un limite di custody-soundness che circoscrive la perdita alla custodia per singola chain indipendentemente dall'ipotesi sui guardian, mostriamo che l'offerta di z-asset shielded resta pubblicamente verificabile rispetto a tale custodia senza aprire alcuna note, e individuiamo nel bridge la frontiera post-quantistica del sistema: le firme dei guardian secp256k1 sono violabili con Shor, per cui il percorso di rilascio resta classicamente sicuro finché le chain di origine non rilasceranno precompilati post-quantistici, comunque venga rafforzato il lato Rand.
Risultati principali- Teor. 5.3 — Perdita di privacy nel pagamento del gas
- Teor. 7.9 — Privacy del gas in batch
- Teor. 10.6 — L'attestazione non implica l'autorizzazione
- Teor. 10.14 — Custody Soundness
- Thm 10.19 — Il bridge è la frontiera post-quantistica
- Thm 13.2 — Divario di attribuzione
- Thm 15.4 — Front-running, corretto e condizionato
- Thm 15.9 — Solidità di VPA
- Thm 18.1 — Separazione della sicurezza quantistica per primitiva
- Thm 19.2 — Solidità di FRI, parametrica
La Bozza 3 sostituisce le Bozze 1 e 2La Bozza 1 (dicembre 2025) e la Bozza 2 (la revisione VPA di maggio 2026) sono ritirate. Tre errori dell'analisi precedente sono corretti anziché attenuati: l'affermazione di 128 bit post-quantistici contraddiceva il limite di collisione quantistico di 85 bit di un hash a 256 bit; la VRF per la selezione del leader sarebbe stata violata da Shor su una curva ellittica; e il Goldilocks semplice non può sostenere la solidità di FRI dichiarata. Il livello di esecuzione passa dalla SVM alla EVM e il doppio token si riduce al solo RAND. Gli aggiornamenti di settembre 2026 riallineano il progetto al full node di riferimento fino alla chain 15: Rand è dichiarato esplicitamente come proof of stake, lo schema a conoscenza zero è scritto per esteso e VPA è indicato come una proposta che la chain in esecuzione non utilizza.
- ImplementazionezkVM · RISC-VHotStuffChain 15Testnet
Rand Protocol — Implementazione di riferimento
Un ledger schermato e una macchina virtuale verificata con STARK, così come è distribuita
Bozza di implementazione 3 · settembre 2026 · 46 pagine
Nella finanza tradizionale i sistemi di regolamento sono riservati per impostazione predefinita: i saldi dei conti e le registrazioni dei trasferimenti sono visibili al titolare del conto, all'istituzione e, in base a un procedimento legale, a un'autorità di vigilanza, e a nessun altro. Le blockchain pubbliche invertono questa proprietà. Su Ethereum e Solana lo stato globale e la coda delle transazioni in attesa sono osservabili da ogni partecipante, il che espone il flusso di ordini istituzionali a un front-running sistematico e rivela controparti e importi di ogni trasferimento di stablecoin. Nessun protocollo in produzione combina oggi la riservatezza di un ledger bancario con il regolamento deterministico, la verifica trasparente e la sicurezza post-quantistica di una chain pubblica.
Questo documento presenta Randprotocol, una blockchain di livello uno progettata per colmare tale divario, nella forma in cui è implementata nel suo full node di riferimento. L'asset nativo, RAND, esiste solo come note in un pool completamente schermato: un albero di impegni Poseidon2 di profondità 32 e un insieme di nullifier sostituiscono gli account, e ogni trasferimento è un bundle fisso a due input e due output, la cui validità è stabilita da una prova STARK trasparente, basata su hash, dell'esecuzione di un unico programma guest RISC-V fissato. Lo stesso sistema di prova supporta il calcolo arbitrario riservato: i programmi RV32IM sono distribuiti tramite hash del contenuto e invocati con una prova di esecuzione al posto dei loro input, e la chain registra otto parole di output pubbliche. Il consenso è HotStuff concatenato, con quorum ponderati per stake, una regola di commit a tre view consecutive e insiemi di validator derivati per epoca da un registro pubblico; lo stake è vincolato a partire dal pool e prelevato verso di esso. Un bridge attestato da guardiani deposita come note gli asset provenienti da quattro chain esterne. Le firme dei validator sono CRYSTALS-Dilithium2 e le buste delle note usano ML-KEM-768 con ChaCha20-Poly1305.
Descriviamo l'implementazione componente per componente e sviluppiamo poi la sua analisi formale rispetto ai parametri distribuiti: le relazioni di bundle e di chiamata dimostrate dalla macchina virtuale a conoscenza zero a nove tabelle, compresa la costruzione dell'accumulatore di taint che sostituisce un'asserzione nel circuito; gli argomenti di lookup-bus che vincolano il digest del programma e l'impegno di input con salt; la solidità di FRI del profilo di produzione (80 query, 20 bit di grinding, blowup 8, un'estensione di grado 2 del campo Goldilocks), enunciata sia con il limite proven proximity-gaps sia con la congettura ethSTARK; le identità di bilanciamento del valore e di audit dell'offerta del pool; e la safety e la liveness delle regole di consenso consapevoli delle epoche.
L'analisi individua le proprietà che l'implementazione non fornisce ancora. Commissioni, pesi dello stake, importi dei depositi al confine del pool e identità dei programmi sono pubblici; l'attuale wallet comunica al nodo interrogato la foglia che intende spendere; una prova a 80 query occupa circa 1,3 MB (1,43 MB per il bundle a quattro slot dalla chain 14 in poi), il che limita un blocco da 4 MiB a tre trasferimenti schermati (due dalla chain 14; la chain 15 porta il blocco a 20 MiB); l'aggregazione delle prove a livello di blocco, lo slashing e i guest EVM e SVM erano ancora in sospeso alla revisione di base (i guest sono stati nel frattempo integrati, benché le chiamate EVM non siano ammissibili con il limite di chiamate del tier 14, e tre cicli di audit guidati dai fondatori sono stati nel frattempo chiusi; non è stato eseguito alcun audit indipendente); e il prover GPU non è stato eseguito su hardware. Il software è distribuito su una rete di test di 26 validator (chain 17 dal 2026-09-29, con ogni validator gestito dal team fondatore) e non è adatto a un uso che coinvolga valore reale.
Risultati principali- Thm 5.8 — Solidità della conoscenza, condizionata
- Thm 5.11 — Conoscenza zero statistica
- Thm 5.12 — Solidità di FRI come istanziata
- Thm 5.14 — Sicurezza per primitiva del sistema distribuito
- Thm 5.17 — Bilanciamento del valore del pool
- Thm 5.22 — Safety
- Thm 5.24 — Liveness dopo GST
- Thm 5.28 — Il bridge non è post-quantistico
Redatto rispetto a fullnode 26ab1d4, con addendum fino a 8e64781Ogni affermazione sul sistema si riferisce al nodo di riferimento al commit 26ab1d4 (branch main, 2026-09-16): il pool schermato, lo staking, il bridge come note e buste di chiamata, il set di vincoli 6 della zkVM, la VM di ricorsione e l'aggregazione a livello di blocco, integrata ma attivabile solo da genesis. Due revisioni successive sono registrate come addendum contrassegnati dove il nodo è cambiato: 2026-09-24 (d050259, v0.5–v0.5.5, chain 14 — il bundle a quattro slot con asset nascosto, il registro dei token, il bridge rafforzato) e 2026-09-27 (8e64781, v0.5.6–v0.5.8, chain 15 — il pin dell'intestazione di chiamata e il limite di tier, le costanti Poseidon2 congelate, il vincolo di aggregazione).
- BridgeLock-and-MintECDSA · Dilithium2Quattro chain
Il bridge di Rand
Lock-and-mint attestato in un pool schermato, con co-firme post-quantistiche
Rapporto tecnico, bozza 1 · settembre 2026 · 13 pagine
Rand è una blockchain riservata il cui valore risiede come impegni in un pool schermato anziché come saldi trasparenti. Per i pagamenti serve un asset stabile, e nessun emittente ne distribuisce uno in modo nativo su una chain priva di volumi. Il bridge di Rand importa USDT e USDC da Ethereum, BNB Smart Chain, Tron e Solana come un unico dollaro schermato, zUSD, garantito uno a uno dalla custodia su quelle chain. Questo rapporto specifica il bridge così come è costruito: il messaggio di trasferimento da 184 byte e i suoi due livelli di firma — un quorum di guardiani secp256k1 per ogni messaggio e un quorum di co-firme Dilithium2 per ogni mint in Rand, oggi entrambi sei su otto; il percorso di deposito che termina in una note che la chain stessa deriva dall'importo attestato; il percorso di prelievo in cui un burn è vincolato alla sua prova e rilasciato a fronte di contatori di custodia per chain; la superficie di governance (rotazione dei guardiani con una finestra di tolleranza di un giorno, inserimento esplicito in elenco, una pausa unidirezionale che solo un quorum post-quantistico può revocare); e le regole sull'orologio che una chain collegata tramite bridge impone al proprio consenso.
Enunciamo e dimostriamo le proprietà che la costruzione garantisce — non falsificabilità del quorum, necessità del vincolo all'emittente, solidità della custodia, auditabilità dell'offerta, e il limite post-quantistico asimmetrico per cui un avversario dotato di capacità Shor può falsificare i rilasci ma non i mint — ed enunciamo, con pari cura, ciò che non garantisce: i guardiani non sono né vincolati con stake né soggetti a slashing, e sebbene sei delle otto chiavi funzionino ora su host propri, un solo account di hosting e una sola chiave dell'operatore le raggiungono ancora tutte. Sono riportati indirizzi di deployment, dimensioni dei messaggi, costi di gas e risultati dei cicli in produzione.
Risultati principali- Prop 5.1 — Nessun reindirizzamento
- Thm 5.2 — Solidità della custodia
- Thm 8.1 — Non falsificabilità del quorum
- Thm 8.3 — L'attestazione non è un'autorizzazione
- Thm 8.4 — Auditabilità dell'offerta tramite bridge
- Thm 8.5 — L'asimmetria post-quantistica
Complemento alla sezione sul bridge del paper del protocolloSpecifica il bridge così come è distribuito, con la stessa notazione della sezione cross-chain del paper del protocollo e in coerenza con essa: il guardian set 1 (sei su otto, secp256k1) ha sostituito il set originale cinque su sei il 2026-09-25, e il set Dilithium2 è passato da sei a otto chiavi al genesis della chain 15 il 2026-09-26.
- Stablecoin shieldedRiserva pienaMulti-chain · Multi-emittenteChain 15
zUSD — Un dollaro shielded interamente riservato su Rand
Trasferimenti riservati di stablecoin senza rischio di depeg, su una riserva bloccata multi-chain e multi-emittente
Settembre 2026 · sostituisce zUSDT (dic 2025, rev. ago 2026) · 11 pagine
zUSD è interamente riservato: ogni unità è garantita uno a uno da una stablecoin in dollari detenuta in un contratto di custodia sulla chain in cui quella stablecoin è emessa nativamente — USDT e USDC su Ethereum, BNB Smart Chain e Solana, e USDT su Tron, per un totale di sette backing — ed è riscattabile in uno qualsiasi di essi a richiesta. Non è deliberatamente una stablecoin algoritmica o frazionaria, quindi non ha alcuna dipendenza riflessiva dal prezzo di un asset volatile né la superficie di death spiral che ha distrutto UST di Terra. Il token vive su Rand, un ledger shielded, quindi è una note shielded fin dal momento in cui viene coniata. Ogni tratta è attestata, perciò la garanzia su ogni unità è min(solvibilità della riserva, integrità della soglia dei guardian), con una doppia soglia di sei firme ECDSA su otto e sei co-firme Dilithium2 su otto.
L'invariante di riserva S = Σ_b L_b vale con uguaglianza ed è imposto per costruzione in un'unica funzione del ledger. Il paper enuncia, per ciascun backing, ciò che è garantito, incluso il nuovo rischio introdotto dal pooling di due emittenti, ed elenca i meccanismi di contenimento delle perdite previsti dal deployment: un tetto di mint su 24 ore mobili per ciascun backing e uno globale, una chiave di pausa che può soltanto sospendere, un limite in avanti sul tempo di blocco e tetti di rilascio sui contratti di custodia. Dichiara esplicitamente ciò che non è ancora in atto: operatori guardian indipendenti, un amministratore multi-firma con timelock su ogni contratto di custodia e una proof of reserves verificabile senza l'explorer del progetto stesso.
Risultati principali- Teor. 2.6 — Conservazione dell'invariante
- Cor. 2.7 — Riscattabilità
- Prop. 2.8 — Degradazione della riserva piena a causa del bridge
- Cor. 2.9 — Garanzie per singolo backing
- Prop. 4.1 — Verificabilità pubblica in presenza di shielding
Settembre 2026 — sostituisce zUSDTDescrive il design così come è distribuito sulla chain 15 di Rand e si discosta da zUSDT in tre modi che il codice ora incorpora: il token vive su Rand e non su Solana, quindi non esiste una forma trasparente da schermare; la riserva copre due emittenti oltre che più chain, e un detentore può riscattare in qualsiasi backing; e ogni tratta è una tratta attestata, con una doppia soglia di sei su otto di co-firme ECDSA e Dilithium2. La Proposizione 2.8 è riprodotta senza modifiche perché è ancora corretta, e il Corollario 2.9 registra il nuovo rischio introdotto dal pooling di due emittenti.
- Analisi della sicurezzaPost-quantisticoTassonomia degli attacchi
Analisi della sicurezza del protocollo Rand
Fondamenti crittografici post-quantistici, resistenza agli attacchi e garanzie formali di sicurezza
Dicembre 2025, riconciliato a settembre 2026 · 13 pagine
Un'analisi della sicurezza del protocollo Rand con dimostrazioni formali sia nel modello avversario classico sia in quello quantistico, che copre il consenso BFT pesato per stake (Rand è una chain proof-of-stake: nessuna computazione conferisce peso nel consenso), il sistema di privacy basato su STARK e le primitive post-quantistiche CRYSTALS-Dilithium e Kyber. Analizza la resistenza ad attacchi del 51%, attacchi long-range, nothing-at-stake, grinding, eclipse e Sybil, front-running, attacchi di timing e avversari quantistici, con limiti formali e parametri concreti per ciascuno.
Sotto le ipotesi standard di difficoltà sui reticoli e con un'assegnazione per ruolo delle dimensioni dei digest — 384 bit dove una collisione compromette la solidità, 256 bit dove serve solo la resistenza alla preimmagine — ogni primitiva raggiunge almeno 128 bit di sicurezza post-quantistica; senza tale assegnazione la stessa costruzione ne raggiunge 85. Il limite inferiore del sistema è la solidità di FRI: almeno 100 bit sotto la congettura ethSTARK e 86 bit sotto il limite dimostrato dei proximity gaps, regolabile fino a 100 dimostrabili con 97 query e a 128 con un'estensione di grado 3. Dove l'implementazione di riferimento si discosta dal design — un hash di transcript a 256 bit, nessuno slashing dei validator, leader round-robin, un mempool in chiaro — ogni risultato lo segnala.
Risultati principali- Teor. 2.3 — Resistenza quantistica alle collisioni
- Teor. 3.5 — Sicurezza quantistica di STARK
- Teor. 3.6 — Sicurezza post-quantistica complessiva
- Teor. 4.4 — Safety di HotStuff
- Teor. 5.3 — Non collegabilità dei nullifier
- Teor. 6.8 — Mitigazione del front-running, condizionata
- Teor. 7.1 — Soglia di sicurezza economica
Subordinato alla Parte III del paper del protocolloUn complemento autonomo alla parte sulla sicurezza del paper del protocollo, che è il trattamento canonico riconciliato e prevale in caso di disaccordo. L'analisi di dicembre 2025 conteneva i tre errori che la Draft 3 corregge; da allora è stata riconciliata con la Draft 3 e con la chain in esecuzione.
- Riepilogo per gli investitoriRound seedSAFTOttobre 2026
Rand Protocol: riepilogo per gli investitori
Regolamento privato e programmabile con prove basate su hash
Ottobre 2026 · 6 pagine
Le blockchain pubbliche pubblicano ciò che le imprese devono proteggere: chi ha pagato chi, quanto, e ogni ordine prima che venga eseguito; per questo i maggiori bacini di capitale ne restano fuori. Rand è una chain di layer 1 in cui ogni pagamento è una nota shielded e ogni transazione una prova a conoscenza zero: la rete verifica che la regola sia stata eseguita senza vedere gli input, e una viewing key consente a un revisore di leggere ciò che i concorrenti non possono. I programmi in Rust o C girano su una zkVM RISC-V dimostrata da una STARK basata su hash, senza trusted setup, e i dollari arrivano da quattro chain come un unico dollaro shielded, zUSD.
Il riepilogo espone il problema, il prodotto e i suoi costi misurati, i casi d'uso per grado di maturità, il mercato con stime pubblicate, il confronto con Aleo, Railgun, Quantus e altri, un anno di ricerca e la ricostruzione in tre settimane fino a una rete di test attiva, il token e i prezzi dei round, il round seed (SAFT per 110 milioni di RAND, l'11% di un'offerta massima di un miliardo, a $0.03), il team e i rischi. Non costituisce un'offerta di alcun titolo o token.
Risultati principali- Chain 20 · v0.6.8
- Seed: $0.03 per RAND, $30M di FDV
- SAFT su un'offerta massima di 1B
- 28 release, 7 chain di test
File sorgente
Tutti e cinque i paper sono scritti in LaTeX e si compilano con tectonic. Il sorgente di zUSD è pubblico — è collegato dalla sua voce qui sopra, così che ogni affermazione possa essere verificata rispetto al file da cui proviene — accanto al sorgente superato di zUSDT nello stesso repository. I sorgenti degli altri quattro paper non sono ancora pubblicati; fino ad allora i PDF qui sopra ne sono la forma canonica. Tutto il resto che è pubblico — il nodo, i wallet, l'explorer — si trova nell'organizzazione GitHub.