Il problema: la fiducia non scala
Un recesso è un atto giuridicamente vincolante. Chi sostiene di aver receduto ha bisogno di una prova. Chi sostiene di aver ricevuto un recesso, altrettanto. Nella configurazione classica registri le voci nel tuo database, più un file di log, e speri che nessuno sostenga che hai modificato qualcosa.
Il problema: il gestore del database, cioè noi, potrebbe in teoria modificare tutto a posteriori. Un avvocato che mette in dubbio la tua prova ha vita facile. “Come facciamo a sapere che questa voce del database risale davvero al momento della ricezione?”
La soluzione in una frase
Ogni recesso riceve un'impronta. Alla fine della giornata raccogliamo tutte le impronte in un albero. Pubblichiamo la radice di quell'albero. Chiunque può verificare in seguito se il proprio recesso era davvero nell'albero, senza ottenere accesso agli altri recessi.
Chi non legge il resto di questo articolo ha già capito l'essenziale.
L'impronta: SHA-256
SHA-256 è una funzione di hash crittografica. Inserisci una quantità qualsiasi di testo e ottieni 64 caratteri. Questi 64 caratteri sono univoci per quel testo. Cambia una sola virgola e l'intera impronta cambia. È praticamente impossibile trovare due testi diversi che producano la stessa impronta.
Da noi ogni recesso viene serializzato alla ricezione in un blocco di testo definito: nome, contatto, riferimento dell'ordine, testo libero, marca temporale al millisecondo, ID dello shop. Questo blocco passa attraverso SHA-256. Risultato: un'impronta di 64 caratteri.
L'impronta è come la prova di una busta sigillata. Se in seguito mostriamo il contenuto e qualcuno ricalcola l'impronta, deve coincidere di nuovo esattamente. Se un solo carattere differisce, ad esempio perché abbiamo abbreviato il nome a posteriori, l'impronta non coincide più. La manomissione diventa visibile.
L'albero: albero di Merkle
Un'impronta per recesso è un buon inizio, ma non basta ancora. Dovremmo pubblicare ogni impronta singolarmente per renderle verificabili. Sarebbe un incubo per la protezione dei dati, perché dalle impronte unite all'informazione “questa impronta era sul server al tempo X” si potrebbero trarre conclusioni.
Gli alberi di Merkle risolvono il problema in modo elegante. Prendi due impronte, le combini e ne calcoli di nuovo l'hash. Riprendi questa nuova coppia di impronte insieme alla coppia successiva, finché alla fine resta un'unica impronta: la radice dell'albero.
Recesso A → hash_A ─┬───── hash_AB ─┬──────────┐
Recesso B → hash_B ─┘ │ │
│ Radice
Recesso C → hash_C ─┬───── hash_CD ─┘
Recesso D → hash_D ─┘La radice è esattamente la stessa solo se ogni singolo recesso sottostante è invariato. Una sola lettera modificata in un singolo recesso ne ribalterebbe l'impronta, poi l'impronta della coppia superiore, poi la successiva, fino alla radice. La radice non coinciderebbe più.
L'analogia del notaio
Immagina un notaio. Ogni giorno a mezzanotte raccoglie tutti i recessi della giornata, li scrive in un registro, lo sigilla e lo ripone in una cassaforte. Il mattino seguente pubblica su un cartellone davanti a casa un breve codice che corrisponde solo a quel registro.
Se in seguito qualcuno si presenta sostenendo che il suo recesso è nel registro, il notaio può mostrarglielo: “Sì, guardi, qui a pagina 47, riga 12. Il codice sul cartellone corrisponde esattamente a questo registro. Se avessi modificato qualcosa, il codice non corrisponderebbe più, e tutti lo vedrebbero sul cartellone.”
Il registro è il database. Il sigillo è l'impronta SHA-256. Il cartellone è il nostro endpoint pubblico. Il codice è la radice di Merkle.
La radice pubblica: /proof
Ogni giorno a mezzanotte calcoliamo l'albero di Merkle di tutti i recessi ricevuti quel giorno. Scriviamo la radice in un endpoint pubblico all'indirizzo /proof/root/YYYY-MM-DD.
Ogni gestore di shop riceve un proof_token per ogni recesso. È il percorso completo attraverso l'albero, dal proprio recesso fino alla radice. Con questo token qualsiasi terzo, anche un giudice, anche il cliente stesso, può verificarne l'autenticità.
GET /proof/{token}
Response 200:
{
"revocationHash": "9f86d081884c7d659a2feaa0c55ad015...",
"merkleProof": ["a3f5...", "b2e8...", "c1d4..."],
"merkleRoot": "5d41402abc4b2a76b9719d911017c592...",
"publishedAt": "2026-04-13T00:00:00Z",
"verifiable": true
}Chi vuole verificare la logica prende il revocationHash, lo combina secondo le regole degli alberi di Merkle con gli elementi di merkleProof, e dovrebbe ottenere alla fine esattamente il merkleRoot. Si può ricalcolare in dieci righe di codice in qualsiasi linguaggio di programmazione.
Protezione dei dati: perché resta conforme al GDPR
Il bello dell'albero di Merkle è che la radice non consente alcuna conclusione sui singoli recessi. Non pubblichiamo né i nomi, né le e-mail, né tantomeno le singole impronte. Solo la radice e, per ogni recesso, la prova di percorso individuale.
La prova di percorso la ottiene solo chi conosce il proof_token. E lo ottengono solo il gestore dello shop, il cliente e chiunque riceva il token da uno dei due. Non esiste alcun elenco pubblico.
Così la costruzione soddisfa contemporaneamente due requisiti apparentemente contraddittori: la verificabilità pubblica e la protezione dei dati delle singole operazioni conforme al GDPR.
Perché regge in tribunale
Un giudice non deve capire come funziona SHA-256 per accettare una perizia basata su SHA-256. La funzione è standardizzata dal 2001, è usata in tutto il mondo da banche, governi e blockchain, e non è crittograficamente compromessa.
Ciò che conta è che la radice di Merkle sia stata pubblicata in un momento in cui nessuno poteva più influenzarla a posteriori. Per questo la scrittura a mezzanotte, e per questo l'archiviazione immutabile. Chi sostiene che abbiamo aggiunto una voce a posteriori dovrebbe spiegare come abbiamo contemporaneamente modificato la radice già resa pubblica il giorno seguente. Questa spiegazione non esiste finché SHA-256 non viene compromesso.
In pratica: cosa vedi nella dashboard
Nella dashboard ogni recesso riceve un link a /proof/{token}. Puoi inoltrare questo link a un avvocato o verificarlo tu stesso. In un'eventuale controversia legale è la tua verifica tecnicamente neutra, indipendente da noi.
E poiché noi stessi non possiamo intervenire nell'albero senza distruggere la radice pubblica, siamo anche noi vincolati dalla prova. Non è una promessa di marketing, ma un limite strutturale del sistema.
Perché altri fornitori non lo hanno
La maggior parte dei fornitori di pulsanti di recesso scrive semplicemente la voce nel proprio database e si affida ai backup e alla buona coscienza. Basta finché la prima controversia non degenera. Allora ti ritrovi con una riga di database che un perito tecnico classifica come manipolabile in dieci secondi.
Abbiamo scelto l'impegno aggiuntivo perché l'obbligo derivante dalla Direttiva (UE) 2023/2673 (recepita in Italia con il D.Lgs. 209/2025 nel Codice del Consumo, in vigore dal 19 giugno 2026) è troppo recente per affidarsi alla consuetudine. Le prime decisioni giudiziarie devono ancora arrivare. Quando arriveranno, vorrai stare dalla parte in cui c'è la matematica.
Dettagli sull'implementazione nella nostra guida o sulla pagina del prodotto.