Simulação de transações: o que uma transação vai fazer antes de você assinar

O endereço está certo. O valor está certo. Você conferiu os dois. E a transação continua não sendo o que você pensa.

Isso não é hipótese. É o formato comum da maioria das perdas em cripto que envolvem uma pessoa cuidadosa. Ninguém a convenceu a mandar dinheiro para um estranho. Ela aprovou algo cujas partes visíveis estavam todas corretas e cujas consequências estavam inteiramente em outro lugar — numa permissão de gasto de tokens, numa chamada de contrato, num caractere de um endereço que ela já tinha visto cem vezes.

A simulação é a tentativa de fechar essa lacuna: mostrar a você os efeitos de uma transação em vez do seu conteúdo, antes que sua assinatura a torne real.

A lacuna entre o que você quis dizer e o que está assinando

Uma transação não é uma frase. São bytes.

Quando esses bytes são uma transferência simples, a lacuna entre o que dizem e o que fazem é pequena: um endereço, um valor, uma taxa. Quando são uma chamada de contrato, a lacuna pode ser enorme. approve parece uma permissão. É um direito permanente de outro endereço movimentar seus tokens, e sob o padrão ERC-20 nada na chamada exige limitar quanto nem por quanto tempo. Uma única aprovação, assinada uma vez, pode ser drenada meses depois.

A interface que você está olhando na hora de assinar precisa traduzir esses bytes em uma frase. Essa tradução é a superfície de ataque. Se ela for produzida por quem quer a sua assinatura, pode dizer qualquer coisa.

Um ensaio, não uma promessa

Simular significa executar a transação contra o estado atual da rede sem transmiti-la, e registrar o que muda.

No SSP Enterprise isso acontece quando uma proposta é criada, antes de qualquer assinatura. A simulação é montada a partir do que o construtor da proposta produziu — os destinatários, os valores, o contrato do token e os dados de chamada que a própria SSP montou — nunca a partir de hex assinado bruto entregue por um cliente. Ela roda somente em leitura. Três motores cobrem as diferentes famílias de redes:

• Redes EVM executam uma chamada somente-leitura contra um nó e leem de volta as mudanças de saldo resultantes e a chamada decodificada.
• Redes UTXO não precisam de nó nenhum. As entradas e saídas já são conhecidas, então o antes-e-depois é aritmética sobre as moedas selecionadas, e os destinatários são classificados como troco que volta para você ou genuinamente externos.
• Solana desserializa a transação não assinada que o construtor produziu e roda o próprio simulateTransaction da rede, com a verificação de assinaturas desligada, e depois lê no resultado os saldos de tokens do cofre antes e depois.

O que volta é uma prévia: qual era o saldo de cada ativo antes, qual será depois e — na EVM — o que a chamada realmente é, decodificada em um método e seus argumentos.

Duas coisas que ela não é. Não é uma garantia: o estado da rede se move, e uma simulação rodada no momento da proposta é uma foto da rede como ela estava então. E não é uma trava. Que é a metade mais interessante do projeto, e voltaremos a isso.

Catorze coisas que vale a pena te dizer

Uma prévia que só mostra números ainda pede que você mesmo enxergue o problema. Por isso a prévia vem acompanhada de avisos, e há catorze deles, em quatro níveis de gravidade.

Aprovações — a categoria que esvazia mais carteiras. Uma permissão ilimitada ou sem limite é crítica. Qualquer aprovação de gasto diferente de zero para um endereço que não está na sua lista de permitidos é alta. E aprovar uma conta comum, de pessoa, em vez de um contrato é alta, porque praticamente não existe motivo legítimo para isso: contratos gastam permissões, pessoas não.

Destinatários — um destinatário que não está nos contatos da sua organização nem na whitelist do cofre é sinalizado. Assim como um para o qual seu cofre nunca enviou antes. Nenhum dos dois está errado por si só. Ambos merecem uma segunda leitura.

Risco de contrato — um contrato de destino cujo código-fonte não é verificado, um implantado nos últimos sete dias, valor nativo sendo enviado a um contrato de qualquer forma, e qualquer endereço que um provedor sinalize como francamente malicioso.

Execução — a transação revertendo na simulação, o que significa que vai falhar na rede e desperdiçar a taxa. Ou a saída simulada não batendo com os valores que a proposta declara: o cofre perdendo mais, ou menos, do que a tela diz.

Degradação — e, claramente rotulado, o caso em que a simulação não pôde rodar. Um nó inalcançável produz "indisponível", não silêncio nem um atestado de saúde inventado.

A distinção entre essas gravidades importa mais que a contagem. Crítica e alta falam de uma transação que provavelmente não é o que aparenta. Média e informativa falam de uma transação incomum, coisa que transações legítimas ocasionalmente são.

Envenenamento de endereço: o ataque que vence gente cuidadosa

Um aviso merece uma seção própria, porque mira exatamente o hábito que a maior parte dos conselhos de segurança recomenda.

O envenenamento de endereço funciona assim. Um atacante manda ao seu cofre uma transação minúscula ou de valor zero a partir de um endereço fabricado para compartilhar os seis primeiros e os quatro últimos caracteres de um endereço com o qual você já negocia. Nada é roubado. Nada é sequer realmente feito. A transação existe para que o endereço sósia apareça no seu histórico.

Mais tarde — dias depois, quando você paga a mesma contraparte de novo — você copia o endereço do seu próprio histórico de transações, como gente cuidadosa faz em vez de redigitar. Você o confere como gente cuidadosa confere: os primeiros caracteres, os últimos caracteres. Ambos batem. O meio não, e o meio é para onde o dinheiro vai.

A SSP compara cada destinatário de uma proposta com os endereços que seu cofre já conhece, usando exatamente a comparação de prefixo e sufixo que o olho humano faz, e levanta um aviso crítico nomeando o endereço imitado. A mesma checagem roda no sentido contrário sobre o histórico de entrada, de modo que um endereço envenenado é marcado quando chega, e não só quando você está prestes a usá-lo.

O motivo para conhecer esse ataque mesmo que você nunca use a SSP: o hábito de verificação que barra todos os outros ataques de endereço é justamente o que este ataque foi construído para derrotar. Compare endereços inteiros, ou não compare nada.

Por que os avisos são calculados no servidor — e ainda assim não bloqueiam nada

O conjunto de avisos é decidido no servidor, usando os contatos da sua organização e a whitelist do cofre como fonte da verdade. Isso é deliberado: se um cliente pudesse decidir o que conta como permitido, um cliente comprometido poderia decidir em silêncio que tudo conta.

E ainda assim nada disso pode parar uma transação. A simulação nunca condiciona assinatura nem transmissão. Um provedor que dá erro, estoura o tempo ou não alcança um nó devolve "indisponível", e a proposta continua plenamente assinável. Todo o subsistema é isolado contra falhas para que uma quebra na prévia nunca possa encalhar uma proposta.

Isso vai soar como uma escolha estranha, então vale enunciar o raciocínio com clareza. Uma prévia que pode bloquear é uma prévia que pode ser levada a bloquear — derrubando um nó, produzindo um falso crítico, por qualquer uma das mil maneiras pelas quais software dá errado. Fundos que não podem se mover porque um serviço consultivo está doente são fundos que você perdeu em parte. É o limiar do multisig que protege o dinheiro; a simulação está ali para informar os humanos que seguram as chaves. O que realmente barra uma transação é a versão longa desse argumento.

Quando o servidor e o seu aparelho discordam

Tudo acima é a leitura do servidor. Seu aparelho faz a dele.

Quando o SSP Wallet mostra a você uma proposta para assinar, ele decodifica os bytes por conta própria e exibe o que ele encontrou — não o resumo do servidor. Depois compara os dois. Se a chamada decodificada do servidor implica um conjunto de destinatários diferente do que o aparelho derivou, o aparelho levanta um aviso crítico próprio de divergência e rebaixa visualmente a prévia do servidor.

A decodificação do aparelho é a que vale. A checagem é deliberadamente conservadora: uma simulação do servidor ausente ou pendente é uma degradação, não uma contradição, e não é sinalizada como tal. Ela também só se aplica a redes EVM, onde o servidor chega a produzir uma chamada decodificada; em redes UTXO não há com o que comparar, e a decodificação própria do aparelho simplesmente se sustenta sozinha.

Essa é a propriedade que vale levar, seja qual for sua carteira. Uma segunda opinião só vale alguma coisa se vier de um lugar que não poderia ter sido comprometido pelo mesmo ato que comprometeu o primeiro. Dois resumos do mesmo servidor são um resumo só.

Ler uma faixa de risco sem aprender a ignorá-la

Avisos funcionam até virarem papel de parede. Alguns poucos hábitos os mantêm úteis.

Leia a gravidade primeiro, o detalhe depois. Crítico e alto merecem uma parada. Um aviso médio ou informativo num primeiro pagamento a um fornecedor novo é o sistema funcionando certo, não motivo de preocupação.

Trate qualquer aviso de aprovação como parada total. Transferências movem o que dizem mover. Aprovações concedem um direito que sobrevive à transação. Se você não pretendia conceder uma permissão permanente, a resposta é não.

Acredite no aparelho, não na tela. Se os dois discordam, o telefone na sua mão é o que roda em um hardware que um atacante teria de comprometer separadamente.

Não trate "indisponível" como "está tudo bem". Significa que ninguém conferiu. Isso é motivo para você olhar com mais atenção, especialmente num pagamento grande ou incomum.

Tudo aqui é sobre o instante anterior a uma assinatura. Para o que acontece depois — quem pode assinar, quantos são necessários e quais operações exigem os dois aparelhos de novo — comece por configurar seu primeiro cofre empresarial e ações críticas e a reassinatura. E para os padrões de ataque em torno dos quais esses avisos foram moldados, ataques de phishing mirando usuários de cripto cobre a metade humana do problema.