Token SPL e conti token in SSP

Se hai usato token ERC-20 su Ethereum, il modello dei token di Solana ti sembrerà familiare per una trentina di secondi e poi smetterà di avere senso. Su Ethereum un contratto token tiene un registro di chi possiede cosa, e il tuo indirizzo compare come una riga di quel registro. Su Solana il tuo indirizzo non compare affatto nei registri del token. Al suo posto viene creato un conto separato per custodire il tuo saldo di quello specifico token, di tua proprietà ma distinto dal tuo indirizzo principale.

Quell'unica scelta di progettazione spiega quasi tutte le sorprese che le persone incontrano con i token SPL: perché inviare un token a qualcuno di nuovo costa più che inviarlo a chi già lo possiede, perché un portafoglio può mostrare saldo zero di un token per un indirizzo che non l'ha mai toccato, e perché qui i decimali contano più che altrove. Questo articolo attraversa il modello così come SSP lo implementa.

Perché Solana ha bisogno di un conto separato per token

La regola di fondo di Solana è che tutto è un conto, e ogni conto ha un proprietario, una dimensione e un deposito d'affitto proporzionale a quella dimensione. Non esiste un contratto che faccia crescere in sordina una mappa interna man mano che arrivano utenti: lo spazio deve stare dentro un conto da qualche parte, e qualcuno deve pagarlo.

Così il programma SPL Token divide il lavoro. Il conto di mint conserva i fatti sul token stesso: offerta totale, decimali e chi può emetterne altri. Ogni possessore ottiene il proprio conto token, un piccolo conto di dimensione fissa che registra un saldo per un mint e indica un proprietario. Il tuo saldo in SOL vive al tuo indirizzo; il tuo saldo in USDC vive in un conto token che il tuo indirizzo controlla.

Il pregio di questo disegno è la prevedibilità: ogni saldo di token ha la stessa forma e costa uguale da conservare. Il prezzo è che detenere un token nuovo richiede di far nascere un conto nuovo. La documentazione sui token di Solana è la fonte primaria se vuoi la specifica invece del riassunto.

Il conto token associato, e chi lo paga

Se ogni possessore ha bisogno di un conto token, e chiunque può creare conti, finiresti con più conti token per persona e per mint senza modo di sapere a quale inviare. Il conto token associato — ATA — è la convenzione che risolve la cosa: per un dato proprietario e un dato mint esiste un unico indirizzo canonico, derivato in modo deterministico da entrambi. I portafogli possono calcolarlo, quindi nessuno deve pubblicarlo.

L'inghippo è l'affitto. Un conto token occupa circa 165 byte, il che equivale a circa 0,002 SOL trattenuti come deposito d'affitto finché il conto esiste. Quel deposito è recuperabile alla chiusura del conto, ma va versato in anticipo e da qualcuno che abbia SOL, cosa che per definizione il destinatario del suo primissimo trasferimento di token potrebbe non avere.

SSP gestisce la cosa come ogni altra commissione su Solana. Quando invii un token SPL a qualcuno il cui ATA non esiste, la transazione include un'istruzione idempotente per crearlo, e il paymaster di SSP paga l'affitto. Il tuo vault rimborsa il paymaster dentro la stessa transazione, ed è per questo che quel primo trasferimento verso un nuovo destinatario costa circa 0,0025 SOL in più di un trasferimento ripetuto alla stessa persona. «Idempotente» è la parola che conta: se il conto risulta già esistente, l'istruzione va a buon fine e non fa nulla, invece di far fallire l'intero trasferimento.

Nota che questa istruzione di creazione sta fuori dalla proposta multisig. Creare il conto token di qualcun altro non muove i tuoi fondi e non richiede autorizzazione dal tuo vault, quindi non appartiene alla parte che i tuoi due dispositivi firmano. Il rimborso, che invece muove i tuoi fondi, sta dentro la proposta.

Che cosa supporta SSP di serie

SSP arriva con SOL nativo, il mint ufficiale USDC di Circle e FLUX su Solana. Qualunque altro token SPL compaia nel tuo vault viene risolto e mostrato accanto a questi.

Vale la pena enunciare un limite deliberato: i trasferimenti Solana di SSP sono costruiti sul programma SPL Token classico. I token emessi con Token-2022, il programma più recente con transfer hook, trasferimenti riservati e altre estensioni, oggi non fanno parte del percorso di invio. È una scelta di perimetro, non una svista: le estensioni di Token-2022 possono cambiare ciò che fa un trasferimento, e supportarle significa verificare ciascuna estensione rispetto alle garanzie di decodifica sul dispositivo descritte più sotto.

Come viene costruito davvero un trasferimento di token

Quando invii un token SPL da SSP, la transazione che viene firmata contiene, nell'ordine:

1. Creare l'ATA del destinatario se serve: idempotente, pagata dal paymaster, fuori dalla proposta.
2. TransferChecked: sposta il saldo dal conto token del tuo vault a quello del destinatario, autorizzato dal vault.
3. Rimborsare il paymaster: un semplice trasferimento di SOL dal tuo vault, dentro la proposta.

Il tutto atterra come un'unica transazione atomica. Non c'è un passaggio di approvazione separato, nessuna proposta pendente ferma on-chain e nessuno stato in cui il conto del destinatario sia stato creato ma il trasferimento non sia avvenuto. O si esegue tutto, o niente.

Il conto di origine è l'ATA del tuo stesso vault, derivato nello stesso modo deterministico, con l'indirizzo del programma del vault come proprietario. Poiché il vault è un indirizzo derivato da programma e non una coppia di chiavi, la derivazione ammette esplicitamente un proprietario fuori dalla curva ed25519. Se vuoi il dettaglio sul perché l'indirizzo del vault funzioni così, il multisig Solana auto-inizializzante lo affronta.

I decimali fanno parte della firma

È il punto su cui vale la pena rallentare, perché è lì che un token può mentirti.

Un mint dichiara quante cifre decimali usa il suo token. USDC ne usa sei; molti token ne usano nove; non c'è una regola. Se un portafoglio mostra «100 USDC» ma costruisce un trasferimento per un numero di unità grezze che presuppone decimali sbagliati, puoi inviare mille volte tanto senza vedere nulla di strano a schermo.

SSP usa TransferChecked invece dell'istruzione di trasferimento semplice. La differenza è che TransferChecked incorpora l'indirizzo del mint e il byte dei decimali direttamente nei dati dell'istruzione firmata. Ne derivano tre controlli distinti:

• La tua estensione decodifica i byte e li confronta con ciò che sta mostrando.
• SSP Key decodifica gli stessi byte in modo indipendente sul telefono e li confronta con i metadati del token forniti dall'estensione.
• Il programma SPL Token on-chain confronta i decimali dell'istruzione con quelli effettivi del mint e rifiuta la transazione se differiscono.

Il terzo controllo è quello che non si aggira a parole. Un mint che dichiari decimali diversi da quelli che ha non produce un trasferimento sbagliato: produce una transazione fallita.

Ricevere token

Ricevere è più semplice, con una sfumatura. Dai al mittente il tuo indirizzo del portafoglio — quello che SSP mostra nella schermata di ricezione — non un indirizzo di conto token. Qualunque cosa stia inviando, l'ATA corretto viene derivato dal tuo indirizzo e dal mint, e il portafoglio del mittente lo crea se serve.

Se il tuo vault non ha mai posseduto quel token, il conto non esisterà finché non arriva il primo trasferimento, e il suo affitto lo paga chi ti invia. È normale e non richiede nulla da parte tua. Significa però che un esploratore di blocchi non mostrerà alcun conto token per un token che ti è stato promesso ma non ancora ricevuto: è il conto che non esiste ancora, non un trasferimento perduto.

Errori frequenti

Inviare a un indirizzo di conto token invece che a un indirizzo di portafoglio. Alcuni esploratori mostrano l'ATA in evidenza. Mandare un token a un conto token anziché al suo proprietario è un modo ben noto di perdere fondi su Solana. SSP si aspetta l'indirizzo del portafoglio del proprietario e deriva il resto.

Dare per sicuro un token sconosciuto perché compare nel portafoglio. Chiunque può creare un mint e inviartelo, e i mint possono avere nomi che imitano token reali. Che un token compaia nel tuo vault non è un avallo. Verifica l'indirizzo del mint su una fonte ufficiale prima di trattare un saldo come valore reale.

Aspettarsi approvazioni in stile Ethereum. I token SPL hanno un meccanismo di delega, ma lo schema di autorizzazione permanente che rende le approvazioni ERC-20 un rischio ricorrente non è il modo in cui è costruita la maggior parte delle applicazioni Solana. Se arrivi da Ethereum, approvazioni dei token: i permessi che continui a concedere spiega l'abitudine che stai disimparando, e Ethereum in SSP offre il confronto.

Dimenticare il sovrapprezzo del primo invio. I ~0,0025 SOL extra su un primo trasferimento a un nuovo destinatario sono affitto, non una commissione che SSP incassa. Restano nel conto token del destinatario e sono recuperabili da lui se un giorno lo chiude.

Per la meccanica passo passo di un trasferimento reale, vedi inviare Solana con SSP. Su come SSP tenga il vault sottostante in un multisig 2 su 2 senza creatore, parti da Solana in SSP.