L'eredità nel Compratempo

Stato: v0.3 — maggio 2026 Cambio rispetto a v0.2: aggiornato il contesto wallet provider — la scelta è ora custodial in-house. La sostanza del documento non cambia: l’eredità nel Compratempo è un problema istituzionale, non tecnico-wallet, e la Strada 3 (custodia della memoria) funziona indipendentemente da chi gestisce le chiavi sotto. Con l’implementazione in-house, tutti i pattern di eredità diventano tecnicamente realizzabili (abbiamo accesso pieno alle chiavi), il che rende ancora più importante la disciplina su quali pattern usare — vedi sezione sulla Strada 1. Natura: documento concettuale, non operativo. Annota un problema importante con la sua inclinazione di soluzione, da maturare quando il Compratempo sarà più maturo. Riferimenti: visione, tessuto-sociale.

Perché ne parliamo

Il Compratempo costruisce, una tessera alla volta, il mosaico di una vita — il ritratto fatto di tempo donato e ricevuto che si compone negli anni. Naturale chiedersi: cosa succede al mosaico di una persona quando quella persona non c’è più?

Non è una domanda secondaria: è centrale. Il mosaico è memoria, e la memoria di una vita ha senso anche dopo. Una persona vorrà sapere che le sue tessere — le testimonianze del bene fatto e ricevuto — non si dissolvono con lei. Vorrà magari pensare a chi le custodirà.

Questo documento mette a fuoco il problema, mostra perché non è un problema del wallet provider (qualsiasi sia la scelta di custodia sotto), e propone una direzione di soluzione. È un documento di lavoro: la materia è viva, da maturare con consulenza legale al momento giusto.

Cosa i provider di wallet non risolvono nativamente

Una precisazione importante per non confondere:

Recovery in vita — accedere al proprio wallet da un nuovo dispositivo dopo aver perso il vecchio — è un problema solubile con meccanismi standard (export e re-import della chiave, recovery shards in soluzioni più sofisticate). Nel Compratempo con la scelta in-house, “recovery” è di fatto un nuovo onboarding: la persona riautentica via magic link e ritrova il proprio wallet associato al proprio utente. L’utente è ancora vivo, è ancora lui ad autenticarsi, semplicemente da un altro device. Funziona bene.

Eredità vera — cosa succede al wallet quando l’utente muore — non è risolta nativamente da nessun provider embedded wallet. Tutti richiedono in qualche forma un’autenticazione attiva dell’utente per le operazioni sul wallet, e una persona deceduta non produce più autenticazioni. Il wallet diventa “orfano” — le sue tessere restano on-chain (sono soulbound, intrasferibili: nessuno può rubarle né spostarle), ma nessuno può più operare il wallet.

Quindi l’eredità nel Compratempo è un problema principalmente istituzionale, non tecnico. I provider possono offrire alcune primitive utili (gli authenticator multipli, i flussi di recovery), ma il come si accerta un decesso, chi attiva l’eredità, come si raccoglie il consenso dell’erede in vita — sono questioni istituzionali. Si affronta a un altro livello rispetto al “wallet provider”.

La natura del problema: cosa significa “ereditare” nel Compratempo

Prima di proporre una soluzione, vale la pena ragionare su cosa si dovrebbe ereditare. Le tessere del Compratempo non sono come gli asset finanziari di un wallet tradizionale: hanno proprietà specifiche che ne ridisegnano l’eredità.

Le tessere sono soulbound (ERC-5192). Per costruzione non si trasferiscono. Una tessera di Anna resta di Anna anche on-chain, per sempre. Non si può “mandare la tessera all’erede” perché tecnicamente non si può. Questo è coerente con la natura della tessera come memoria personale: non è un titolo da cedere, è un ricordo.

Le tessere non hanno valore economico nel sistema. Non si vendono, non si scambiano, non producono rendimento. Quindi “ereditare le tessere” non è ereditare un patrimonio. È ereditare una memoria.

Le tessere sono già pubbliche on-chain. Chiunque, oggi, può leggere il mosaico di un qualsiasi wallet del Compratempo guardando la chain — è un dato pubblico. Quindi l’erede non acquisisce informazione che non avrebbe: ha l’informazione comunque. Cambia come la incontra.

Ne discende che il problema dell’eredità nel Compratempo è di natura particolare: non è “trasferire un asset”, è custodire una memoria altrui dentro un sistema che ne riconosce il valore. È più vicino all’eredità di un diario, di una collezione di fotografie, di una libreria personale — oggetti che hanno valore affettivo e mnemonico, non economico.

Tre strade per l’eredità (con la mia inclinazione)

Strada 1: Eredità via Compratempo come gestore della custodia

Anna designa un erede; al decesso, il Compratempo (come istituzione, con prova del fatto) trasferisce la custodia del wallet di Anna all’erede.

Con il wallet custodial in-house questa strada è tecnicamente molto realizzabile. L’API ha pieno accesso alle chiavi cifrate dei wallet utenti (con la master key di cifratura del Compratempo). Potrebbe legittimamente, in presenza di prova di decesso, recuperare la chiave di Anna e trasferirla all’erede.

Pro: soluzione “completa” — l’erede acquisisce pieno controllo del wallet di Anna, può anche solo “guardarne il mosaico” o usarlo come crede.

Contro nonostante la fattibilità tecnica:

Il fatto di poter fare questa cosa è esattamente la fonte del potere indebito che vogliamo evitare. Avere la capacità di trasferire la custodia significa anche poter essere obbligati a farlo da terzi (autorità, contenziosi). Capacità tecnica non significa che sia saggio usarla.
Apre la domanda: chi decide cosa sia “prova di decesso”? Senza una governance chiara, si rischia di abusare di questo potere. Ricorda che abbiamo nominato — nel tessuto-sociale-v1.0 — il rischio di “potere indebito sull’utente”: questa è esattamente la situazione che vogliamo evitare.
Anche se l’erede acquisisce il wallet, eredita anche tutte le sue capacità future (firmare nuovi scambi, eccetera). Questo solleva domande: l’erede può firmare scambi “per conto di Anna” che è morta? Probabilmente no, e quindi la maggior parte delle capacità del wallet diventerebbe sterile per l’erede.

Con la scelta in-house questo trade-off diventa ancora più importante: non c’è più il “rifugio architetturale” di un provider esterno che limita cosa possiamo fare. Tutto è nelle nostre mani. Proprio per questo la disciplina su cosa scegliere di fare deve essere ancora più rigorosa. Strada possibile, ma carica di responsabilità istituzionale e di rischi di potere indebito. Da valutare con cura — non da imboccare leggermente.

Strada 2: Eredità come problema dell’utente, fuori dal Compratempo

Anna, finché è viva, fa l’export della propria chiave privata e la conserva accessibile a un erede di sua scelta (testamento notarile con la chiave, password manager con accesso d’emergenza, busta sigillata). Quando Anna muore, l’erede accede a quella chiave e importa il wallet in un suo wallet client. Tecnicamente diventa Anna dal punto di vista del wallet.

Pro: nessun coinvolgimento del Compratempo, nessuna dipendenza da provider. Pattern “classico” della crypto custody.

Contro: richiede che Anna sia tecnicamente attiva — sappia che esiste l’export, lo faccia, lo conservi bene. Per Anna anziana, non-tecnica, è una soglia significativa. Esattamente la tecnicalità da cui il Compratempo voleva sollevarla.

Strada 3: Eredità come custodia della memoria, registrata nel modello

Anna designa nel Compratempo un erede (un altro utente del Compratempo). Il Compratempo conserva questa designazione come dato proprio. Quando il decesso è accertato (vedi sotto), il sistema non sposta il wallet: lo lascia dov’è, orfano on-chain. Ma sposta logicamente le tessere dentro il proprio modello: il mosaico dell’erede, da quel momento, include anche le tessere di Anna, marcate distintamente come “in custodia, ereditate da Anna”.

L’erede custodisce le tessere, non le possiede:

Non può “rivenderle” (non hanno valore economico nel sistema, e comunque sono soulbound).
Non può “fingere” che siano sue (sono visibilmente marcate come tessere di Anna).
Le guarda, le mostra, le ricorda. Le tiene vive.

Pro:

Rispetta la natura soulbound delle tessere: non le sposta, non le falsifica.
Funziona indipendentemente dalla scelta tecnica del wallet sotto: stessa logica vale per wallet custodial in-house (la scelta attuale), self-custody indipendente, o qualunque altra soluzione futura.
Coerente con la filosofia del Compratempo: la chain custodisce i fatti immutabili (le tessere di Anna restano dov’erano, per sempre); l’API media le esperienze (l’erede vede il mosaico di Anna nel proprio). Stesso pattern dell’architettura generale.
Coerente con la natura del Compratempo come istituzione che custodisce memoria: l’eredità della memoria non è un trasferimento, è un riconoscimento.

Contro:

Il wallet di Anna resta orfano on-chain (con possibili minime conseguenze: nessuno paga il gas se mai servisse, nessuno può “ravvivare” eventuali tessere future di Anna che fossero state in scolpitura al momento del decesso). Limitazioni minori.
Richiede un meccanismo di accertamento del decesso (vedi sotto).

Inclinazione: la Strada 3

La Strada 3 è la più coerente con tutto: con la natura soulbound delle tessere (non si trasferiscono), con la natura del mosaico come memoria (si custodisce, non si possiede), con la filosofia “fisica neutra + istituzione con valori” che attraversa il Compratempo (la chain non si tocca, l’istituzione interpreta), e con l’indipendenza dai provider di wallet (funziona uguale per chiunque).

In sostanza: l’eredità diventa un atto del Compratempo come istituzione, non un problema tecnico-wallet. Anna non deve essere tecnicamente competente per lasciare in eredità il proprio mosaico — basta che designi un erede nel sistema. Il Compratempo si fa carico di onorare quel legame al momento giusto, come si è già fatto carico di altre cose (interrompere abusi su segnalazione, custodire la memoria di rete, conservare chi-ha-presentato-chi).

Cosa va affrontato per realizzare la Strada 3

Quando si arriverà al momento di costruire questa funzionalità (non per il pilota — più avanti), questi sono i nodi da sciogliere:

1. Modello: l’entità “designazione di erede”. Una nuova relazione nel modello dell’API: Anna designa l’utente X come erede del proprio mosaico. Singola (un solo erede) o multipla (più eredi che custodiscono insieme)? Inclinazione iniziale: singola, per semplicità, con la possibilità di cambiare designazione in vita. Lascia spazio a multipla in evoluzione.

2. Consenso dell’erede. L’erede deve essere informato e consenziente? Probabilmente sì — custodire la memoria di una persona è un atto che richiede consapevolezza. Inclinazione: consenso dell’erede richiesto alla designazione, simile al consenso reciproco della presentazione (vedi tessuto sociale).

3. Accertamento del decesso. Chi attesta il fatto e come? Tre possibilità:

Self-attestazione di un familiare (con verifica documentale dietro): pratico, ma apre porta ad abusi.
Documento ufficiale (certificato di morte): solido, ma scoraggia chi non vuole interagire con burocrazia.
Procedura mista con periodo di “dormancy” (l’utente non si autentica per N mesi → notifica all’erede designato → l’erede può attivare l’eredità con documento di decesso) — più gentile, meno fragile.

Inclinazione: procedura mista è probabilmente la migliore. Da approfondire con consulenza legale.

4. Reversibilità. L’eredità una volta attivata è definitiva, o l’erede può “rifiutarla” successivamente? Inclinazione: rifiutabile, perché custodire memoria di altri è un atto che ha senso solo se voluto. Se Anna designa Maria come erede ma Maria non sopporta il peso, Maria può rifiutare e la designazione cerca un nuovo erede o decade.

5. Visualizzazione. Come l’erede vede le tessere di Anna nel proprio mosaico? Inclinazione: sezione separata (non mescolate alle proprie), titolata “Custodia di [Anna]”, visivamente distinta, con la storia di Anna eventualmente accennata. Il mosaico dell’erede include il mosaico di Anna, ma rispetta la sua identità — non lo cannibalizza.

6. Privacy e dato sensibile. La designazione di erede è dato altamente sensibile (sa chi morirà prima di chi, sa relazioni intime). Va trattata con cura — accesso ristretto, eventualmente cifrata at-rest, mai esposta in modi sbagliati. Da affrontare insieme alle altre questioni di hardening.

7. Eredità di un erede. Anna designa Maria; Maria muore prima di Anna. Cosa succede? La designazione decade automaticamente e Anna è notificata che la sua eredità non ha più destinatario; può designarne un altro. Caso da gestire ma non complicato.

8. Modello giuridico. La consulenza legale dovrà chiarire: è questa una “successione” nel senso giuridico? Il Compratempo, riconoscendo l’eredità di tessere, sta facendo qualcosa che ha rilevanza giuridica (in Italia, in UE)? Quasi certamente no (le tessere non sono asset finanziari, non hanno valore di mercato), ma va verificato.

La consulenza legale necessaria (al momento giusto)

L’eredità è uno dei temi che richiede consulenza legale specifica, oltre alla consulenza generale prevista prima del lancio. Domande da portare:

L’eredità di tessere soulbound senza valore economico costituisce successione giuridica? (Probabilmente no, ma verificare.)
Il Compratempo come istituzione, attestando un decesso e attivando un’eredità, ha responsabilità simili a un esecutore testamentario? (Quasi certamente non al livello formale, ma quale è il livello informale?)
Quale documentazione minima richiedere per accertare un decesso? (Certificato di morte, dichiarazione sostitutiva, altro?)
In caso di conflitto fra eredi (Anna non ha designato erede ma più familiari rivendicano la custodia), il Compratempo come arbitra?
Aspetti GDPR: trattare il “diritto all’oblio” del defunto (la cancellazione dei suoi dati personali) come si concilia con la custodia delle sue tessere da parte di un erede?

Queste sono materie per uno studio specializzato in diritto delle nuove tecnologie e successioni. Non per il pilota — per il momento maturo.

Cosa NON è eredità nel Compratempo

Per chiarezza, alcune cose che il Compratempo non fa, anche se a prima vista potrebbero sembrare eredità:

Non trasferisce wallet. Le tessere di Anna restano nel wallet di Anna on-chain, per sempre. Il wallet resta orfano. (Se Anna in vita ha fatto export delle chiavi e le ha lasciate accessibili a un familiare, allora fuori dal Compratempo il wallet può tecnicamente essere operato dal familiare — ma è il pattern self-custody indipendente, non l’eredità nel modello del Compratempo.)
Non riassegna autorialità. Le tessere di Anna sono di Anna: chi le custodisce non ne diventa autore. È custodia, non sostituzione.
Non eredita relazioni. Le connessioni di Anna (chi conosceva, chi le aveva presentato chi) non passano automaticamente all’erede. La rete sociale di Anna era sua. L’erede custodisce la memoria del suo tempo donato, non le sue amicizie.
Non eredita conti pendenti. Eventuali Proposte di Anna ancora aperte (non scolpite) decadono al decesso. Niente “fai onorare gli accordi pendenti”: il Compratempo non sa cosa l’altra parte avrebbe accettato.

L’eredità nel Compratempo è stretta e precisa: custodia delle tessere come memoria. Niente di più, niente di meno. Coerente con tutto il resto.

Stato e prossimi passi

Questo documento è v0.1 — una prima messa a fuoco. La materia non è ancora matura per essere costruita, e non lo sarà prima che:

Il Compratempo sia in funzione da abbastanza tempo da avere utenti con relazioni di lungo termine.
Sia stata fatta consulenza legale specifica sui temi sopra elencati.
Sia stata coinvolta la fondazione (futura) come soggetto che porta la responsabilità istituzionale del processo.

Per il momento, ciò che conta è aver annotato la direzione (Strada 3 — custodia della memoria, non trasferimento di wallet) e aver mostrato perché il problema è principalmente istituzionale. Questo libera la scelta del wallet sottostante da considerazioni sull’eredità: custodial in-house (scelta corrente), self-custody indipendente, o qualsiasi altra soluzione futura — l’eredità funziona uguale, perché vive a un altro livello.

Una nota sulla scelta in-house: avendo pieno accesso alle chiavi cifrate sotto la nostra master key, qualsiasi pattern di eredità è tecnicamente realizzabile dall’API — non solo la Strada 3 (custodia della memoria) ma anche la Strada 1 (trasferimento di custodia) e pattern misti. Avere queste capacità è una libertà, non un obbligo a usarle. Anzi: con la libertà tecnica viene la disciplina maggiore sulla scelta — vedi commento sulla Strada 1.

Documento sull’eredità nel Compratempo, v0.3 — maggio 2026. L’eredità del mosaico è custodia di memoria, non trasferimento di wallet.