Conia un token d'identità soulbound

Solana Token-2022 NonTransferable o Sui Closed-Loop Token — coniato nei portafogli, mai trasferito tra loro. Identità, presenze, attestazione KYC, reputazione.

I token soulbound sono come l'identità on-chain rimane on-chain. Una volta coniato in un portafoglio, il token non può mai muoversi — rendendolo utile per credenziali, prove di presenze, attestazioni KYC e sistemi di reputazione in cui la trasferibilità permetterebbe agli utenti di giocare l'assegnazione. Questo preset è l'SBT più semplice possibile su entrambe le catene: l'estensione Token-2022 NonTransferable di Solana o il Closed-Loop Token di Sui senza regola di transfer registrata su TokenPolicy.

Cosa è incluso

• Metadati immutabili: I metadati del token (nome, simbolo, icona) non possono essere modificati dopo la creazione
• Non trasferibile (Soulbound): Token can be minted to wallets but never transferred between them. Use for identity badges, attendance credentials, KYC attestations, or closed-loop loyalty points.

Perché questo stack

Su Solana, l'estensione NonTransferable è un singolo bit sull'account di conio — il programma SPL Token-2022 lo applica a livello di protocollo, nessuna logica personalizzata da verificare. Su Sui, `sui::token::Token<T>` è dichiarato solo con l'abilità `key` (no `store`), quindi `transfer::public_transfer` è rifiutato in fase di compilazione e ogni movimento richiede una regola TokenPolicy — che non registriamo. Il bypass è strutturalmente impossibile su entrambe le catene.

Perché non EVM?

EVM non ha una primitiva non trasferibile a livello di protocollo — ogni implementazione sovrascrive l'hook `_update` sulla base ERC-20 per ripristinare, che funziona ma non è così pulito (il percorso di ripristino è codice controllabile, non applicazione di protocollo). Solana e Sui espongono entrambi la semantica soulbound di prima classe, quindi distribuiamo lì per primo. Una variante EVM è tracciata per quando il caso d'uso giustifica un'implementazione per catena.

L'emittente può bruciare un badge?

Sì su entrambe le catene. Su Solana, l'estensione NonTransferable blocca i trasferimenti tra portafogli ma non i burn — l'autorità di conio può revocare una credenziale tramite l'istruzione SPL Token Burn standard. Su Sui, il distributore mantiene il TreasuryCap e può bruciare tramite `sui::token::burn` (la policy Closed-Loop si applica ai trasferimenti avviati dall'utente, non ai burn dell'emittente).

Qual è la differenza tra questo e il preset Loyalty su Sui?

Identity / SBT è la forma massimamente restrittiva — nessun trasferimento, mai, da nessuno. Loyalty (solo Sui) consente trasferimenti ma solo a indirizzi sulla whitelist gestita dall'emittente (i tuoi commercianti, portafogli partner, account operatore). Scegli Identity per credenziali e prove di presenze; scegli Loyalty per programmi a punti a circuito chiuso in cui i titolari hanno bisogno di spendere saldi all'interno della rete commerciante.