> ## 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.

# Taxas de prioridade e orçamento computacional

> Dimensionamento correto dos limites de unidades de computação e taxas de prioridade para transações Raydium — benchmarks por instrução, estratégias de estimativa e padrões de tratamento de congestionamento.

<Info>
  **Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.**

  [Ver versão em inglês →](/integration-guides/priority-fee-tuning)
</Info>

<Info>
  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.
</Info>

## As duas configurações

```ts theme={null}
import { ComputeBudgetProgram } from "@solana/web3.js";

const tx = new Transaction()
  .add(ComputeBudgetProgram.setComputeUnitLimit({ units: 250_000 }))
  .add(ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 50_000 }))
  .add(yourRaydiumSwapIx);
```

* `setComputeUnitLimit(units)` — limita computação; a transação paga por no máximo `units` CUs.
* `setComputeUnitPrice(microLamports)` — lance de taxa de prioridade, em micro-lamports por CU. Taxa de prioridade total = `units × microLamports × 1e-6` lamports.

Cálculo de custo: um limite de 250k CU a 50k micro-lamports/CU oferece `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          | —                    | —                                  |

A linha "cruzamentos de tick" para CLMM é a maior variável de CU. Se você não souber quantos ticks o swap vai cruzar, orce pelo pior caso — 8 cruzamentos é o limite rígido (o programa carrega no máximo 8 arrays de tick).

### 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_account` não é grátis.
* **+5.000 CU para `setComputeUnitLimit` / `setComputeUnitPrice`** cada uma.

Exemplo: um swap de usuário que cria a ATA de saída e envolve SOL nativo:

```
wrap_sol (create_ata + system transfer + sync_native)   ≈ 30.000
CPMM swap_base_input (SPL)                              ≈ 140.000
close_account (unwrap)                                  ≈ 5.000
ComputeBudget instructions                              ≈ 10.000
────────────────────────────────────────────────────────
Total                                                   ≈ 185.000 → orçamento 250.000
```

Margem de segurança: defina o limite de CU \~25% acima do uso esperado. Subestimar custos mata toda a tx; superestimar apenas aumenta o custo de taxa de prioridade proporcionalmente (taxa de prioridade é `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:

```ts theme={null}
// Helius
const response = await fetch(`https://mainnet.helius-rpc.com/?api-key=${apiKey}`, {
  method: "POST",
  body: JSON.stringify({
    jsonrpc: "2.0",
    id:      "fee-estimate",
    method:  "getPriorityFeeEstimate",
    params: [{
      accountKeys: [poolStatePubkey.toBase58()],
      options:     { priorityLevel: "High" },
    }],
  }),
});
const { result } = await response.json();
const microLamports = result.priorityFeeEstimate;
```

Níveis de prioridade na maioria dos provedores: `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      |

Provedores: Helius (`getPriorityFeeEstimate`), Triton (`getRecentPrioritizationFees` com lista de contas), QuickNode (similar).

### Estratégia 2: Consulta RPC direta

Use o RPC padrão `getRecentPrioritizationFees`:

```ts theme={null}
const fees = await connection.getRecentPrioritizationFees({
  lockedWritableAccounts: [poolStatePubkey],
});

// fees: Array<{ slot, prioritizationFee }>
// Slots recentes; padrão ~150 slots.

const median = percentile(fees.map(f => f.prioritizationFee), 0.5);
```

Este é o método RPC vanilla do Solana; funciona com qualquer provedor. Desvantagem: a amostra é pequena (150 slots ≈ 60 segundos) e ruidosa. Para estimativas mais suaves, use a agregação de um provedor.

### Estratégia 3: Auto-ajuste histórico

Para bots com fluxo constante, rastreie suas próprias taxas de sucesso vs. expiração:

```
alvo por pool: taxa de sucesso de 80% em <30s
se taxa_sucesso_atual < 80%: priorityFee += 10%
se taxa_sucesso_atual > 95%: priorityFee -= 5%
```

Isto se auto-corrige mais rápido que estimadores públicos e captura a estrutura por pool que os estimadores públicos nem sempre veem.

## Tratamento de falhas por esgotamento de CU

Sintoma: tx falha com `exceeded maximum number of instructions allowed (200000)` ou `ProgramFailedToComplete`.

Diagnóstico:

```bash theme={null}
solana confirm <tx-sig> -v
# Procure por "consumed N of M compute units" e qual instrução esgotou.
```

Soluções:

1. **Aumente o limite de CU.** Se sua tx estava usando 195k de um orçamento de 200k, suba para 300k.
2. **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.
3. **Aparar contas.** Cada conta gravável adicional adiciona \~2.000 CU. Podar contas não utilizadas ajuda em casos marginais.
4. **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 com `BlockhashNotFound`.

Diagnóstico:

* `getSignatureStatuses([sig])` retorna `null` → líder nunca viu.
* Retorna `{ confirmationStatus: null }` → líder viu mas não incluiu.

Soluções:

1. **Aumente a taxa de prioridade.** Resubmeta com 2× a taxa atual.
2. **Reconstrua com blockhash fresco.** A vida útil do blockhash é \~60 segundos; além disso a tx é inválida independentemente de taxas.
3. **Broadcast multi-RPC.** Alguns RPCs têm melhor conectividade com líderes. Submeta a 3–5 em paralelo.
4. **Mude para bundles Jito.** Veja [`integration-guides/routing-and-mev`](/pt/integration-guides/routing-and-mev). Bundles ignoram filas de pacotes públicas.

Esqueleto de lógica de retry:

```ts theme={null}
async function submitWithRetry(buildTx, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const tx = await buildTx({
      priorityFee: basePriorityFee * Math.pow(1.5, attempt),
      blockhash:   (await connection.getLatestBlockhash()).blockhash,
    });

    try {
      const sig = await connection.sendRawTransaction(tx.serialize(), {
        skipPreflight: attempt > 0,  // pula após primeira tentativa para economizar latência
      });

      const result = await connection.confirmTransaction(sig, "confirmed");
      if (result.value.err) {
        // Erro de lógica; não retry.
        throw result.value.err;
      }
      return sig;

    } catch (e) {
      if (isExpiredError(e)) continue;  // retry
      if (isRevertError(e)) throw e;    // não retry; falha determinística
      throw e;
    }
  }
  throw new Error("submit: exhausted retries");
}
```

## 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                       |

Monitorando sinais de congestionamento:

* 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:

```
CU médio por tx:            ~250.000
Taxa do 50º percentil:      ~20.000 micro-lamports/CU
Custo por tx:               250_000 × 20_000 × 1e-6 = 5_000 lamports = 5e-6 SOL
Custo diário (1000 tx):     5e-3 SOL ≈ $1 @ $200 SOL
Custo mensal:               ~$30
```

Esse é o mínimo. Durante congestionamento, multiplique por 5–10×. Planeje \~\$150–300/mês em taxas de prioridade para um bot de fluxo constante.

Bots que devem pousar em slots específicos (liquidações, arb) pagam percentil 95º continuamente e gastam \~10× mais. Dicas de bundle Jito dominam nessa escala — frequentemente \$1000+/mês — mas a alternativa (ser front-run ou expirar) é pior.

## 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 em `txVersion: 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`](/pt/integration-guides/routing-and-mev) — estratégias de bundle Jito.
* [`integration-guides/aggregator`](/pt/integration-guides/aggregator) — montagem de transação.
* [`integration-guides/cpi-integration`](/pt/integration-guides/cpi-integration) — empilhamento de CU em CPIs compostos.
* [Documentação do programa compute budget do Solana](https://docs.solana.com/developing/programming-model/runtime#compute-budget)

Fontes:

* [Solana `getRecentPrioritizationFees` RPC](https://docs.solana.com/api/http#getrecentprioritizationfees)
* [API de taxa de prioridade Helius](https://docs.helius.dev/solana-apis/priority-fee-api)
* Benchmarks: logs de execução da mainnet (testes de integração SDK Raydium, abril de 2026).