Por que Transações Solana Falham: 5 Correções

Este guia prático foca em cinco correções para transações Solana falhadas e passos que podem prevenir falhas repetidas.

Transações Solana falham por cinco motivos:

1. Blockhash expirou antes da rede confirmar a transação
2. Taxa de prioridade foi muito baixa para a demanda atual da rede
3. Tolerância a Slippage foi violada em um swap de DEX
4. Orçamento de unidades de computação acabou no meio da execução
5. O nó RPC conectando sua carteira à rede estava sobrecarregado

✅ Seus Fundos Estão Seguros

Uma transação Solana falhada não deduz tokens da sua carteira. Seu SOL e tokens permanecem exatamente onde estavam. No máximo, você pode perder uma pequena taxa de rede base, tipicamente menos de $0,001. Seu valor de swap, valor de transferência ou preço de mint NFT não foi cobrado.

Nesta página:

• Por que Transações Solana Falham: O Que Está Acontecendo
• As 5 Causas Raiz de Falhas em Transações Solana
• Mensagens de Erro Solana Decodificadas
• Como Corrigir uma Transação Solana Falhada
• Falhas Específicas da Plataforma
• Solana Está Fora do Ar? Como Verificar o Status da Rede Status
• Você Ainda Paga Taxas em uma Transação Falhada?
• Checklist Pré-Transação
• Perguntas Frequentes
• Resumo: Combine Seu Erro com a Correção Certa

Por que Transações Solana Falham: O Que Está Acontecendo

Ver uma transação Solana falhar enquanto um movimento de preço se desenrola é frustrante, especialmente quando a mensagem de erro não informa nada útil. Se seu swap, mint ou transferência falhou em Jupiter, Raydium, Orca ou Magic Eden, a causa é quase sempre uma de cinco coisas, e cada uma tem uma correção específica.

Em todo o ecossistema de finanças DeFi (descentralizadas) da Solana, incluindo swaps de tokens, provisão de liquidez, protocolos de empréstimo e mints NFT, falhas de transação carregam consequências financeiras reais porque os preços se movem em milissegundos. A arquitetura da Solana a torna mais rápida e barata do que a maioria das blockchains, mas também cria modos de falha que usuários familiarizados com Ethereum ou outras redes não esperariam. Diferente de redes onde transações lentas esperam em uma fila, Solana usa um protocolo de encaminhamento de transações chamado Gulf Stream que descarta transações que não consegue processar imediatamente. Não há fila. Transações falhadas exigem resubmissão ativa com as configurações corretas.

Este guia abrange falhas em sua carteira de criptomoedas (como Phantom ou Backpack), Jupiter, Raydium, Orca e Magic Eden. Se você suspeita que a própria Solana está tendo problemas hoje, pule para a seção de status da rede antes de solucionar suas configurações.

As 5 Causas Raiz de Falhas em Transações Solana

Falhas de transação Solana se dividem em duas categorias: falhas em nível de rede (vencimento de blockhash, congestionamento, nós RPC sobrecarregados) e rejeições em nível de programa do Smart Contract, ou programa, que executa o aplicativo que você está usando. Erros de tolerância a Slippage e erros de orçamento de computação são rejeições em nível de programa; vencimento de blockhash e taxa de prioridade insuficiente são em nível de rede. A correção depende de qual tipo você está enfrentando.

Solana usa um sistema de contagem de tempo chamado Proof of History, que gera uma sequência criptográfica que os validadores usam para concordar com o tempo sem comunicar timestamps uns aos outros. Cada slot nesta sequência produz um blockhash, um código semelhante a um timestamp embutido em cada transação para provar que a transação é atual. Essa arquitetura baseada em slots cria as janelas de vencimento únicas da Solana e é o que distingue seus modos de falha de outras blockchains.

Causa 1: Blockhash Expirou

Cada transação Solana carrega um blockhash, que prova que a transação foi criada recentemente. Se este blockhash expirar antes da rede confirmar a transação, Solana a descarta inteiramente.

Cada blockhash é válido por aproximadamente 150 slots, o que equivale a cerca de 60 a 90 segundos em condições normais. Durante o congestionamento da rede, os validadores ficam para trás no processamento, o que significa que as transações expiram mais rápido em termos relativos. As mensagens de erro que você verá são Blockhash not found ou Transaction expired.

Solana usa Gulf Stream em vez de uma fila de transações tradicional, o que significa que uma transação descartada não volta para a fila para esperar. Ela desaparece. Você deve ressubmitir ativamente iniciando a transação novamente de sua carteira ou interface DEX. A carteira busca automaticamente um blockhash fresco na nova submissão. Para o procedimento de ressubmissão, veja Correção 3: Ressubmeter com um Blockhash Fresco.

⚠️ Nota do Desenvolvedor

Sempre busque um blockhash fresco com connection.getLatestBlockhash('confirmed') em cada tentativa de retentativa. Nunca reutilize um blockhash entre as tentativas de retentativa. Use níveis de commit confirmed ou finalized em ambientes de produção, não processed, para evitar estados desatualizados. Detecte se uma transação foi descartada ou processada chamando getSignatureStatuses antes de cada retentativa.

Durante o congestionamento da rede, os validadores da Solana, os computadores que processam suas transações, escolhem quais transações lidar primeiro com base nos níveis da taxa de prioridade.

Uma taxa de prioridade é uma gorjeta opcional paga aos validadores, medida em micro-lamports por unidade de computação. Um lamport é igual a 0,000000001 SOL; um micro-lamport é um milionésimo de um lamport. Durante períodos de alto tráfego, como lançamentos NFT populares ou movimentos acentuados do mercado, os validadores processam primeiro as transações com taxas de prioridade mais altas. Transações com taxas de prioridade zero ou insuficientes são descartadas em vez de enfileiradas.

Uma causa relacionada de erros de SOL insuficiente: Solana exige que cada conta mantenha um saldo mínimo chamado limite isento de aluguel para permanecer ativa na rede. Se o saldo da sua carteira cair abaixo deste limite após uma taxa, ou se uma transação criar uma nova conta de token sem SOL suficiente para financiá-la, você verá um erro de Suficiente fundos mesmo quando parecer ter SOL suficiente para a negociação em si. Mantenha um buffer de 0,05 SOL acima do valor da sua transação.

É por isso que ressubmeter a mesma transação sem alterar as configurações muitas vezes falha novamente. Para orientação sobre como definir o nível de taxa correto, veja Correção 1: Aumentar Sua Taxa de Prioridade.

⚠️ Nota do Desenvolvedor

Adicione ComputeBudgetProgram.setComputeUnitPrice(microLamports) como a primeira instrução em sua transação. Consulte getRecentPrioritizationFees() para estimativa dinâmica em vez de usar um multiplicador estático. Os níveis de taxa mudam com a demanda da rede, então valores estáticos se tornam não confiáveis durante picos de congestionamento. Detecte gatilhos de failover monitorando erros HTTP 429 (limite de taxa), 503 (serviço indisponível) e de tempo limite de conexão.

Cada transação Solana roda em um orçamento de processamento chamado unidades de computação, que medem a quantidade de trabalho computacional que a transação exige. Transferências simples consomem muito pouco deste orçamento. Operações complexas, como um swap DEX multi-hop roteando através de três ou quatro pools de liquidez, consomem substancialmente mais.

Se a sua transação esgotar o orçamento da unidade de computação antes de terminar, a Solana a cancelará. Os erros que você verá são Compute budget exceeded ou Program failed to complete.

Antes de enviar sua transação, a Phantom e outras carteiras executam uma verificação prévia chamada simulação de transação, que executa a transação em relação ao estado atual da blockchain sem realmente submetê-la. Se a simulação detectar que as unidades de computação serão esgotadas, ela bloqueia a transação e mostra Transaction simulation failed. A maioria das falhas de simulação indica um problema real com a transação, embora ocasionalmente dados de estado desatualizados causem uma falha falsa em uma transação que, de outra forma, teria sucesso.

Para a maioria dos usuários em interfaces DEX modernas, os limites da unidade de computação são definidos automaticamente. Se você vir um erro de orçamento de computação, use o botão de nova tentativa integrado da DEX antes de tentar ajustes manuais. Para etapas detalhadas, consulte Correção 5: Ajustar o orçamento da unidade de computação.

⚠️ Nota do Desenvolvedor

Adicione ComputeBudgetProgram.setComputeUnitLimit(units) como a primeira instrução na transação. Execute simulateTransaction() primeiro para medir o consumo real da unidade de computação e, em seguida, defina o limite para o consumo real multiplicado por 1,1 como uma margem de 10%. Definir o limite muito baixo causa falhas de InstructionError; defini-lo muito alto desperdiça o orçamento de taxas, mas não causa falhas.

Causa 4: Tolerância de Slippage excedida

A tolerância de Slippage é uma proteção que sua corretora descentralizada (DEX, uma plataforma onde você pode trocar tokens diretamente da sua carteira) define em seu nome. Se o preço de um token se mover mais do que o limite definido entre o momento em que você solicita uma troca e o momento em que ela é executada, o Smart Contract cancela a transação para protegê-lo de um preço pior do que o esperado.

Esta é uma falha de proteção, não uma perda. Seu Saldo principal está seguro; a troca não foi executada. O erro que você verá é Slippage tolerance exceeded.

Falhas de Slippage acontecem com mais frequência em tokens voláteis, pares de trading de baixa Liquidez e durante períodos de alta congestão, quando há um atraso maior entre a cotação do preço e a execução. Se um pool de Liquidez tiver reservas muito baixas, mesmo uma tolerância de slippage de 5% pode não ser suficiente porque o pool não pode acomodar o tamanho da sua negociação a qualquer preço razoável. Nesse caso, tente reduzir o valor da troca ou mudar para um par de trading diferente.

Jupiter, Raydium e Orca são as DEXes onde essa falha é encontrada com mais frequência. Para instruções de ajuste passo a passo, consulte Correção 2: Ajustar sua tolerância de Slippage.

Causa 5: Nó RPC sobrecarregado

Sua carteira Solana se conecta a um servidor chamado nó RPC para enviar transações. Pense nele como a agência de correios que passa sua transação para a rede de validadores. Toda vez que você clica em confirmar na Phantom ou Backpack, a carteira envia sua transação para um nó RPC, que a encaminha para os validadores.

O Endpoints de RPC público gratuito da Solana tem taxa limitada e é frequentemente sobrecarregado durante períodos de alta demanda. Durante um lançamento Popular de NFT ou um movimento brusco do mercado, os nós RPC públicos recebem muito mais envios do que podem processar e descartam transações antes mesmo que elas cheguem aos validadores. Quando isso acontece, você pode ver Unable to confirm transaction ou sofrer falhas silenciosas sem nenhuma mensagem de erro.

Mudar para um provedor de RPC dedicado, como Helius ou QuickNode, ambos os quais oferecem planos gratuitos, dá às suas transações um caminho mais confiável para a rede. Para etapas sobre como mudar seu RPC, consulte Correção 4: Mudar para um melhor Endpoints de RPC.

⚠️ Nota do Desenvolvedor

Mantenha uma lista de Endpoints de RPC de reserva na configuração da sua aplicação. Implemente a lógica de failover automático quando o Endpoints primário retornar erros ou tempo esgotado. Use o WebSocket signatureSubscribe para monitoramento de confirmação de transação em vez de polling HTTP com getSignatureStatuses, pois as assinaturas de WebSocket são mais rápidas e confiáveis sob carga.

Mensagens de erro da Solana decodificadas: O que cada uma significa

As mensagens de erro de transações da Solana com falha aparecem no registro de atividade da sua carteira (Phantom ou Solflare), no Solana Explorer (explorer.solana.com) ou no Solana FM (solana.fm). Para procurar uma transação específica com falha, copiar a assinatura da transação do histórico de transações da sua carteira e cole-a em qualquer explorador. Uma transação com falha mostra um status de erro vermelho com o código de erro específico.

Antes de enviar qualquer transação, a Phantom executa uma simulação para prever se ela terá sucesso. Se essa verificação prévia falhar, a Phantom mostra Transaction simulation failed e bloqueia o envio. A maioria das falhas de simulação indica um problema real com suas configurações, mas ocasionalmente dados desatualizados causam uma falha falsa. Nesse caso, atualizar a página e reenviar uma vez é apropriado.

Como corrigir uma transação Solana com falha

Lista de verificação de correção rápida (comece com a Correção 1 se não tiver certeza de qual se aplica):

1. Aumente sua taxa de prioridade para Rápido ou Turbo e reenvie
2. Ajuste a tolerância de slippage em 0,5% a 1% e reenvie
3. Reenvie com um novo blockhash (aguarde 5 segundos e inicie a partir da DEX novamente)
4. Mude para um Endpoints de RPC dedicado nas configurações da sua carteira
5. Verifique o status da rede Solana em status.solana.com antes de tentar novamente se suspeitar de congestão

Uma taxa de prioridade insuficiente causa a maioria das transações com falha durante períodos de negociação ativos, portanto, a Correção 1 é o ponto de partida certo quando você não tem certeza.

Correção 1: Aumentar sua taxa de prioridade

Aumentar sua taxa de prioridade é a correção mais eficaz para falhas em transações durante períodos de congestionamento. Isso sinaliza aos validadores para processarem sua transação antes de envios com taxas menores.

Os níveis de taxas variam de acordo com a demanda da rede. Use o recurso de estimativa automática da sua carteira ou verifique o Solana Beach para ver as condições atuais da rede. Não confie em valores específicos de lamports, pois eles mudam rapidamente.

Referência de Nível de Taxa de Prioridade:

Para aumentar a taxa de prioridade no Jupiter (a interface pode variar conforme a versão):

1. Abra o Jupiter em jup.ag
2. Clique no ícone de engrenagem de configurações no painel de swap
3. Selecione Taxa de Prioridade (Priority Fee)
4. Escolha Rápido (Fast) ou Turbo, ou insira um valor Personalizado (Custom)
5. Reenvie seu swap

Para aumentar a taxa de prioridade no Phantom:

1. Abra a carteira Phantom
2. Vá em Configurações
3. Selecione Transações
4. Ajuste a Velocidade da Transação para Alta (High) ou Personalizada (Custom)
5. Retorne ao seu DEX e reenvie

Para Raydium, clique na engrenagem de configurações na interface de swap, selecione Taxa de Prioridade, escolha um nível mais alto e reenvie. A tabela de Falhas Específicas da Plataforma mostra o caminho exato de navegação para cada Plataforma.

⚠️ Nota do Desenvolvedor

Adicione ComputeBudgetProgram.setComputeUnitPrice(microLamports) como a primeira instrução em sua transação. Chame getRecentPrioritizationFees() para obter os percentis de taxas de rede atuais em vez de usar um multiplicador estático. Pagar a mais desperdiça SOL, mas não causa falhas na transação.

Correção 2: Ajuste sua Tolerância de Slippage

Se o seu swap falhou com um erro de tolerância de slippage, a correção é ampliar a faixa de preço aceitável, mas o quanto você a amplia é importante.

⚠️ Aviso Importante

Definir o slippage acima de 3% a 5% em pares de tokens com baixa Liquidez expõe você a ataques sanduíche de MEV, onde bots detectam sua transação pendente e se antecipam a ela para extrair valor. Aumente o slippage gradualmente, não tudo de uma vez.

Para ajustar o slippage no Jupiter (a interface pode variar conforme a versão):

1. Abra o Jupiter e clique no ícone de engrenagem de configurações
2. Selecione Tolerância de Slippage
3. Aumente sua configuração atual em 0,5% a 1% (por exemplo, de 0,5% para 1,5%)
4. Reenvie seu swap

Para Raydium: clique na engrenagem de configurações, selecione Slippage, insira sua porcentagem ajustada e reenvie. Para Orca: clique em Configurações, ajuste a Tolerância de Slippage e reenvie. A tabela de Falhas Específicas da Plataforma mostra o caminho exato de navegação para cada DEX.

Se você estiver usando o Jupiter, verifique se o recurso de Slippage Dinâmico está disponível em sua interface. Este recurso calcula automaticamente o slippage ideal para cada trade com base nas condições atuais do mercado.

Se um token continuar falhando mesmo com 5% de slippage, o problema provavelmente é Liquidez insuficiente no pool, e não a movimentação de preço. Tente reduzir o valor do seu swap ou dividir o trade em transações menores.

Correção 3: Reenviar com um Novo Blockhash

Um Vencimento de blockhash é corrigido pelo reenvio, mas você não pode reenviar o mesmo objeto de transação. Solana exige um novo blockhash em cada envio.

Como a Solana usa Gulf Stream em vez de uma fila de transações tradicional, uma transação descartada não pode ser "destravada". A transação desapareceu. Uma nova transação deve ser criada do zero.

Para usuários finais (Phantom, Jupiter, Raydium):

1. Aguarde de 5 a 10 segundos após a falha
2. Não clique em enviar novamente na mesma tela de confirmação
3. Retorne à interface de swap e inicie a transação novamente desde o início
4. Sua carteira busca automaticamente um novo blockhash quando você reenvia

Antes de reenviar: verifique o Solana Explorer (explorer.solana.com) para confirmar se a transação realmente não teve sucesso. Cole a assinatura da sua transação na barra de pesquisa. Se a transação aparecer como confirmada, não reenvie.

⚠️ Nota do Desenvolvedor

Busque um novo blockhash com connection.getLatestBlockhash('confirmed') antes de cada tentativa de reenvio. Implemente um backoff exponencial: aguarde 1 segundo antes da primeira tentativa, 2 segundos antes da segunda, 4 segundos antes da terceira. Defina um limite máximo de 5 tentativas antes de exibir um erro ao usuário. Use níveis de compromisso confirmed ou finalized, não processed, ao buscar blockhashes em ambientes de produção.

Correção 4: Mudar para um Endpoints de RPC Melhor

O Endpoints de RPC público e gratuito da Solana (api.mainnet-beta.solana.com) possui limite de taxa e é frequentemente sobrecarregado durante períodos de alta demanda, tornando as transações enviadas mais propensas a serem descartadas antes de chegarem aos validadores.

Provedores de RPC dedicados, como Helius e QuickNode, geralmente oferecem maior confiabilidade do que o RPC da Solana Mainnet público durante o congestionamento. Ambos os provedores oferecem planos gratuitos adequados para usuários individuais.

Para mudar o RPC no Phantom (a interface pode variar conforme a versão):

1. Abra a carteira Phantom
2. Vá em Configurações
3. Selecione Configurações do Desenvolvedor
4. Escolha Alterar Endpoints de RPC
5. Insira a URL do seu Endpoints da Helius ou QuickNode
6. Confirme e reenvie sua transação

Para mudar o RPC no Solflare:

1. Abra a carteira Solflare
2. Vá em Configurações
3. Selecione Rede
4. Escolha RPC Personalizado e insira a URL do seu Endpoints
5. Salve e reenvie sua transação

⚠️ Nota do Desenvolvedor

Mantenha uma lista de Endpoints de RPC de reserva na configuração da sua aplicação. Implemente uma lógica de failover automático para que sua aplicação mude para um reserva quando o principal retornar erros ou expirar o tempo limite. Use WebSocket signatureSubscribe para monitoramento de confirmação de transação em vez de polling com getSignatureStatuses, pois as conexões WebSocket são mais rápidas sob carga pesada.

Correção 5: Ajustar o Orçamento da Unidade de Computação

Para usuários finais, a maioria das interfaces de DEX modernas, incluindo Jupiter e Raydium, define limites de unidade de computação automaticamente. Se você vir um erro de Compute budget exceeded, use a função integrada de repetição ou atualização da DEX em vez de ajustar as configurações manualmente.

Se o erro persistir, tente simplificar sua rota de swap. Uma rota direta através de um único pool usa menos unidades de computação do que uma rota complexa de vários saltos através de quatro ou cinco pools. No Jupiter, procure por uma opção de Rota Direta Apenas nas configurações de roteamento.

Se o seu swap falhar consistentemente em um par específico, pode ser uma rota temporariamente com alta demanda. Esperar alguns minutos e reenviar frequentemente resolve o problema sem quaisquer alterações nas configurações.

⚠️ Nota do Desenvolvedor

Adicione ComputeBudgetProgram.setComputeUnitLimit(units) como a primeira instrução na transação. Execute simulateTransaction() primeiro para medir o consumo real da unidade de computação e, em seguida, defina o limite para o consumo real multiplicado por 1.1 como uma margem de segurança de 10%. Definir o limite muito baixo causa falhas de InstructionError; defini-lo muito alto desperdiça o orçamento da taxa sem causar falhas.

Falhas Específicas da Plataforma: Phantom, Jupiter, Raydium e Magic Eden

Os cenários de falha mais comuns na Solana ocorrem de forma diferente dependendo de qual Plataforma você está usando. Verifique a tabela de comparação abaixo para encontrar sua Plataforma e, em seguida, leia a subseção relevante para obter detalhes.

O roteamento multi-hop da Jupiter envia seu swap através de vários pools de Liquidez para encontrar o melhor preço. Cada hop adicional adiciona consumo de unidades de computação e cria outro ponto onde o movimento de preço pode violar a tolerância a slippage.

As duas falhas mais comuns específicas da Jupiter são a tolerância a slippage excedida em pares de tokens voláteis e Falha na simulação da transação devido a uma taxa de prioridade insuficiente. Ambas são corrigidas ajustando as configurações no menu do ícone de engrenagem da Jupiter antes de reenviar.

O seletor de taxa de prioridade embutido da Jupiter oferece opções Normal, Rápida, Turbo e Personalizada. Durante qualquer sessão de negociação ativa, Rápida é a configuração mínima recomendada. Durante um lançamento NFT ou uma forte movimentação de mercado, use Turbo.

Algumas carteiras mais antigas não suportam o formato de transações versionadas da Jupiter. Se você vir um erro no formato da transação em vez de um erro de slippage ou taxa, verifique se o software da sua carteira está atualizado.

Falhas de Swap Raydium e Orca

Falhas de AMM em Raydium e Orca geralmente vêm de alto impacto no preço em pools com Liquidez limitada. O pool não consegue acomodar o tamanho da sua negociação a um preço razoável, mesmo com configurações generosas de slippage.

Antes de confirmar qualquer swap na Raydium ou Orca, verifique a porcentagem de impacto no preço exibida na interface. Se o impacto no preço exceder 2% a 3%, o tamanho da negociação é muito grande para a Liquidez disponível naquele pool. Reduza o valor do seu swap ou divida a transação em dois ou três swaps menores enviados sequencialmente.

Para posições de liquidez concentrada Whirlpool da Orca, o slippage pode ser especialmente sensível. Se um pool concentrado saiu de sua faixa de preço ativa, as transações falharão independentemente da sua configuração de slippage. Nesse caso, tente um pool diferente ou roteie através do agregador da Jupiter, que encontra automaticamente caminhos alternativos.

Falhas de Mint Magic Eden e NFT

Falhas de mint NFT na Magic Eden diferem de falhas rotineiras de DEX porque o problema não são suas configurações. A questão é a submissão simultânea de milhares de transações durante uma janela de lançamento estreita, que sobrecarrega a rede e faz com que os validadores descartem transações com taxa de prioridade baixa antes que possam ser processadas.

Mints de alta demanda usando programas Candy Machine criam competição extrema. Bots submetem centenas de transações por segundo, saturando tanto o RPC público quanto a fila de validadores.

Protocolo de três etapas para um mint bem-sucedido durante um lançamento de alta demanda:

1. Antes da janela de mint abrir, defina sua taxa de prioridade para Turbo ou a configuração máxima disponível na sua carteira
2. Mude do RPC público da Solana para um provedor dedicado como Helius ou QuickNode (tiers gratuitos são suficientes)
3. Tenha a página de mint totalmente carregada e sua conexão de carteira pré-aprovada; envie a transação imediatamente quando o mint abrir, não após a página recarregar

Seu principal de SOL é retornado automaticamente se uma transação de mint falhar. Apenas a pequena taxa de rede, aproximadamente 0,000005 SOL, é consumida. Alguns projetos também usam mecanismos de lista de permissões e Candy Guards, então se as transações falharem consistentemente mesmo com as configurações corretas, confirme que você se qualifica para a fase atual de mint.

A Solana Está Fora do Ar? Como Verificar a Liquidez da Rede

A maioria das falhas de transação na Solana não é causada por uma interrupção da rede. Elas resultam de configurações do lado do usuário ou congestionamento temporário da rede. Interrupções reais, onde a rede para completamente, são raras e anunciadas oficialmente.

Verificação de status em três etapas:

1. Vá para status.solana.com, a página oficial de status da rede da Solana, e verifique se há relatórios de incidentes ativos da Solana Foundation.
2. Vá para Solana Beach e verifique a figura de transações por segundo (TPS) em tempo real e o tempo médio de confirmação. Altas taxas de falha durante TPS ativo indicam congestionamento da rede, não uma interrupção.
3. Verifique r/solana ou o Discord da Solana. Se muitos usuários estiverem relatando falhas simultaneamente, a rede está sob congestionamento. Se apenas alguns estiverem, o problema provavelmente está do seu lado.

Você Ainda Paga Taxas em uma Transação Falha na Solana?

Sim, a Solana cobra uma pequena Taxa-base de transação mesmo quando uma transação falha, mas seus tokens e o valor principal do seu swap, transferência ou mint não são deduzidos da sua carteira.

Seus tokens estão seguros. A transação falhou antes de qualquer swap ou transferência ser executada.

A Taxa-base é de aproximadamente 0,000005 SOL por assinatura, o que equivale a uma fração de centavo na maioria dos níveis de preço do SOL. Esta taxa compensa os validadores pelo processamento da tentativa de transação, mesmo quando ela não é bem-sucedida. Se você incluiu uma taxa de prioridade, esse valor também é consumido. A quantidade de tokens que você estava tentando trocar, o SOL que você estava tentando enviar, ou o preço NFT que você estava tentando pagar nunca foram deduzidos.

Uma transação descartada silenciosamente por um nó RPC sobrecarregado antes mesmo de chegar aos validadores não cobra nenhuma taxa, pois não há registro dela na blockchain.

Para verificar exatamente quanto de taxa foi cobrado em qualquer transação falha:

1. Copie a assinatura da transação do histórico de transações da sua carteira
2. Cole-a no Solana Explorer ou Solana FM
3. Localize a transação falha, que mostra um status de erro vermelho
4. Verifique o campo Taxa para ver o valor exato de SOL cobrado

Checklist Pré-Transação: Como Prevenir Falhas de Transações na Solana

Seguir este checklist antes de qualquer transação sensível ao tempo leva menos de 60 segundos e elimina as causas mais comuns de falha.

1. Verifique status.solana.com para incidentes ativos antes de qualquer transação durante condições de mercado voláteis
2. Defina sua taxa de prioridade para pelo menos Rápida para qualquer transação durante o horário de negociação ativo; use Turbo para trades sensíveis ao tempo ou mints NFT
3. Verifique se sua tolerância a slippage corresponde à volatilidade do par de tokens: 0,5% para pares estáveis como USDC/USDT, 1% a 2% para tokens de mid-cap, até 3% para small-caps voláteis
4. Confirme se seu Saldo de SOL cobre o valor da transação mais taxas mais um buffer de 0,05 SOL para limiares isentos de aluguel
5. Para transações sensíveis ao tempo ou de alto valor, mude do RPC público da Solana para um provedor dedicado como Helius ou QuickNode (ambos oferecem tiers gratuitos)
6. Para mints NFT: configure sua taxa de prioridade e RPC antes da janela de mint abrir, não durante
7. Para grandes swaps NFT: verifique a porcentagem de impacto no preço antes de confirmar; se o impacto no preço exceder 2% a 3%, reduza o valor do swap ou divida em transações menores
8. Confie no otimizador de taxa embutido da sua Plataforma quando disponível; Jupiter, Raydium e Orca oferecem recomendações de taxa automáticas que se ajustam às condições atuais da rede

⚠️ Nota do Desenvolvedor

Em dApps de produção, implemente estimativa de unidades de computação baseada em simulação em vez de limites estáticos. Consulte getRecentPrioritizationFees() dinamicamente e atualize sua recomendação de taxa a cada submissão de transação. Implemente failover de RPC para que seu aplicativo mude para um endpoint de backup automaticamente. Nunca reutilize blockhashes em tentativas de retentativa.

Perguntas Frequentes: Cinco Correções para Transações Falhas na Solana

Cada resposta abaixo é autocontida. Você não precisa ler o resto deste guia para usar o FAQ.

O que causa o falha de uma transação na Solana?

Transações na Solana falham por cinco motivos: vencimento do blockhash, taxa de prioridade insuficiente, esgotamento do orçamento de unidades de computação, violação da tolerância a slippage ou sobrecarga do nó RPC. Falhas em nível de rede exigem o aumento da sua taxa de prioridade e reenvio. Rejeições em nível de programa exigem o ajuste de parâmetros da transação, como tolerância a slippage ou valor da swap. Consulte As 5 Causas Raiz para uma explicação completa de cada uma.

Você ainda paga taxas em uma transação falha na Solana?

Sim. A Solana cobra uma pequena taxa-base de transação, aproximadamente 0,000005 SOL, mesmo quando uma transação falha, mas seus tokens e o principal da swap não são deduzidos. Transações descartadas silenciosamente por um nó RPC sobrecarregado antes de atingir a rede não cobram nenhuma taxa, pois não deixam registro na blockchain. Consulte Você Ainda Paga Taxas para instruções de verificação.

Quanto tempo antes de uma transação na Solana expirar?

Uma transação na Solana expira após aproximadamente 150 slots, o que equivale a cerca de 60 a 90 segundos em condições normais de rede. Durante o congestionamento, o tempo de vencimento efetivo pode parecer menor, pois os validadores ficam atrasados no processamento. Após o vencimento, a transação é permanentemente descartada e deve ser reenviada do zero.

O que é um blockhash na Solana?

Um blockhash é um código semelhante a um timestamp embutido em cada transação da Solana que prova que a transação foi criada recentemente. Os validadores o usam para verificar se a transação está atual e não foi repetida de uma sessão anterior. Blockhashes expiram após aproximadamente 150 slots; após isso, a transação é rejeitada com um erro de Blockhash not found ou Transaction expired.

O que são unidades de computação na Solana?

Unidades de computação são a medida da Solana para os recursos de processamento que uma transação consome. Transferências simples usam uma pequena quantidade; swaps DEX complexas e multi-hop usam significativamente mais. Se uma transação esgotar seu orçamento de unidades de computação antes de concluir, a Solana a cancelará e retornará o erro Compute budget exceeded. Interfaces DEX modernas definem limites de unidades de computação automaticamente para a maioria dos usuários.

O que é uma taxa de prioridade na Solana?

Uma taxa de prioridade é uma gorjeta opcional paga aos validadores em micro-lamports por unidade de computação para mover sua transação para frente de submissões com taxas mais baixas durante o congestionamento. A taxa-base de transação da Solana é fixa e pequena; a taxa de prioridade é o componente variável que determina a rapidez com que sua transação é processada. Os níveis de taxa variam com a demanda da rede, portanto, use o recurso de estimativa automática da sua carteira ou a API de Taxa de Prioridade da Helius para valores atuais.

Como verifico se uma transação na Solana falhou?

Copie a assinatura da transação do histórico de transações da sua carteira e cole-a no Solana Explorer ou Solana FM. Transações falhas mostram um status de erro vermelho com o código de erro específico. Transações confirmadas mostram um status de sucesso verde. Sempre verifique antes de reenviar para evitar enviar uma transação duplicada.

Posso recuperar fundos de uma transação falha na Solana?

Seus fundos não precisam ser recuperados porque nunca foram enviados. Uma transação falha na Solana não deduz seus tokens ou valor da swap da sua carteira. A transação falhou antes da execução, então o saldo da sua carteira permanece inalterado, exceto pela pequena taxa-base. Seu principal está seguro.

Por que a Solana descarta transações em vez de colocá-las em fila?

A Solana usa um protocolo de encaminhamento de transações chamado Gulf Stream em vez de uma fila de transações tradicional. O Gulf Stream encaminha transações diretamente para o próximo validador esperado antes que o bloco atual termine. Transações que não podem ser processadas imediatamente são descartadas em vez de serem mantidas em uma linha de espera. Esse design permite a alta taxa de transferência da Solana, mas significa que transações falhas exigem reenvio ativo em vez de espera passiva.

O que significa "transaction simulation failed" no Phantom?

Transaction simulation failed significa que o Phantom executou um teste pré-voo na sua transação e previu que ela não seria bem-sucedida. O Phantom bloqueia a submissão para evitar que você gaste uma taxa em uma transação que falhará. A maioria das falhas de simulação indica um problema real com suas configurações, como slippage insuficiente, saldo baixo de SOL ou rejeição de programa. Ocasionalmente, dados de estado desatualizados causam uma falha falsa; atualizar a página e reenviar uma vez é apropriado nesse caso.

Como resolvo fundos insuficientes na Solana?

Adicione SOL à sua carteira e certifique-se de que seu saldo exceda o valor da transação mais as taxas mais um buffer de 0,05 SOL. O erro de fundos insuficientes da Solana nem sempre significa que você está sem SOL apenas para a taxa. Às vezes, significa que você não tem SOL suficiente para cobrir o limite de isenção de aluguel exigido para criar uma nova conta de token ao receber um token pela primeira vez.

Meu dinheiro está seguro se uma transação na Solana falhar?

Seu principal está seguro. Os tokens ou SOL que você estava tentando enviar ou trocar permanecem na sua carteira exatamente como estavam. Uma transação falha na Solana não executa a transferência, swap ou mint, portanto, seu saldo permanece inalterado. Apenas uma pequena taxa-base de transação, tipicamente menos de US$ 0,001, pode ter sido cobrada.

Por que minha transação na Solana continua falhando mesmo depois de tentar novamente?

Transações que falham repetidamente geralmente indicam que a mesma configuração incorreta está sendo reenviada sem ajuste. Identifique seu erro: se for Slippage tolerance exceeded, aumente a tolerância a slippage e reenvie. Se as transações forem descartadas silenciosamente sem mensagem de erro, sua taxa de prioridade está muito baixa. Se status.solana.com mostrar um incidente ativo, aguarde a rede se recuperar antes de reenviar.

Por que transações na Solana falham durante mints NFT?

Falhas de mint NFT ocorrem porque milhares de usuários e bots submetem transações simultaneamente em uma janela de lançamento estreita, saturando os endpoints RPC públicos e a fila de validadores. Os validadores descartam transações de baixa taxa de prioridade para gerenciar a carga. Definir sua taxa de prioridade para Turbo e mudar para um provedor RPC dedicado antes da abertura da janela de mint melhora significativamente as taxas de sucesso. Consulte Magic Eden e Falhas de Mint de NFT NFT para o protocolo de preparação completo.

O que é tolerância a slippage em DEXes da Solana?

A tolerância a slippage é a variação máxima de preço que você aceitará entre o momento em que solicita uma swap e quando ela é executada. Se o preço do token se mover além desse limite, o Smart Contract cancelará a swap automaticamente para protegê-lo de receber um preço significativamente pior do que o cotado. Configurações típicas variam de 0,5% para pares de tokens estáveis a 2% ou 3% para ativos voláteis. Definir acima de 3% a 5% em pares de baixa liquidez aumenta a exposição a ataques de sandwich MEV.

Explore SOL na Bybit

Use a página de preços da SOL) para revisar os dados de mercado atuais da SOL ou acesse o mercado spot SOL/USDT) se o Trading Spot corresponder aos seus objetivos. A atividade de trading Bybit não é o mesmo que submeter uma transação na blockchain da Solana; taxas de rede ainda podem ser aplicadas ao depositar ou sacar SOL na rede Solana.

Resumo: Combine Seu Erro com a Correção Certa

Toda falha de transação na Solana mapeia para uma das cinco causas raiz, e cada uma tem uma correção específica.

Seu principal está seguro em qualquer um desses cenários. Transações Solana falhas não perdem tokens permanentemente; apenas uma taxa-base mínima é consumida. Para evitar falhas repetidas, passe pela Lista de Verificação Pré-Transação antes do seu próximo swap ou mint sensível ao tempo.

Os caminhos de configurações referenciados neste guia estão precisos a partir da data de publicação e podem variar de acordo com a carteira ou versão do DEX. Os níveis de taxa variam com a demanda da rede; use o recurso de estimativa automática da sua carteira ou a API de Taxa de Prioridade da Helius para valores atuais. As referências de ferramentas (Helius, QuickNode, Solana Beach) são apresentadas como opções, não endossos.