Tokens SPL e contas de token na SSP
Se você já usou tokens ERC-20 no Ethereum, o modelo de tokens da Solana vai parecer familiar por uns trinta segundos e depois deixar de fazer sentido. No Ethereum, um contrato de token mantém um registro de quem possui o quê, e o seu endereço aparece como uma linha nesse registro. Na Solana, o seu endereço não aparece nos registros do token de jeito nenhum. Em vez disso, uma conta separada é criada para guardar o seu saldo daquele token específico, de sua propriedade mas distinta do seu endereço principal.
Essa única decisão de projeto explica quase toda surpresa que as pessoas levam com tokens SPL: por que enviar um token para alguém novo custa mais do que enviar para quem já tem, por que uma carteira pode mostrar saldo zero de um token para um endereço que nunca encostou nele, e por que casas decimais importam aqui mais do que em qualquer outro lugar. Este artigo percorre o modelo do jeito que a SSP o implementa.
Por que a Solana precisa de uma conta separada por token
A regra básica da Solana é que tudo é uma conta, e toda conta tem um dono, um tamanho e um depósito de aluguel proporcional a esse tamanho. Não existe contrato que faça crescer discretamente um mapeamento interno conforme chegam mais usuários — o armazenamento precisa morar em alguma conta, e alguém precisa pagar por ele.
Então o programa SPL Token divide o trabalho. A conta de mint guarda os fatos sobre o token em si: fornecimento total, casas decimais e quem pode emitir mais. Cada detentor ganha sua própria conta de token, uma conta pequena e de tamanho fixo que registra um saldo para um mint e nomeia um dono. Seu saldo de SOL mora no seu endereço; seu saldo de USDC mora numa conta de token que o seu endereço controla.
A vantagem desse desenho é a previsibilidade — todo saldo de token tem o mesmo formato e custa o mesmo para armazenar. O preço é que ter um token novo exige trazer uma conta nova à existência. A documentação de tokens da Solana é a fonte primária se você quiser a especificação em vez do resumo.
A conta de token associada, e quem paga por ela
Se todo detentor precisa de uma conta de token, e qualquer um pode criar contas, você acabaria com várias contas de token por pessoa por mint e sem jeito de saber para qual enviar. A conta de token associada — ATA — é a convenção que resolve isso: para um dado dono e um dado mint existe um único endereço canônico, derivado deterministicamente dos dois. Carteiras conseguem calculá-lo, então ninguém precisa publicá-lo.
O detalhe é o aluguel. Uma conta de token tem cerca de 165 bytes, o que dá aproximadamente 0,002 SOL retidos como depósito de aluguel enquanto a conta existir. Esse depósito é recuperável quando a conta é fechada, mas precisa ser pago adiantado, e por alguém que tenha SOL — o que o destinatário da primeiríssima transferência de token dele, por definição, pode não ter.
A SSP lida com isso do mesmo jeito que com qualquer outra taxa da Solana. Quando você envia um token SPL para alguém cuja ATA não existe, a transação inclui uma instrução idempotente para criá-la, e o paymaster da SSP paga o aluguel. Seu cofre reembolsa o paymaster dentro da mesma transação, e é por isso que essa primeira transferência para um destinatário novo custa cerca de 0,0025 SOL a mais que uma repetida para a mesma pessoa. "Idempotente" é a palavra importante: se a conta já existir, a instrução é bem-sucedida e não faz nada, em vez de derrubar a transferência inteira.
Repare que essa instrução de criação fica fora da proposta multisig. Criar a conta de token de outra pessoa não move seus fundos e não precisa de autorização do seu cofre, então não pertence à parte que seus dois dispositivos assinam. O reembolso, que move seus fundos, fica dentro da proposta.
O que a SSP suporta de fábrica
A SSP vem com SOL nativo, o mint oficial de USDC da Circle e o FLUX na Solana. Qualquer outro token SPL que apareça no seu cofre é resolvido e exibido ao lado deles.
Vale enunciar com clareza um limite deliberado: as transferências Solana da SSP são construídas sobre o programa SPL Token clássico. Tokens emitidos sob o Token-2022, o programa mais novo com transfer hooks, transferências confidenciais e outras extensões, não fazem parte do caminho de envio hoje. É uma decisão de escopo, não um descuido: extensões do Token-2022 podem mudar o que uma transferência faz, e dar suporte a elas significa auditar cada extensão contra as garantias de decodificação no dispositivo descritas abaixo.
Como uma transferência de token é realmente montada
Quando você envia um token SPL pela SSP, a transação assinada contém, em ordem:
- Criar a ATA do destinatário se necessário — idempotente, paga pelo paymaster, fora da proposta.
- TransferChecked — move o saldo da conta de token do seu cofre para a do destinatário, autorizado pelo cofre.
- Reembolsar o paymaster — uma transferência simples de SOL do seu cofre, dentro da proposta.
Tudo isso pousa como uma única transação atômica. Não há passo de aprovação separado, nem proposta pendente parada on-chain, nem estado em que a conta do destinatário foi criada mas a transferência não aconteceu. Ou executa tudo, ou nada.
A conta de origem é a própria ATA do seu cofre — derivada do mesmo jeito determinístico, com o endereço de programa do cofre como dono. Como o cofre é um endereço derivado de programa e não um par de chaves, a derivação permite explicitamente um dono fora da curva ed25519. Se quiser o detalhe de fundo sobre por que o endereço do cofre funciona assim, o multisig Solana auto-iniciável cobre o assunto.
As casas decimais fazem parte da assinatura
Esta é a parte que vale desacelerar, porque é onde um token pode mentir para você.
Um mint declara quantas casas decimais o seu token usa. USDC usa seis; muitos tokens usam nove; não há regra. Se uma carteira exibe "100 USDC" mas monta uma transferência com um número de unidades brutas que assume as casas decimais erradas, você pode enviar mil vezes demais e não ver nada de errado na tela.
A SSP usa TransferChecked em vez da instrução de transferência simples. A diferença é que o TransferChecked embute o endereço do mint e o byte de casas decimais diretamente nos dados da instrução assinada. Daí decorrem três verificações distintas:
- Sua extensão decodifica os bytes e os compara com o que está exibindo.
- O SSP Key decodifica os mesmos bytes de forma independente no seu celular e os compara com os metadados do token fornecidos pela extensão.
- O programa SPL Token on-chain compara as casas decimais da instrução com as casas decimais reais do mint e rejeita a transação se diferirem.
A terceira verificação é a que não se contorna com conversa. Um mint que declare casas decimais diferentes das que tem não produz uma transferência errada — produz uma transação que falha.
Recebendo tokens
Receber é mais simples, com uma ressalva. Dê ao remetente o seu endereço de carteira — aquele que a SSP mostra na tela de receber — e não um endereço de conta de token. Seja o que for que ele esteja enviando, a ATA correta é derivada do seu endereço e do mint, e a carteira do remetente a cria se preciso.
Se o seu cofre nunca teve aquele token, a conta não existirá até a primeira transferência chegar, e o aluguel dela é pago por quem envia para você. Isso é normal e não exige nada de você. Significa, porém, que um explorador de blocos não mostrará conta de token alguma para um token que lhe prometeram mas que ainda não chegou — é a conta ainda não existir, não uma transferência perdida.
Armadilhas comuns
Enviar para um endereço de conta de token em vez de um endereço de carteira. Alguns exploradores exibem a ATA com destaque. Mandar um token para uma conta de token em vez de para o dono dela é um jeito bem conhecido de perder fundos na Solana. A SSP espera o endereço de carteira do dono e deriva o resto.
Supor que um token desconhecido é seguro porque aparece na sua carteira. Qualquer um pode criar um mint e enviá-lo a você, e mints podem ter nomes que imitam tokens reais. Um token aparecer no seu cofre não é um aval. Verifique o endereço do mint contra uma fonte oficial antes de tratar um saldo como valor real.
Esperar aprovações no estilo Ethereum. Tokens SPL têm um mecanismo de delegado, mas o padrão de permissão permanente que torna as aprovações ERC-20 um risco recorrente não é como a maioria das aplicações Solana é construída. Se você vem do Ethereum, aprovações de tokens: as permissões que você não para de conceder explica o hábito que você está desaprendendo, e Ethereum na SSP traz a comparação.
Esquecer o acréscimo do primeiro envio. Os ~0,0025 SOL extras numa primeira transferência para um destinatário novo são aluguel, não taxa que a SSP recolhe. Ficam na conta de token do destinatário e são recuperáveis por ele caso um dia a feche.
Para a mecânica passo a passo de uma transferência real, veja enviando Solana com a SSP. Para entender como a SSP mantém o cofre subjacente num multisig 2-de-2 sem criador, comece por Solana na SSP.
