Proof of reserves crypto: alberi di Merkle, passività e limiti

Proof of reserves, spesso abbreviato in PoR, è un’etichetta per procedure che cercano di mostrare una combinazione di due elementi: che un’organizzazione controlla determinati indirizzi di asset digitali e che i saldi dei clienti sono stati inclusi in un dataset di saldi. Un report può confrontare quegli asset con i crediti dei clienti che prende in considerazione. La sigla non identifica un metodo universale, uno standard contabile, un perimetro di asset, una definizione di passività o una frequenza di revisione.

Per questo, la prima domanda utile è più precisa di un rapporto in evidenza: che cosa è stato conteggiato esattamente, per quale entità giuridica, in quale momento e secondo quale procedura? Un exchange può pubblicare saldi dei wallet, un soggetto terzo può esaminare uno snapshot e un utente può verificare il proprio leaf di account in un albero di Merkle. Sono elementi di prova collegati, ma rispondono a domande diverse.

L’avviso dell’Office of the Investor Advocate del PCAOB mette in guardia sui limiti significativi dei report proof of reserves. Riflette il punto di vista del personale dell’Office of the Investor Advocate, non necessariamente quello del Consiglio del PCAOB o di altro personale PCAOB, e non è una regola, una politica né una dichiarazione del Consiglio del PCAOB. L’avviso spiega che queste procedure non sono audit svolti secondo gli standard PCAOB e potrebbero non affrontare passività, diritti dei clienti, asset presi in prestito, controlli o eventi successivi allo snapshot. Leggi l’avvertenza come un confine delle evidenze disponibili, non come un’affermazione secondo cui ogni processo PoR sia identico.

Un rapporto di copertura di solito divide un importo dichiarato di asset per un importo dichiarato di passività verso i clienti. Se un report elenca 1.020 BTC di asset inclusi nel perimetro e 1.000 BTC di saldi dei clienti inclusi, il rapporto semplice è 102%. Il calcolo ha senso solo dopo aver definito numeratore e denominatore. Sono entrambi espressi in BTC? Sono stati misurati nello stesso momento? Il dato sugli asset include solo indirizzi che l’entità può controllare? Il dato sui saldi comprende ogni conto, prodotto e credito dovuto dall’entità?

Un rapporto superiore al 100% non equivale automaticamente a un bilancio completo. Un report può concentrarsi sui saldi crypto dei clienti ed escludere altri debiti dell’azienda, imposte, costi operativi, pretese legali o obblighi verso finanziatori. Questi elementi possono incidere sulla solvibilità complessiva anche se non rientrano nella domanda più circoscritta: se un insieme selezionato di saldi dei clienti risulta coperto da un insieme selezionato di asset on-chain.

Anche il criterio di valutazione modifica il significato del rapporto. Se il report converte diversi token in dollari, il risultato dipende dalle fonti dei prezzi, dagli orari di rilevazione e dal trattamento degli asset scambiati con poca liquidità o a sconto. La quantità di token può restare invariata mentre il suo controvalore in dollari cambia. Quando possibile, confronta prima le quantità dello stesso asset e poi leggi le regole di conversione in valuta fiat e l’orario utilizzato. Non confrontare il saldo attuale di un wallet con uno snapshot delle passività riferito a un altro blocco o a un altro giorno come se descrivessero lo stesso stato simultaneo.

Un albero di Merkle raggruppa i record tramite hashing ripetuti. In uno schema tipico per i saldi di conto, un record viene trasformato in un leaf che rappresenta un identificativo di account e uno o più saldi. Gli hash vicini vengono combinati in hash genitore e il processo continua fino a un unico root che riassume il dataset impegnato. Un utente può ricevere il proprio leaf e gli hash fratelli lungo il percorso verso il root, quindi ricalcolare autonomamente il percorso.

La RFC 9162 dell’IETF definisce prove di inclusione per i log di Certificate Transparency: se l’hash dell’albero ricostruito coincide con il root pubblicato, la prova stabilisce che il leaf fornito è presente nell’albero impegnato. Gli exchange usano formati di dati e sistemi di prova propri, quindi la RFC spiega il concetto crittografico generale e non è una specifica per il PoR di ogni exchange.

Per esempio, Binance descrive il proprio albero di Merkle e il processo zk-SNARK come strumenti con cui gli utenti possono verificare che i record di conto contribuiscano al totale dichiarato, limitando al tempo stesso la divulgazione dei dati degli altri account. Kraken descrive l’inclusione dei saldi di conto e le evidenze di controllo degli indirizzi nel proprio processo PoR. Sono descrizioni specifiche dei singoli fornitori. Il limite generale è lo stesso: verificare il tuo leaf prova che il record è nel dataset impegnato. Non prova che l’operatore abbia iniziato da un elenco completo e corretto di ogni obbligazione verso i clienti.

Un block explorer può mostrare che un indirizzo deteneva una certa quantità a un determinato blocco. Questa osservazione non identifica chi può firmare per quell’indirizzo. Una firma separata o un’altra procedura di controllo può fornire evidenza che un’organizzazione sia in grado di autorizzare un messaggio tramite una chiave. Per esempio, la descrizione del processo Binance afferma che verifica che i wallet di riserva appartengano a Binance; Kraken afferma che il suo commercialista controlla le firme digitali degli indirizzi con saldi visibili pubblicamente.

Anche una firma valida non costituisce una conclusione giuridica o economica completa. Dimostra il controllo di una chiave per l’indirizzo o il messaggio verificato. Da sola non stabilisce che gli asset siano di proprietà legale dell’exchange e non detenuti per conto di terzi, liberi da pegni o vincoli, immediatamente trasferibili o disponibili per soddisfare un particolare credito di un cliente. Nel wallet potrebbero anche trovarsi asset presi in prestito al momento dello snapshot. L’avviso del personale PCAOB osserva specificamente che uno snapshot potrebbe non rivelare prestiti usati per far apparire più consistenti le riserve.

Conta anche l’elenco degli indirizzi. Un exchange può usare hot wallet, cold wallet, custodi, wallet omnibus o indirizzi condivisi tra prodotti. Il report dovrebbe spiegare come identifica gli indirizzi inclusi e come tratta gli asset detenuti tramite un altro custode. Se un indirizzo viene omesso, è controllato da un’entità collegata o viene contato due volte, il numeratore pubblicato può raccontare una storia diversa dagli asset disponibili per l’entità valutata.

Il denominatore può includere elementi diversi a seconda del fornitore e della data del report. I saldi spot sono solo una categoria possibile. Una metodologia può anche correggere i saldi per posizioni a margine, garanzie per i futures, staking, trasferimenti in sospeso, prestiti interni o profitti e perdite non realizzati. Il saldo mostrato al cliente non coincide sempre con la quantità usata nell’albero delle passività del report.

La pagina metodologica attuale di Kraken descrive trattamenti separati per saldi spot, staking, margine e futures, comprese alcune correzioni specifiche per prodotto. La pagina afferma inoltre che l’inclusione dell’account riflette gli asset nel perimetro allo snapshot e non include operazioni successive né asset fuori perimetro. È un esempio del motivo per cui le etichette di perimetro contano, non una formula universale valida per altre piattaforme.

Verifica quali società operative sono comprese. Un gruppo può avere più entità giuridiche, marchi, aree geografiche, controllate o custodi. Un report su una società o un insieme di wallet non copre automaticamente ogni prodotto mostrato nella stessa app. Chiediti anche se prelievi in sospeso, saldi negativi, prestiti, crediti derivanti da derivati e asset dei clienti detenuti presso affiliate siano inclusi o compensati. La risposta cambia il significato del denominatore.

Un record utile quindi riporta più di una data nell’intestazione. Identifica il periodo esaminato, l’orario dello snapshot e l’altezza dei blocchi, le entità e i prodotti coperti, gli asset e i saldi inclusi, le esclusioni, la fonte di valutazione, le regole di compensazione e il metodo usato per verificare il controllo dei wallet. Senza questi dettagli, “coperto al 100%” può descrivere un perimetro molto più ristretto di quanto immagini il lettore.

Supponiamo che un report ipotetico indichi 1.020 BTC di asset e 1.000 BTC di passività verso i clienti. Il rapporto mostrato è 1.020 ÷ 1.000 = 102%. Ora supponiamo che il dataset ometta 50 BTC di crediti dei clienti. Il totale completo delle passività verso i clienti sarebbe 1.050 BTC e la copertura diventerebbe 1.020 ÷ 1.050 = 97,14%. La differenza non coperta sarebbe di 30 BTC, prima di considerare altri debiti o variazioni di valutazione.

In questo esempio il dato sugli asset non si è mosso. La conclusione è cambiata perché è cambiata la popolazione delle passività. La prova Merkle di un cliente può comunque verificarsi correttamente se il leaf di quel cliente è incluso; non può rivelare se la pretesa omessa di un altro cliente manchi dall’albero. Ecco perché una prova di inclusione e un controllo di completezza sono verifiche distinte.

Un secondo esempio ipotetico mostra perché agli asset presi in prestito deve corrispondere la passività relativa. Immagina che un’entità abbia $980.000 di asset propri liberi da vincoli e prenda in prestito altri $200.000, ancora presenti nei suoi wallet allo snapshot. I wallet visibili contengono $1,18 milioni. Se i crediti dei clienti ammontano a $1 milione e il report omette l’obbligo di restituzione dei $200.000, il confronto mostrato è 118%. Includendo il credito di $200.000 del finanziatore, gli obblighi totali diventano $1,2 milioni; $1,18 milioni divisi per $1,2 milioni fanno 98,33%, con un disavanzo di $20.000. L’esempio assume valori confrontabili nello stesso momento e ignora altri asset, commissioni e dettagli giuridici. Mostra perché uno snapshot degli asset, da solo, non risolve la questione delle passività.

Nel gennaio 2026, Binance ha annunciato una modifica alla presentazione del proprio PoR dopo aver dichiarato che il precedente perimetro dei saldi netti degli account ometteva gli asset della piattaforma e produceva un rapporto di riserva gonfiato. Si tratta di una dichiarazione sulla metodologia e sull’aggiornamento di Binance, non della prova che ogni exchange usasse lo stesso calcolo. È un promemoria pratico: leggi cosa include il rapporto pubblicato e verifica se il metodo è cambiato tra un report e l’altro.

La parola “audit” può comparire nel marketing di una piattaforma o nel titolo di un report, ma il mandato e gli standard applicati continuano a contare. L’avviso del personale PCAOB afferma che gli incarichi PoR non sono svolti secondo gli standard di revisione PCAOB e non sono soggetti alle ispezioni PCAOB. Osserva inoltre che i fornitori usano procedure e standard diversi e che, in alcuni incarichi, la direzione può scegliere le procedure concordate.

Un report sulle procedure concordate di norma riferisce i risultati di passaggi specifici; non esprime necessariamente un giudizio sull’adeguatezza dell’insieme di procedure, sulla completezza delle passività o sulla stabilità finanziaria dell’azienda. Anche gli incarichi di assurance limitata sono diversi. Leggi il report: chi ha incaricato il fornitore, che cosa gli è stato chiesto di testare, quali evidenze ha esaminato, quali asset e passività sono inclusi, quali eccezioni sono emerse e quale conclusione dichiara davvero il fornitore.

Un audit separato del bilancio può coprire un’entità giuridica e passività più ampie, ma ha una propria data di riferimento, un quadro contabile, una materialità e un perimetro. Non dedurre che un exchange abbia questo tipo di audit solo perché un report PoR nomina uno studio contabile. Al contrario, i limiti del PoR non significano che ogni specifica dichiarazione sulle riserve sia falsa; significano che le evidenze sostengono soltanto le conclusioni effettivamente verificate dalle procedure.

Parti dalla data del report e dall’entità precisa. Conferma l’orario dello snapshot, le altezze dei blocchi pertinenti, i contratti dei token inclusi, gli indirizzi dei wallet, i prodotti degli account e l’eventuale inclusione di asset detenuti tramite custodi. Se una piattaforma pubblica un rapporto di copertura, cerca la formula e il denominatore invece di trattare la percentuale come un giudizio che si spiega da solo.

Poi separa le evidenze in due colonne. Per gli asset, chiediti che cosa dimostra il saldo dell’indirizzo, il controllo dell’indirizzo, la valutazione e l’assenza di prestiti, pegni, garanzie o conteggi doppi. Per i crediti dei clienti, chiediti come è stato prodotto lo snapshot degli account, quali saldi sono compensati, come vengono trattati i saldi negativi e le operazioni non ancora regolate e se sono inclusi tutti gli account e le entità rilevanti. Esamina poi il perimetro, gli standard, l’indipendenza, le eccezioni e la conclusione esatta del soggetto terzo.

Se è disponibile una prova personale di inclusione, verifica che il saldo del tuo account compreso nel perimetro ricostruisca il root pubblicato usando il metodo dichiarato dal fornitore e la data corretta del report. Tieni privata la prova perché identificativi dell’account o record di saldo possono essere sensibili. Una verifica riuscita ti dice che il record che hai ricevuto è nel dataset impegnato. Non ti dice che tutti gli altri record siano presenti, che sul lato degli asset non esistano pretese concorrenti o che i prelievi saranno elaborati durante un futuro evento di stress.

Infine, considera ciò che succede tra uno snapshot e l’altro. Una verifica puntuale non può monitorare continuamente prestiti, movimenti dei wallet, modifiche agli account, decisioni di governance o interruzioni operative dopo l’orario limite. Leggi insieme al PoR le condizioni di prelievo, gli accordi di custodia, le informazioni sulle entità giuridiche e gli eventuali bilanci più ampi. Per una panoramica collegata sulle differenze tra custodia e sede di negoziazione, consulta la guida ai perpetual CEX e DEX. Per la proprietà delle chiavi e le differenze dei wallet ospitati, consulta la guida al recupero dei wallet crypto.

Il PoR può rendere più trasparenti determinate evidenze e offrire agli utenti un modo per controllare se un record compare in un dataset impegnato. È utile. Non garantisce solvibilità, segregazione giuridica, copertura assicurativa, rimborso alla pari, prelievi senza interruzioni o protezione da frodi, attacchi informatici, errori di governance e procedure d’insolvenza. Queste questioni dipendono da passività, diritti legali, operazioni, custodia e norme applicabili nella giurisdizione dell’utente.

Non confondere un report sugli asset dei clienti di un exchange con un report sulle riserve di un emittente di stablecoin. Il primo riguarda in genere gli asset detenuti o controllati da una piattaforma a fronte dei crediti dei conti dei clienti; il secondo riguarda le riserve e le condizioni di rimborso di un accordo che disciplina un token. I meccanismi possono sovrapporsi, ma i crediti giuridici, le entità incluse e le vie di uscita sono diversi. La guida sul depeg e sul rimborso delle stablecoin spiega perché prezzo di mercato del token, riserve dell’emittente e valore di rimborso per il detentore siano misure distinte.

Una conclusione corretta è circoscritta e datata: “Questo report mostra questi asset e questi saldi inclusi, secondo il metodo dichiarato e allo snapshot indicato, e il record del mio account era incluso.” Se il report non consente di sostenere chiaramente nemmeno questa frase, il rapporto in evidenza non basta a colmare le lacune. Questa guida spiega evidenze e meccanismi di custodia; non raccomanda un exchange né indica dove detenere asset.