👇👇👇
Qualche giorno fa ho provato a spiegare a un amico come TokenTable gestisce i programmi di vesting. Ho iniziato in modo semplice — "immagina che ci sia un elenco di chi riceve token e quando." Lui ha annuito. Poi ho aggiunto: "e l'attestazione che conferma chi è su quell'elenco è emessa dalla stessa azienda che esegue il pagamento." Ha smesso di annuire.
Pensavo che forse avessi frainteso qualcosa. Sono tornato a rileggere la documentazione.
Non avevo frainteso.
Come funziona tecnicamente
TokenTable è una piattaforma di distribuzione di token — airdrop, vesting, programmi di sblocco. Ha elaborato oltre $4 miliardi in distribuzioni di token per più di 200 progetti e generato $15M in ricavi reali nel 2024. Starknet, ZetaChain, Notcoin — questi non sono nomi piccoli.
Sign Protocol è il livello di attestazione. Ti consente di emettere una prova on-chain verificabile: chi ha diritto a cosa, quando, e a quali condizioni.
Insieme sembrano perfetti: TokenTable definisce i criteri di idoneità, Sign Protocol attesta a loro, tutto rimane on-chain e auditabile. Il cliente vede una traccia completa per ogni sblocco.
Ma qui mi sono bloccato.
La parte che ho letto due volte
TokenTable controlla i programmi di sblocco. TokenTable decide chi entra nell'elenco di idoneità. E TokenTable usa Sign Protocol — di proprietà della stessa azienda — per attestare che quelle decisioni siano corrette.
Quindi l'attestazione dice: "questo indirizzo è idoneo." Ma è stata emessa dalla stessa entità che ha costruito l'elenco di idoneità.
Ho continuato a leggere la documentazione aspettandomi di trovare qualche passo di verifica indipendente. Un oracolo forse? Un voto DAO? Un auditor esterno che co-firma lo schema?
Finora — no. Il verificatore e l'esecutore sono la stessa struttura.
Perché questo non è necessariamente negativo
Non sto cercando di creare uno scandalo da questo — tecnicamente tutto è corretto. Sign Protocol è aperto, qualsiasi terza parte può controllare l'attestazione on-chain. Oltre $4B elaborati senza incidenti noti è un dato, non marketing.
La finanza tradizionale risolve questo con la separazione dei ruoli: la custodia è separata dall'esecuzione, l'audit dalla gestione. In Web3 quella linea è sfocata per design — e molti protocolli sono costruiti in questo modo nelle fasi iniziali mentre la reputazione del team funge da garante.
Ma Sign si sta spostando a un livello diverso ora. Contratti governativi negli UAE, Thailandia, Sierra Leone — questi non sono più casi studio di startup. Quando @SignOfficial signa contratti infrastrutturali a livello sovrano, la domanda di "chi verifica il verificatore" smette di essere accademica.
Dove questo potrebbe diventare un problema
Immagina uno scenario: un progetto importante usa TokenTable per il vesting del team. Diciotto mesi dopo emerge una disputa — il team dice che i criteri di idoneità erano una cosa, gli investitori dicono un'altra. L'attestazione on-chain esiste. Ma è stata emessa dalla stessa parte che controllava i criteri.
Questo non è ipotetico — è una situazione standard in qualsiasi progetto token in cui documentazione e realtà divergono.
Un'attestazione Sign in quel caso è prova che qualcuno ha confermato qualcosa. Non prova che la conferma fosse indipendente.
Dubbio soft
Ho iniziato a scrivere questo post intendendo lodare TokenTable per un'integrazione del protocollo elegante. Penso ancora che sia tecnicamente solido — e $15M di ricavi prima del lancio di un token è raro in Web3 e merita rispetto.
Ma più guardavo all'architettura, più notavo che "decentralizzato" qui significa "aperto all'ispezione" — non "verificato indipendentemente." Queste sono cose diverse.
A un certo punto — specialmente se Sign diventa genuinamente un'infrastruttura sovrana per gli stati — quella differenza potrebbe contare molto. O forse no. Quello che mi piacerebbe sapere è se il team ha un piano per quel scenario, o se è semplicemente una domanda che non è ancora arrivata nella roadmap.