Porquê as Transações Solana Falham: 5 Soluções

Este guia focado em ações concentra-se em cinco soluções práticas para transações Solana falhadas e passos que podem prevenir falhas repetidas.

As transações Solana falham por cinco razões:

1. Blockhash expirou antes da rede confirmar a transação
2. A taxa de prioridade foi demasiado baixa para a procura atual da rede
3. A tolerância Slippage foi violada num swap DEX
4. O orçamento de unidades de computação esgotou-se a meio da execução
5. O nó RPC a ligar a sua carteira à rede estava sobrecarregado

✅ Os Seus Fundos Estão Seguros

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

Nesta página:

• Porquê as Transações Solana Falham: O Que Está a Acontecer
• As 5 Causas Raiz das Falhas de Transações Solana
• Mensagens de Erro Solana Decodificadas
• Como Corrigir uma Transação Solana Falhada
• Falhas Específicas da Plataforma
• Solana Está Down? Como Verificar o Estado da Rede Status
• Ainda se Paga Taxas numa Transação Falhada?
• Lista de Verificação Pré-Transação
• Perguntas Frequentes
• Resumo: Associe o Seu Erro à Solução Correta

Porquê as Transações Solana Falham: O Que Está a Acontecer

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

Em todo o ecossistema de finanças descentralizadas (DeFi - DeFi) da Solana, incluindo swaps de tokens, provisão de liquidez, protocolos de empréstimo e mints de NFT, as falhas de transação acarretam consequências financeiras reais porque os preços movem-se em milissegundos. A arquitetura da Solana torna-a mais rápida e mais barata do que a maioria das blockchains, mas também cria modos de falha que os utilizadores familiarizados com o Ethereum ou outras cadeias não esperarão. Ao contrário das redes onde as transações lentas esperam numa fila, a 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. As transações falhadas exigem reenvio ativo com as configurações corretas.

Este guia cobre falhas em toda a sua carteira de criptomoedas (como a Phantom ou Backpack), Jupiter, Raydium, Orca e Magic Eden. Se suspeitar que a própria Solana está a ter problemas hoje, salte para a secção de estado da rede antes de resolver os seus ajustes.

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

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

A 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 comunicarem timestamps uns aos outros. Cada slot nesta sequência produz um blockhash, um código semelhante a um timestamp incorporado em cada transação para provar que a transação é atual. Esta arquitetura baseada em slots cria as janelas de vencimento únicas da Solana e é o que distingue os 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, a Solana descarta-a totalmente.

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 atrasam-se no processamento, o que significa que as transações expiram mais rapidamente em termos relativos. As mensagens de erro que verá são Blockhash not found ou Transaction expired.

A Solana usa o Gulf Stream em vez de uma fila de transações tradicional, o que significa que uma transação descartada não volta a ser enfileirada e a esperar. Ela desaparece. Deve reenviá-la ativamente iniciando a transação novamente a partir da sua carteira ou interface DEX. A carteira obtém automaticamente um blockhash fresco na nova submissão. Para o procedimento de reenvio, veja Solução 3: Reenviar Com um Blockhash Fresco.

⚠️ Nota para Desenvolvedores

Obtenha sempre um blockhash fresco com connection.getLatestBlockhash('confirmed') em cada tentativa de reenvio. Nunca reutilize um blockhash em tentativas de reenvio. Use níveis de compromisso confirmed ou finalized em ambientes de produção, não processed, para evitar estado desatualizado. Detete se uma transação foi descartada ou processada chamando getSignatureStatuses antes de cada reenvio.

Causa 2: Taxa de Prioridade Muito Baixa

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

Uma taxa de prioridade é uma gorjeta opcional paga aos validadores, medida em micro-lamports por unidade de computação. Um lamport equivale a 0,000000001 SOL; um micro-lamport é um milionésimo de um lamport. Durante períodos de tráfego elevado, como lançamentos populares de NFT 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 para erros de saldo insuficiente: A Solana exige que cada conta mantenha um saldo mínimo chamado limiar isento de aluguer para permanecer ativa na rede. Se o saldo da sua carteira cair abaixo deste limiar após uma taxa, ou se uma transação criar uma nova conta de token sem SOL suficiente para a financiar, verá um erro de Insufficient funds mesmo quando parecer ter SOL suficiente para a própria negociação. Mantenha um buffer de 0,05 SOL acima do montante da sua transação.

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

⚠️ Nota para Desenvolvedores

Adicione ComputeBudgetProgram.setComputeUnitPrice(microLamports) como a primeira instrução na sua transação. Monitore getRecentPrioritizationFees() para estimativa dinâmica em vez de usar um multiplicador estático. Os níveis de taxa mudam com a procura da rede, pelo que os valores estáticos tornam-se não confiáveis durante picos de congestionamento. Detete gatilhos de failover monitorizando erros HTTP 429 (rate limit), 503 (service unavailable) e timeout de conexão.

Causa 3: Orçamento de Computação Excedido

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

Se a sua transação esgotar o seu orçamento de unidades de computação antes de terminar, a Solana cancela-a. Os erros que verá são Compute budget exceeded ou Program failed to complete.

Antes de enviar a 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 contra o estado atual da blockchain sem a submeter realmente. Se a simulação detetar que as unidades de computação serão esgotadas, 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 obsoletos causem uma falha falsa numa transação que, de outra forma, teria sucesso.

Para a maioria dos utilizadores em interfaces DEX modernas, os limites das unidades de computação são definidos automaticamente. Se vir um erro de orçamento de computação, utilize o botão de repetição integrado da DEX antes de tentar ajustes manuais. Para passos detalhados, consulte Correção 5: Ajustar o Orçamento de Unidades de Computação.

⚠️ Nota para Desenvolvedores

Adicione ComputeBudgetProgram.setComputeUnitLimit(units) como a primeira instrução na transação. Execute simulateTransaction() primeiro para medir o consumo real de unidades 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 demasiado baixo causa falhas de InstructionError; defini-lo demasiado alto desperdiça o orçamento de taxas, mas não causa falhas.

Causa 4: Tolerância de Slippage Excedida

Tolerância de Slippage é uma proteção que a sua corretora descentralizada (DEX, uma plataforma onde pode trocar tokens diretamente da sua carteira) define em seu nome. Se o preço de um token variar mais do que o limite definido entre o momento em que solicita a troca e o momento em que esta é executada, o Smart Contract cancela a transação para o proteger de um preço pior do que o esperado.

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

As falhas de Slippage acontecem com maior frequência em tokens voláteis, pares de trading de baixa liquidez e durante períodos de elevada congestão, quando existe um atraso maior entre a sua cotação de 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 consegue acomodar o tamanho da sua negociação a qualquer preço razoável. Nesse caso, tente reduzir o montante da troca ou mudar para um par de trading diferente.

Jupiter, Raydium e Orca são as DEXes onde esta falha é encontrada mais comummente. Para instruções de ajuste passo a passo, consulte Correção 2: Ajustar a Sua Tolerância de Slippage.

Causa 5: Nó RPC Sobrecarregado

A sua carteira Solana liga-se a um servidor chamado nó RPC para submeter transações. Pense nele como a estação de correios que passa a sua transação para a rede de validadores. Sempre que clica em confirmar na Phantom ou Backpack, a carteira envia a sua transação para um nó RPC, que a encaminha para os validadores.

O endpoint RPC público gratuito da Solana tem limite de taxa e é frequentemente sobrecarregado durante períodos de elevada procura. Durante um lançamento Popular de NFT ou um movimento brusco de mercado, os nós RPC públicos recebem muito mais submissões do que as que conseguem processar, e descartam transações antes mesmo de estas chegarem aos validadores. Quando isto acontece, pode ver Unable to confirm transaction ou experienciar falhas silenciosas sem qualquer mensagem de erro.

Mudar para um fornecedor de RPC dedicado, como a Helius ou a QuickNode, que oferecem planos gratuitos, dá às suas transações um caminho mais fiável para a rede. Para passos sobre como mudar o seu RPC, consulte Correção 4: Mudar para um Melhor RPC Endpoint.

⚠️ Nota para Desenvolvedores

Mantenha uma lista de endpoints RPC de reserva na configuração da sua aplicação. Implemente uma lógica de failover automático quando o endpoint principal retornar erros ou expirar o tempo limite. Utilize o WebSocket signatureSubscribe para a monitorização da confirmação de transações em vez de polling HTTP com getSignatureStatuses, uma vez que as subscrições de WebSocket são mais rápidas e mais fiáveis sob carga.

Mensagens de Erro da Solana Descodificadas: O Que Cada Uma Significa

As mensagens de erro de transações Solana falhadas aparecem no registo de atividade da sua carteira (Phantom ou Solflare), no Solana Explorer (explorer.solana.com) ou no Solana FM (solana.fm). Para pesquisar uma transação falhada específica, copiar a assinatura da transação do histórico de transações da sua carteira e cole-a num dos exploradores. Uma transação falhada mostra um estado 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 terá sucesso. Se esta verificação prévia falhar, a Phantom mostra Transaction simulation failed e bloqueia a submissão. A maioria das falhas de simulação indica um problema real com as suas definições, mas ocasionalmente dados obsoletos causam uma falha falsa. Nesse caso, atualizar a página e submeter novamente uma vez é apropriado.

Como Corrigir uma Transação Solana Falhada

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

1. Aumente a sua taxa de prioridade para Rápida ou Turbo e submeta novamente
2. Ajuste a tolerância de slippage para cima em 0,5% a 1% e submeta novamente
3. Submeta novamente com um novo blockhash (aguarde 5 segundos e inicie a partir da DEX novamente)
4. Mude para um endpoint RPC dedicado nas definições da sua carteira
5. Verifique o estado 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 falhadas durante períodos de trading ativo, pelo que a Correção 1 é o ponto de partida certo quando não tem a certeza.

Correção 1: Aumentar a Sua Taxa de Prioridade

Aumentar a sua taxa de prioridade é a solução mais eficaz para transações falhadas durante períodos de congestionamento. Sinaliza aos validadores para processarem a sua transação antes das submissões com taxas mais baixas.

Os níveis de taxa variam com a procura da rede. Use a funcionalidade de estimativa automática da sua carteira ou consulte o Solana Beach para conhecer as condições atuais da rede. Não confie em valores específicos de lamports, pois estes mudam rapidamente.

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

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

1. Abra o Jupiter em jup.ag
2. Clique no ícone de engrenagem das definições no painel de swap
3. Selecione Priority Fee
4. Escolha Fast ou Turbo, ou introduza um valor Custom
5. Reenvie o seu swap

Para aumentar a taxa de prioridade no Phantom:

1. Abra a carteira Phantom
2. Aceda a Settings
3. Selecione Transactions
4. Ajuste a Transaction Speed para High ou Custom
5. Regresse ao seu DEX e reenvie

Para o Raydium, clique no ícone de engrenagem das definições na interface de swap, selecione Priority Fee, escolha um nível superior e reenvie. A tabela Falhas Específicas da Plataforma mostra o caminho de navegação exato para cada Plataforma.

⚠️ Nota para Desenvolvedores

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

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

Se o seu swap falhou com um erro de tolerância a slippage, a correção é alargar o intervalo de preço aceitável, mas a quantidade com que o alarga importa.

⚠️ Aviso Importante

Definir slippage acima de 3% a 5% em pares de tokens com baixa Liquidez expõe-no a ataques de sanduíche MEV, onde bots detetam a sua transação pendente e executam-na antecipadamente para extrair valor. Aumente o slippage incrementalmente, não de uma só vez.

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

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

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

Se estiver a usar o Jupiter, verifique se a funcionalidade Dynamic Slippage está disponível na sua interface. Esta funcionalidade calcula automaticamente o slippage ideal para cada trade com base nas condições atuais do mercado.

Se um token continuar a falhar mesmo com 5% de slippage, o problema é provavelmente Liquidez insuficiente na pool em vez de movimento de preços. Tente reduzir o montante do seu swap ou dividir a operação em transações menores.

Correção 3: Reenvie com um Novo Blockhash

A Vencimento de um blockhash é corrigida reenviando, mas não pode reenviar o mesmo objeto de transação. Solana requer um novo blockhash em cada submissão.

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

Para utilizadores consumidores (Phantom, Jupiter, Raydium):

1. Aguarde 5 a 10 segundos após a falha
2. Não clique em submeter novamente no mesmo ecrã de confirmação
3. Regresse à interface de swap e inicie a transação novamente do início
4. A sua carteira obtém automaticamente um novo blockhash quando reenvia

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

⚠️ Nota para Desenvolvedores

Obtenha um novo blockhash com connection.getLatestBlockhash('confirmed') antes de cada tentativa de retentativa. Implemente backoff exponencial: aguarde 1 segundo antes da primeira retentativa, 2 segundos antes da segunda, 4 segundos antes da terceira. Defina um número máximo de retentativas de 5 tentativas antes de apresentar um erro ao utilizador. Use os níveis de compromisso confirmed ou finalized, não processed, ao obter blockhashes em ambientes de produção.

Correção 4: Mude para um Melhor RPC Endpoint

O RPC endpoint público gratuito do Solana (api.mainnet-beta.solana.com) é limitado por taxa e frequentemente sobrecarregado durante períodos de alta procura, tornando as transações submetidas mais propensas a serem descartadas antes de chegarem aos validadores.

Fornecedores dedicados de RPC como Helius e QuickNode geralmente oferecem maior fiabilidade do que o RPC mainnet público do Solana durante o congestionamento. Ambos os fornecedores oferecem níveis gratuitos adequados para utilizadores individuais.

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

1. Abra a carteira Phantom
2. Aceda a Settings
3. Selecione Developer Settings
4. Escolha Change RPC Endpoint
5. Introduza o URL do seu endpoint Helius ou QuickNode
6. Confirme e reenvie a sua transação

Para mudar de RPC no Solflare:

1. Abra a carteira Solflare
2. Aceda a Settings
3. Selecione Network
4. Escolha Custom RPC e introduza o URL do seu endpoint
5. Guarde e reenvie a sua transação

⚠️ Nota para Desenvolvedores

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

Correção 5: Ajuste o Orçamento de Unidades de Computação

Para utilizadores consumidores, a maioria das interfaces modernas de DEX, incluindo Jupiter e Raydium, definem limites de unidades de computação automaticamente. Se vir um erro Compute budget exceeded, use a função de retentativa ou atualização integrada do DEX em vez de ajustar manualmente as definições.

Se o erro persistir, tente simplificar a sua rota de swap. Uma rota direta através de uma única 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 uma opção Direct Route Only nas definições de roteamento.

Se o seu swap falhar consistentemente num par específico, pode ser uma rota com procura temporariamente alta. Esperar alguns minutos e reenviar muitas vezes resolve o problema sem qualquer alteração nas definições.

⚠️ Nota para Desenvolvedores

Adicione ComputeBudgetProgram.setComputeUnitLimit(units) como a primeira instrução na transação. Execute simulateTransaction() primeiro para medir o consumo real de unidades de computação, depois defina o limite para o consumo real multiplicado por 1,1 como um buffer de segurança de 10%. Definir o limite muito baixo causa falhas 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

Falhas Específicas de Plataformas: Phantom, Jupiter, Raydium e Magic Eden

Os cenários de falha mais comuns do Solana desenrolam-se de forma diferente consoante a Plataforma que está a usar. Verifique a tabela de comparação abaixo para encontrar a sua Plataforma, depois leia a subsecção relevante para obter detalhes.

Falhas de Swap na Jupiter

O encaminhamento multi-salto da Jupiter envia o seu swap através de vários pools de liquidez para encontrar o melhor preço. Cada salto adicional aumenta o consumo de unidades de computação e cria outro ponto onde o movimento do preço pode exceder 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 definições no menu do ícone de engrenagem da Jupiter antes de reenviar.

O seletor de taxa de prioridade integrado da Jupiter oferece opções Normal, Rápido, Turbo e Personalizado. Durante qualquer sessão de negociação ativa, Rápido é a definição mínima recomendada. Durante um lançamento NFT ou um movimento acentuado do mercado, utilize Turbo.

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

Falhas de Swap na Raydium e Orca

As falhas de AMM na Raydium e Orca ocorrem mais frequentemente devido a um alto impacto no preço em pools com liquidez limitada. O pool não consegue acomodar o tamanho do seu trade a um preço razoável, mesmo com configurações generosas de slippage.

Antes de confirmar qualquer swap na Raydium ou Orca, verifique a percentagem de impacto no preço mostrada na interface. Se o impacto no preço exceder 2% a 3%, o tamanho do trade é muito grande para a liquidez disponível nesse pool. Reduza o seu montante de swap ou divida a transação em dois ou três swaps menores submetidos sequencialmente.

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

Falhas de Mint na Magic Eden e NFT

As falhas de mint NFT na Magic Eden diferem das falhas de DEX rotineiras porque o problema não são as suas definiçõ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 que usam programas Candy Machine criam concorrência extrema. Bots submetem centenas de transações por segundo, saturando tanto o RPC público quanto a fila de validadores.

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

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

O seu principal em 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, portanto, se as transações falharem consistentemente mesmo com definições corretas, confirme que se qualifica para a fase de mint atual.

A Solana está Desligada? Como Verificar a Liquidez da Rede Status

A maioria das falhas de transação da Solana não são causadas por uma interrupção da rede. Resultam de definições do lado do utilizador ou congestionamento temporário da rede. Interrupções reais, onde a rede para completamente, são raras e anunciadas oficialmente.

Verificação de estado em três passos:

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

Ainda Paga Taxas numa Transação Solana Falhada?

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

Os 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 cêntimo na maioria dos níveis de preço do SOL. Esta taxa compensa os validadores por processarem a tentativa de transação, mesmo quando ela não tem sucesso. Se incluiu uma taxa de prioridade, esse montante também é consumido. O montante de token que estava a tentar trocar, o SOL que estava a tentar enviar, ou o preço NFT que estava a tentar pagar nunca foram deduzidos.

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

Para verificar exatamente quanta taxa foi cobrada em qualquer transação falhada:

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 falhada, que mostra um estado de erro vermelho
4. Verifique o campo Taxa para ver o montante exato de SOL cobrado

Lista de Verificação Pré-Transação: Como Evitar Falhas nas Transações Solana

Realizar esta lista de verificação antes de qualquer transação sensível ao tempo demora 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 a sua taxa de prioridade para, pelo menos, Rápido para qualquer transação durante as horas de negociação ativas; utilize Turbo para trades ou mints NFT sensíveis ao tempo
3. Verifique se a 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 capitalização média, até 3% para small-caps voláteis
4. Confirme se o seu Saldo de SOL cobre o montante da transação mais as taxas mais um buffer de 0,05 SOL para limites isentos de aluguer
5. Para transações sensíveis ao tempo ou de alto valor, mude do RPC público da Solana para um fornecedor dedicado como Helius ou QuickNode (ambos oferecem níveis gratuitos)
6. Para mints NFT: configure a sua taxa de prioridade e RPC antes de a janela de mint abrir, não durante ela
7. Para grandes swaps DEX: verifique a percentagem de impacto no preço antes de confirmar; se o impacto no preço exceder 2% a 3%, reduza o montante do swap ou divida em transações menores
8. Confie no otimizador de taxas incorporado do seu DEX quando disponível; Jupiter, Raydium e Orca oferecem cada um recomendações automáticas de taxas que se ajustam às condições atuais da rede

⚠️ Nota do Desenvolvedor

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

Perguntas Frequentes: Cinco Correções para Transações Solana Falhadas

Cada resposta abaixo é independente. Não precisa de ler o resto deste guia para usar o FAQ.

O que causa o falhanço de uma transação Solana?

As transações 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 de slippage ou sobrecarga do nó RPC. Falhas a nível de rede exigem o aumento da sua taxa de prioridade e reenvio. Rejeições a nível de programa exigem o ajuste de parâmetros de transação como tolerância de slippage ou montante de troca. Veja As 5 Causas Raiz para uma explicação completa de cada uma.

Sim. A Solana cobra uma pequena taxa-base de transação, aproximadamente 0,000005 SOL, mesmo quando uma transação falha, mas os seus tokens e o principal da troca não são deduzidos. Transações descartadas silenciosamente por um nó RPC sobrecarregado antes de chegar à rede não cobram qualquer taxa, pois não deixam registo na blockchain. Veja Ainda Paga Taxas para instruções de verificação.

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

Um blockhash é um código semelhante a um carimbo de data/hora incorporado em cada transação Solana que prova que a transação foi criada recentemente. Os validadores utilizam-no para verificar se a transação está atualizada e não foi repetida de uma sessão anterior. Os blockhashes expiram após aproximadamente 150 slots; depois disso, a transação é rejeitada com um erro Blockhash not found ou Transaction expired.

As 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; trocas DEX complexas e de múltiplos saltos usam significativamente mais. Se uma transação esgotar o seu orçamento de unidades de computação antes de ser concluída, a Solana cancela-a e devolve o erro Compute budget exceeded. As interfaces DEX modernas definem limites de unidades de computação automaticamente para a maioria dos utilizadores.

Uma taxa de prioridade é uma gorjeta opcional paga aos validadores em micro-lamports por unidade de computação para mover a sua transação para a frente de submissões de taxas mais baixas durante a congestão. A taxa-base de transação da Solana é fixa e pequena; a taxa de prioridade é o componente variável que determina quão rapidamente a sua transação é processada. Os níveis de taxa variam com a procura da rede, por isso utilize a funcionalidade de estimativa automática da sua carteira ou a API Helius Priority Fee para valores atuais.

Copie a assinatura da transação do histórico de transações da sua carteira e cole-a no Solana Explorer ou Solana FM. As transações falhadas exibem um estado de erro vermelho com o código de erro específico. As transações confirmadas exibem um estado de sucesso verde. Verifique sempre antes de reenviar para evitar enviar uma transação duplicada.

Os seus fundos não precisam de ser recuperados porque nunca foram enviados. Uma transação Solana falhada não deduz os seus tokens ou o montante da troca da sua carteira. A transação falhou antes da execução, pelo que o saldo da sua carteira permanece inalterado, exceto pela pequena taxa-base. O seu principal está seguro.

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. As transações que não podem ser processadas imediatamente são descartadas em vez de mantidas numa linha de espera. Este design permite o alto rendimento da Solana, mas significa que as transações falhadas exigem reenvió ativo em vez de espera passiva.

A simulação de transação falhada significa que a Phantom realizou um teste pré-voo na sua transação e previu que ela não teria sucesso. A Phantom bloqueia a submissão para evitar que desperdice uma taxa numa transação que falhará. A maioria das falhas de simulação indica um problema real com as suas definições, como slippage insuficiente, saldo SOL baixo 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.

Adicione SOL à sua carteira e certifique-se de que o seu saldo excede o montante da transação mais as taxas mais um buffer de 0,05 SOL. O erro de fundos insuficientes da Solana nem sempre significa que ficou sem SOL apenas para a taxa. Às vezes, significa que não tem SOL suficiente para cobrir o limite isento de aluguer necessário para criar uma nova conta de token ao receber um token pela primeira vez.

O seu principal está seguro. Os tokens ou SOL que estava a tentar enviar ou trocar permanecem na sua carteira exatamente como estavam. Uma transação Solana falhada não executa a transferência, troca ou mintagem, pelo que o seu saldo permanece inalterado. Apenas uma pequena taxa-base de transação, tipicamente menos de $0,001, pode ter sido cobrada.

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

As falhas de mint NFT ocorrem porque milhares de utilizadores e bots enviam transações simultaneamente durante uma janela de lançamento restrita, saturando os endpoints RPC públicos e a fila de validadores. Os validadores descartam transações de taxa de prioridade baixa para gerir a carga. Definir a sua taxa de prioridade para Turbo e mudar para um fornecedor RPC dedicado antes da abertura da janela de mint melhora significativamente as taxas de sucesso. Veja Magic Eden e Falhas de Mint NFT para o protocolo de preparação completo.

A tolerância de Slippage é o movimento de preço máximo que aceitará entre o momento em que solicita uma troca e o momento em que ela é executada. Se o preço do token se mover para além desse limiar, o smart contract cancela automaticamente a troca para o proteger de receber um preço significativamente pior do que o cotado. As configurações típicas variam de 0,5% para pares de tokens estáveis a 2% ou 3% para ativos voláteis. Definir para mais de 3% a 5% em pares de baixa liquidez aumenta a exposição a ataques de sanduíche MEV.

Explore SOL na Bybit

Utilize a página de preços da SOL) para rever os dados de mercado atuais da SOL, ou aceda ao 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 Solana; podem ainda aplicar-se taxas de rede ao depositar ou levantar SOL na rede Solana.

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

O seu capital está seguro em cada um destes cenários. As transações falhadas na Solana não resultam na perda permanente de tokens; apenas uma Taxa-base mínima é consumida. Para evitar falhas repetidas, consulte a Lista de Verificação Pré-Transação antes da sua próxima troca ou cunhagem sensível ao tempo.

Os caminhos de definições referenciados neste guia estão corretos à data de publicação e podem variar conforme a versão da carteira ou da DEX. Os níveis das taxas variam com a procura da rede; utilize a funcionalidade de estimativa automática da sua carteira ou a API de Taxas de Prioridade da Helius para valores atuais. Referências a ferramentas (Helius, QuickNode, Solana Beach) são apresentadas como Opções, não como endossos.