Documentation Index
Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
Use this file to discover all available pages before exploring further.
Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →
Toda transação Solana define (implícita ou explicitamente) dois parâmetros: um limite de unidades de computação (máximo de CUs que a tx pode consumir; padrão 200.000 × número de instruções até um limite por tx) e uma taxa de prioridade em micro-lamports por CU. Dimensionar incorretamente qualquer um deles mata a transação — limites de CU muito baixos causam
ProgramFailedToComplete; taxas de prioridade muito baixas fazem a tx ficar não confirmada até expirar.As duas configurações
setComputeUnitLimit(units)— limita computação; a transação paga por no máximounitsCUs.setComputeUnitPrice(microLamports)— lance de taxa de prioridade, em micro-lamports por CU. Taxa de prioridade total =units × microLamports × 1e-6lamports.
250_000 × 50_000 / 1e6 = 12.500 lamports ≈ 0,0000125 SOL ≈ $0,003 a $200 SOL. Taxas de prioridade nessa escala são ruído para a maioria dos swaps de usuários, mas significativas para bots fazendo 1000 txs/dia.
Benchmarks de CU por instrução
Benchmarks de logs de execução da mainnet, obtidos pela média de execuções recentes. Os números são aproximados (±15%); re-meça seus fluxos específicos.| Instrução | SPL Token | Token-2022 (simples) | Token-2022 (taxa de transferência) |
|---|---|---|---|
| CPMM initialize_pool | 180.000 | 200.000 | — |
| CPMM swap_base_input | 140.000 | 180.000 | 200.000 |
| CPMM swap_base_output | 150.000 | 185.000 | 205.000 |
| CPMM deposit | 130.000 | 160.000 | 180.000 |
| CPMM withdraw | 120.000 | 150.000 | 170.000 |
| CLMM create_pool | 70.000 | 85.000 | — |
| CLMM open_position_v2 | 120.000 | 140.000 | 160.000 |
| CLMM increase_liquidity_v2 | 150.000 | 175.000 | 195.000 |
| CLMM decrease_liquidity_v2 | 140.000 | 165.000 | 185.000 |
| CLMM swap_v2 (0 cruzamentos de tick) | 170.000 | 205.000 | 225.000 |
| CLMM swap_v2 (1 cruzamento de tick) | 220.000 | 255.000 | 275.000 |
| CLMM swap_v2 (3 cruzamentos de tick) | 320.000 | 355.000 | 375.000 |
| CLMM collect_fee | 80.000 | 95.000 | 105.000 |
| AMM v4 swap_base_in | 140.000 | — | — |
| AMM v4 deposit | 120.000 | — | — |
| AMM v4 withdraw | 110.000 | — | — |
| Farm v6 create_farm | 70.000 | 85.000 | — |
| Farm v6 deposit (1 slot de recompensa) | 130.000 | 155.000 | 175.000 |
| Farm v6 deposit (3 slots de recompensa) | 220.000 | 255.000 | 275.000 |
| Farm v6 withdraw | igual ao deposit | ||
| Farm v6 harvest | igual ao deposit | ||
| Farm v3/v5 deposit | 100.000 | — | — |
| LaunchLab initialize | 100.000 | — | — |
| LaunchLab buy_exact_in | 140.000 | — | — |
| LaunchLab graduate | 250.000 | — | — |
Transações compostas
Some os orçamentos individuais e adicione:- +1.500 CU por frame de CPI — sobrecarga fixa do runtime para cada chamada entre programas.
- +20.000 CU por criação de ATA —
create_associated_token_accountnão é grátis. - +5.000 CU para
setComputeUnitLimit/setComputeUnitPricecada uma.
units × microLamports, então ~25% acima do orçamento custa 25% extra em taxa de prioridade).
Estimativa de taxa de prioridade
O mercado de taxas local do Solana significa que as taxas de prioridade são por conta gravável. Uma tx que grava em uma conta quente (estado de pool popular) paga mais do que uma tx que grava em uma conta fria. O nível de taxa global não é a métrica certa para swaps Raydium; você quer taxas nas pools específicas que está tocando.Estratégia 1: Estimador do provedor RPC
Cada grande provedor RPC publica um estimador de taxa de prioridade que consulta taxas recentes em contas específicas:Min / Low / Medium / High / VeryHigh / UnsafeMax. Mapeie-os para percentis:
| Nível | Percentil | Caso de uso |
|---|---|---|
| Min | 25º | Tráfego de bot em background, não urgente |
| Low | 50º | Swaps normais de usuários |
| Medium | 60º | Padrão para UIs de carteira |
| High | 75º | Arbitragem sensível ao tempo |
| VeryHigh | 95º | Liquidações, saídas de última chance |
getPriorityFeeEstimate), Triton (getRecentPrioritizationFees com lista de contas), QuickNode (similar).
Estratégia 2: Consulta RPC direta
Use o RPC padrãogetRecentPrioritizationFees:
Estratégia 3: Auto-ajuste histórico
Para bots com fluxo constante, rastreie suas próprias taxas de sucesso vs. expiração:Tratamento de falhas por esgotamento de CU
Sintoma: tx falha comexceeded maximum number of instructions allowed (200000) ou ProgramFailedToComplete.
Diagnóstico:
- Aumente o limite de CU. Se sua tx estava usando 195k de um orçamento de 200k, suba para 300k.
- Divida a transação. Se você está batendo no limite de 1,4M por tx, quebre em duas txs. Farm
harvest then stakeé um clássico para dividir quando há muitas recompensas. - Aparar contas. Cada conta gravável adicional adiciona ~2.000 CU. Podar contas não utilizadas ajuda em casos marginais.
- Use tabelas de lookup. Lookups de LUT são ~50 CU por endereço resolvido, economizando os 5.000 CU de uma referência de conta completa por entrada.
Tratamento de transações travadas
Sintoma: tx submetida, nunca confirma, eventualmente expira comBlockhashNotFound.
Diagnóstico:
getSignatureStatuses([sig])retornanull→ líder nunca viu.- Retorna
{ confirmationStatus: null }→ líder viu mas não incluiu.
- Aumente a taxa de prioridade. Resubmeta com 2× a taxa atual.
- Reconstrua com blockhash fresco. A vida útil do blockhash é ~60 segundos; além disso a tx é inválida independentemente de taxas.
- Broadcast multi-RPC. Alguns RPCs têm melhor conectividade com líderes. Submeta a 3–5 em paralelo.
- Mude para bundles Jito. Veja
integration-guides/routing-and-mev. Bundles ignoram filas de pacotes públicas.
Sob congestionamento
Quando a rede está congestionada (dashboards Jupiter / Jito bundle mostram backlog, latência RPC dispara, taxas de expiração de tx sobem), ajuste:| Parâmetro | Condições normais | Condições de congestionamento |
|---|---|---|
| Limite de CU | +25% acima da estimativa | +25% acima da estimativa (sem mudança) |
| Percentil de taxa de prioridade | 50º | 75º–95º |
| Contagem de retry | 3 | 5–7 |
| Backoff de retry | 500ms | 1000ms |
| Usar bundles Jito | Opcional | Fortemente recomendado |
| Refresh de blockhash no retry | Sim | Sim, obrigatório |
- Percentil 75º de taxa de prioridade > 500k micro-lamports: congestionamento.
- Percentil 50º de dica Jito > 0,001 SOL: congestionamento.
- p99 de resposta RPC > 2s: problema específico do RPC ou congestionamento.
Orçamento de taxa para bots
Um bot de trading rodando ~1000 txs/dia precisa de um orçamento de taxa de prioridade. Estimativa rápida:Armadilhas
1. Esquecer o limite de CU
O padrão é 200k CUs × (instruções em tx). Um swap de instrução única padrão é 200k; isso é suficiente para CPMM em SPL Token, mas não para CLMM com cruzamentos de tick ou qualquer coisa Token-2022. Sempre defina explicitamente.2. Taxa de prioridade na conta errada
Se você estimar taxa de prioridade contra o mint do token, mas a conta quente é o estado do pool, sua estimativa é muito baixa. O estado do pool é a conta gravável certa para mirar para Raydium.3. Taxas escalam com limite de CU
taxa_prioridade_total = units × microLamports. Aumentar units de 200k para 1M a 50k micro-lamports/CU multiplica a taxa de prioridade 5×. Não sobre-orce CU só no caso; meça.
4. Versão padrão de tx
Transações legacy têm limites de conta mais baixos; transações V0 com tabelas de lookup de endereço desbloqueiam rotas maiores. O SDK usa V0 por padrão emtxVersion: TxVersion.V0. Não caia para legacy a menos que você precise de compatibilidade de carteira.
5. skipPreflight esconde erros de CU
skipPreflight: true envia a tx sem simulação local. Você economiza ~100ms, mas perde o feedback antecipado sobre esgotamento de CU. Use apenas em retries, não na primeira tentativa.
Referências
integration-guides/routing-and-mev— estratégias de bundle Jito.integration-guides/aggregator— montagem de transação.integration-guides/cpi-integration— empilhamento de CU em CPIs compostos.- Documentação do programa compute budget do Solana
- Solana
getRecentPrioritizationFeesRPC - API de taxa de prioridade Helius
- Benchmarks: logs de execução da mainnet (testes de integração SDK Raydium, abril de 2026).


