Solana na SSP

A Solana é rápida, barata e, cada vez mais, o lugar por onde as stablecoins realmente circulam. É também a rede em que o multisig em autocustódia historicamente foi mais difícil de acertar — não porque a criptografia seja complicada, mas porque o modelo de contas da Solana transforma «um endereço controlado por várias partes» em um objeto bem mais estranho do que ele é no Bitcoin.

A SSP guarda SOL e tokens SPL no mesmo multisig 2-de-2 que você já usa para Bitcoin e Ethereum: uma chave na extensão do navegador, outra no seu celular, ambas exigidas em cada transação. Este artigo explica o que isso significa especificamente na Solana — como o endereço é derivado, quem paga as taxas, o que seus dispositivos verificam e quais partes realmente diferem das redes que você já conhece.

O que é a Solana da cadeira de quem faz autocustódia

A Solana é uma única máquina de estados global que processa transações em paralelo em vez de uma por vez. Para quem guarda as próprias chaves, três propriedades importam mais do que a manchete sobre throughput.

Primeiro, tudo é uma conta. Seu saldo, o mint de um token, o código de um programa e os dados que esse programa armazena vivem todos em contas com endereço e dono. Segundo, contas custam aluguel: para existir on-chain, uma conta precisa manter um saldo mínimo de SOL proporcional ao seu tamanho. Esse depósito é reembolsável quando a conta é fechada, mas é dinheiro de verdade que precisa vir de algum lugar. Terceiro, transações expiram rápido — uma transação Solana comum referencia um blockhash recente e deixa de valer cerca de um minuto depois.

Cada um desses pontos tem consequência direta para a assinatura em dois dispositivos, e cada um é tratado explicitamente na SSP em vez de ser disfarçado. A documentação oficial da Solana é a fonte primária sobre o modelo de contas e aluguel, se você quiser a versão crua.

Um endereço sem criador

Na maioria dos desenhos de multisig da Solana, a carteira precisa ser criada. Alguém envia uma transação que a estabelece, e o endereço resultante depende de entradas escolhidas durante essa transação — normalmente uma chave aleatória de uso único. O efeito prático é que o endereço não existe até que um criador o traga ao mundo, e não pode receber fundos antes disso.

O programa on-chain da SSP funciona de outro jeito. O endereço do seu cofre é uma impressão digital do conjunto ordenado de membros mais o limiar de aprovação, e nada além disso. Qualquer pessoa que saiba quem são os membros e quantas aprovações são necessárias pode calcular o endereço offline, antes de qualquer coisa tocar a rede. O registro é sem permissão: o programa só confere que os membros que você apresenta realmente resultam no hash do endereço declarado, de modo que registrar não muda nada sobre quem pode gastar.

É por isso que não há criador em quem confiar, nem registrador privilegiado, nem chave de administrador. O gasto é regido apenas pela checagem de limiar dentro do programa. Se quiser o quadro completo, por que endereços multisig na Solana são difíceis trata do problema de fundo, o multisig Solana auto-iniciável trata do programa, e SSP versus Squads V4 é a comparação lado a lado.

Se o próprio modelo 2-de-2 for novidade para você, comece por o que é multisig 2-de-2.

Por que dois dispositivos precisaram de um nonce durável

Eis o problema criado pela expiração. Sua extensão monta e assina uma transação. Seu celular precisa aprová-la depois. Se você sair da sala, almoçar e voltar, o blockhash que a transação referenciava morreu faz tempo e tudo precisa ser refeito.

A SSP resolve isso com uma conta de nonce durável derivada do seu endereço multisig. Em vez de um blockhash recente, a transação referencia um nonce que só avança quando a transação de fato é confirmada. A janela de assinatura deixa de ser um cronômetro. Você pode aprovar no celular minutos ou horas depois e a transação continua válida — mas ainda assim só pode ser usada uma vez, porque executá-la faz o nonce avançar.

A conta de nonce é criada no primeiro envio, e é uma das duas contas cujo aluguel aparece no custo desse primeiro envio. Nonces duráveis e assinatura em dois dispositivos vai mais fundo.

Quem paga as taxas

Na Solana, a conta que paga a taxa de uma transação é o fee payer, e ela precisa assinar. Isso cria um problema desconfortável de partida para um multisig recém-criado: o cofre precisa de SOL para pagar a transação que moveria o seu SOL, e as contas que exigem aluguel ainda não existem.

A SSP usa um paymaster. O relay da SSP opera uma conta que assina como fee payer, adianta a taxa de rede e qualquer aluguel, e é reembolsada pelo seu cofre dentro da mesma transação. Não há passo separado, não há crédito concedido e não há como o reembolso acontecer sem as suas duas assinaturas — ele viaja junto na proposta que seus dispositivos aprovam.

Duas consequências valem ser internalizadas:

• Você não precisa pré-financiar um endereço com SOL para o gás. Receba SOL, envie SOL. É no primeiro envio que as contas são criadas.
• Seu primeiro envio custa mais do que os seguintes. O primeiro envio paga o aluguel permanente da conta multisig e da conta de nonce; envios posteriores pagam pouco mais que a taxa de rede. Os números exatos estão no artigo de taxas desta série.

Se paymasters como conceito não lhe são familiares, patrocínio de gás e paymasters, explicados cobre o padrão geral — a SSP já usa a mesma ideia nas redes EVM, como descrito em Ethereum na SSP.

O que você pode guardar

A Solana na SSP suporta SOL nativo e tokens SPL. De fábrica isso inclui o mint oficial de USDC da Circle e o FLUX na Solana, e a SSP resolve outros tokens SPL que encontrar no seu cofre.

A distinção que costuma confundir: na Solana você não guarda um token no seu endereço principal. Cada token vive na sua própria conta de token associada, de propriedade do seu endereço, uma por mint. Essa conta também precisa de aluguel, e é por isso que enviar um token SPL para alguém que nunca teve aquele token custa um pouco mais: você está pagando para trazer a conta de token dessa pessoa à existência. A SSP a cria automaticamente como parte da transferência em vez de falhar com um erro, e o artigo desta série sobre contas de token detalha o funcionamento.

O que seus dispositivos checam antes de você assinar

Transações Solana são opacas de um jeito que as do Bitcoin não são. O que uma transação faz mora dentro dos dados de instrução, e uma carteira precisa decodificar esses dados antes de conseguir lhe dizer qualquer coisa verdadeira sobre eles. Uma carteira que simplesmente exibe o que um servidor mandou está pedindo que você confie no servidor.

A SSP decodifica a transação nos seus próprios dispositivos, byte a byte, usando a biblioteca de código aberto @runonflux/solana-multisig. Destinatário, valor e mint do token são lidos dos bytes crus e comparados com o que está sendo exibido. Se divergirem, a assinatura é bloqueada de vez — uma discrepância nesse ponto indica ataque em andamento, não falha de renderização. Em transferências SPL, as casas decimais do token vão embutidas na própria instrução assinada, de modo que um mint que declare decimais diferentes faz o programa on-chain rejeitar a transação.

O mesmo princípio rege o programa: builds de mainnet são reproduzíveis a partir do código publicado, então o bytecode implantado em SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r pode ser reconstruído e comparado de forma independente. Uma alegação de segurança vale exatamente o que vale a sua capacidade de conferi-la sozinho.

Como começar

Atualize o SSP Wallet e o SSP Key para a versão mais recente e ative a Solana no seletor de redes. Com a sincronização em lote da v2, dá para ativá-la junto de quaisquer outras redes com uma única aprovação no celular. Se você ainda não configurou a SSP, configurar sua primeira carteira SSP é o ponto de partida.

Daí em diante a Solana se comporta como qualquer outra rede na SSP: entra no total do seu portfólio, os envios seguem o mesmo fluxo de compor → revisar → aprovar com o endereço do destinatário inteiro na tela, e toda transação é coassinada pelos seus dois dispositivos. O anúncio do lançamento na mainnet conta o que foi entregue e quando.