O suporte a Solana na SSP passa do devnet para a mainnet. A mesma autocustódia 2-de-2 que você usa em Bitcoin e Ethereum agora cobre SOL e tokens SPL reais, assinados pelo próprio programa multisig da SSP, em execução na mainnet da Solana em SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r.
Lançamos Solana primeiro no devnet, deliberadamente, na SSP Wallet v1.39.0. Tudo o que veio depois foi para a parte difícil de desfazer quando há dinheiro real envolvido: o programa on-chain, a forma como seu dispositivo o verifica e a garantia de que o código rodando na mainnet é o código que publicamos.
Sem criador, sem coordenador
Multisig na Solana normalmente começa com alguém criando. O Squads V4 — a opção madura, amplamente usada, e aquela com que vale a pena se comparar — cria uma carteira com uma instrução on-chain que exige duas coisas: um criador e uma create_key aleatória, nova e de uso único. O endereço do cofre deriva dessa chave aleatória, o que significa que o endereço não existe e não pode receber fundos até alguém executar a transação de criação — e que nesse momento há uma parte presente como criadora.
O programa da SSP não tem uma etapa de criação nesse formato. O endereço do seu cofre é uma impressão digital do conjunto ordenado de membros junto com o limiar de aprovação — nada mais. Quem souber quem são os membros e quantos precisam aprovar pode calcular o endereço offline, antes que qualquer coisa toque a cadeia. O registro é sem permissão: o programa apenas confere que os membros apresentados de fato produzem o hash do endereço declarado, de modo que registrar não muda nada sobre quem pode gastar.
O resultado é que não há criador em quem confiar, nenhum registrador privilegiado e nenhuma chave de administrador. O gasto é condicionado unicamente à verificação de limiar dentro de execute_transaction — o endereço é a regra, e não um registro de quem o configurou.
É essa propriedade que faz seus dois dispositivos se comportarem na Solana como em todo o resto da SSP. Se o modelo é novo para você, o que é de fato o multisig 2-de-2 é o ponto de partida; a implementação da SSP na Solana entra no programa em si, e SSP versus Squads V4 é a comparação completa.
Seu dispositivo não confia no nosso relay
As transações da Solana são opacas de um jeito que as do Bitcoin não são: o que uma transação faz vive em dados de instrução que uma carteira precisa decodificar antes de conseguir lhe dizer qualquer coisa verdadeira.
Por isso a SSP decodifica no seu dispositivo, byte a byte, usando a biblioteca de código aberto @runonflux/solana-multisig. Destinatários, valores e mints de tokens são verificados contra os bytes brutos da transação em vez de aceitos a partir do que o relay envia. Se os dois discordarem, a assinatura é bloqueada por completo — uma divergência ali indica ataque ativo, não falha de exibição.
Esse trabalho saiu antes da mainnet na v1.40.0, junto com um teto independente para o reembolso de taxas do paymaster e uma lista de instruções permitidas nas aprovações. A mainnet liga um decodificador que já está em produção no devnet há semanas.
Builds que você pode verificar
O programa de mainnet é compilado com uma toolchain fixada e builds verificáveis, de modo que o bytecode implantado naquele endereço pode ser reproduzido a partir do código publicado. Você não precisa acreditar na nossa palavra sobre o que está rodando — pode reconstruir e comparar.
É a mesma postura das builds determinísticas da carteira: uma afirmação de segurança vale apenas o quanto você consegue conferi-la por conta própria.
Como começar
Atualize a SSP Wallet e o SSP Key para as versões mais recentes e ative Solana no seletor de cadeias. Com a sincronização em lote da v2, você pode habilitá-la junto de quaisquer outras cadeias com uma única aprovação no seu Key.
A partir daí, Solana se comporta como qualquer outra cadeia na SSP: aparece no total do seu Portfolio, os envios seguem o mesmo fluxo compor → revisar → aprovar com o endereço completo do destinatário à vista, e cada transação é coassinada pelos seus dois dispositivos.
