Perché lo standard tecnico non è un dettaglio implementativo
La scelta dello standard di token non è una decisione tecnica separabile da quella legale: i due livelli sono intrecciati in modo indissolubile. Uno standard che non implementa KYC on-chain non può essere reso MiCA-compliant attraverso termini contrattuali off-chain — perché la blockchain è il meccanismo di enforcement, e se il meccanismo non esiste on-chain, non esiste in modo efficace.
Partire dallo standard sbagliato significa riscrivere i contratti intelligenti da zero. Non è un costo di refactoring — è un costo di re-deploy con migrazione dei token già emessi, con tutte le complicazioni giuridiche che questo comporta per i detentori esistenti.
ERC-20: il punto di partenza e i suoi limiti
ERC-20 è lo standard fungible token di Ethereum, proposto nel 2015 e diventato il riferimento universale per i token basati su smart contract. La sua semplicità è il suo punto di forza: sei funzioni — totalSupply, balanceOf, transfer, transferFrom, approve, allowance — e un meccanismo di eventi. Qualsiasi wallet Ethereum può ricevere e trasferire token ERC-20 senza permesso, senza identificazione, senza verifica.
Questa caratteristica è un vantaggio per i token di utilità generica su reti permissionless. Per i certificati energetici, diventa un problema strutturale: chi acquista, chi vende, e in quale giurisdizione sono informazioni che la norma richiede di conoscere e documentare. Un trasferimento ERC-20 non porta con sé nessuna di queste informazioni.
ERC-1155 risolve un problema diverso — la gestione di token fungibili e non-fungibili all'interno dello stesso contratto, con batch transfer efficienti. È la scelta corretta per Garanzie di Origine frazionabili come utility token, o per certificati energetici non-fungibili distinti per impianto e periodo. Anche ERC-1155, però, non ha meccanismi KYC built-in.
ERC-3643: lo standard permissioned
ERC-3643, sviluppato da Tokeny Solutions e noto come T-REX (Token for Regulated EXchanges), è lo standard che risolve il problema alla radice. È uno standard open-source, disponibile su GitHub, con implementazione di riferimento in Solidity.
L'architettura si basa su tre componenti:
ONCHAINID: il sistema di identità on-chain che consente a un provider KYC (tipicamente un intermediario finanziario o un identity provider accreditato) di attestare la conformità di un wallet a specifici requisiti verificabili on-chain. L'identità è separata dal wallet — un'entità può avere più wallet con la stessa identità ONCHAINID. Le attestazioni sono revocabili: se un utente perde i requisiti (ad esempio perché il suo status di investitore qualificato scade), il provider KYC revoca l'attestazione e il wallet non può più ricevere trasferimenti.
Compliance module: il contratto di compliance definisce le regole che ogni trasferimento deve rispettare: solo wallet KYC-approvati possono ricevere, limite massimo di investitori per giurisdizione, restrizioni per paese, limite massimo di token per singolo investitore. Queste regole sono eseguibili on-chain — non richiedono un intermediario umano per ogni transazione.
Transfer restriction on-chain: ogni chiamata a transfer o transferFrom passa attraverso la verifica del modulo di compliance prima di eseguire. Se il wallet destinatario non ha un'identità ONCHAINID valida con le attestazioni richieste, la transazione viene rifiutata direttamente dal contratto. Non c'è modo di aggirare il meccanismo — è la logica del contratto intelligente stesso.
Il processo per una GO tokenizzata italiana
Il flusso operativo per tokenizzare una Garanzia di Origine in formato ERC-3643 è il seguente:
Fase 1 — Setup: l'SPV emittente deploya il contratto ERC-3643 con i parametri di compliance (giurisdizioni ammesse, requisiti KYC minimi, limite per investitore). Deploy del contratto ONCHAINID per l'emittente stesso.
Fase 2 — KYC investitori: ogni potenziale acquirente completa il KYC con un provider ONCHAINID accreditato. Il provider attesta on-chain che il wallet è stato verificato e soddisfa i requisiti. L'attestazione è firmata crittograficamente — non modificabile senza la chiave del provider.
Fase 3 — Whitelist: l'emittente aggiunge i wallet KYC-approvati alla whitelist del contratto di compliance. Solo in questo momento i wallet diventano destinatari validi.
Fase 4 — Transfer: qualsiasi trasferimento successivo tra wallet entrambi in whitelist avviene normalmente. Se il destinatario non è in whitelist, il contratto rifiuta la transazione on-chain.
Confronto tra standard
| Caratteristica | ERC-20 | ERC-1155 | ERC-3643 |
|---|---|---|---|
| Permissioned | No | No | Sì |
| KYC on-chain | No | No | Sì (ONCHAINID) |
| Transfer restriction | No | No | Sì (compliance module) |
| MiCA adatto (offerte >1M€) | No | Parzialmente | Sì |
| Uso energetico tipico | DeFi, utility generica | GO frazionata utility | Security token, GO regolamentata |
| Complessità deploy | Bassa | Media | Alta |
MiCA compliance e whitepaper
Per emissioni che superano 1 milione di euro, ERC-3643 è lo standard tecnico che si integra correttamente con gli obblighi di whitepaper MiCA (artt. 19-21 del Reg. 2023/1114). Il whitepaper deve descrivere il meccanismo di compliance e le transfer restriction — ERC-3643 consente di descrivere meccanismi che sono effettivamente verificabili e non aggirabili on-chain. Con ERC-20, la stessa descrizione sarebbe contrattuale ma non tecnicamente enforced.
La combinazione ERC-3643 + ONCHAINID + whitepaper MiCA notificato a CONSOB costituisce lo stack tecnico-legale minimo per emissioni di certificati energetici tokenizzati sopra soglia in Italia nel 2026.
La scelta dello standard tecnico non è neutrale — ERC-20 per un asset energetico che configura security token è un errore legale prima che tecnico. Solaria accompagna il cliente nella scelta della struttura corretta, dallo standard contrattuale alla notifica CONSOB, lavorando con studi legali specializzati in fintech per garantire che la struttura on-chain e quella off-chain siano coerenti.
