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

# Frais de priorité et budget de calcul

> Dimensionnement correct des limites d'unités de calcul et des frais de priorité pour les transactions Raydium — repères par instruction, stratégies d'estimation et modèles de gestion de la congestion.

<Info>
  **Cette page est traduite automatiquement par IA. La version anglaise fait foi.**

  [Voir la version anglaise →](/integration-guides/priority-fee-tuning)
</Info>

<Info>
  Chaque transaction Solana définit (implicitement ou explicitement) deux paramètres : une **limite d'unités de calcul** (max CUs que la tx peut consommer ; par défaut 200 000 × nombre d'instructions jusqu'à un plafond par-transaction) et un **frais de priorité** en micro-lamports par CU. Sous-dimensionner l'un ou l'autre tue les transactions — les limites de CU trop basses causent `ProgramFailedToComplete` ; les frais de priorité trop bas font que la tx reste non confirmée jusqu'à l'expiration.
</Info>

## Les deux paramètres

```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)` — plafonne le calcul ; la transaction paie au maximum `units` CUs.
* `setComputeUnitPrice(microLamports)` — enchère sur les frais de priorité, en micro-lamports par CU. Frais de priorité totaux = `units × microLamports × 1e-6` lamports.

Calcul du coût : une limite de 250k CUs à 50k micro-lamports/CU enchérit `250_000 × 50_000 / 1e6 = 12 500` lamports ≈ 0,0000125 SOL ≈ \$0,003 à 200 \$ SOL. Les frais de priorité à cette échelle sont négligeables pour la plupart des swaps utilisateurs mais importants pour les bots effectuant 1000 tx/jour.

## Repères de CU par instruction

Repères issus des journaux d'exécution mainnet, moyennés sur les exécutions récentes. Les nombres sont approximatifs (±15 %) ; remesurer pour vos flux spécifiques.

| Instruction                      | SPL Token       | Token-2022 (simple) | Token-2022 (transfer fee) |
| -------------------------------- | --------------- | ------------------- | ------------------------- |
| 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 tick crossings) | 170 000         | 205 000             | 225 000                   |
| CLMM swap\_v2 (1 tick crossing)  | 220 000         | 255 000             | 275 000                   |
| CLMM swap\_v2 (3 tick crossings) | 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 reward slot)  | 130 000         | 155 000             | 175 000                   |
| Farm v6 deposit (3 reward slots) | 220 000         | 255 000             | 275 000                   |
| Farm v6 withdraw                 | matches deposit |                     |                           |
| Farm v6 harvest                  | matches deposit |                     |                           |
| Farm v3/v5 deposit               | 100 000         | —                   | —                         |
| LaunchLab initialize             | 100 000         | —                   | —                         |
| LaunchLab buy\_exact\_in         | 140 000         | —                   | —                         |
| LaunchLab graduate               | 250 000         | —                   | —                         |

La ligne « tick crossings » pour CLMM est la plus grande variable de CU. Si vous ne savez pas combien de ticks le swap traversera, budgétisez pour le cas le plus défavorable — 8 traversées est le plafond dur (le programme charge au maximum 8 tableaux de ticks).

### Transactions composées

Additionnez les budgets individuels et ajoutez :

* **+1 500 CU par cadre CPI** — le surcoût fixe du runtime pour chaque appel inter-programmes.
* **+20 000 CU par création d'ATA** — `create_associated_token_account` n'est pas gratuit.
* **+5 000 CU pour chaque `setComputeUnitLimit` / `setComputeUnitPrice`**.

Exemple : un swap utilisateur qui crée l'ATA de sortie et enveloppe le SOL natif :

```
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 → budget 250 000
```

Marge : fixez la limite de CU \~25 % au-dessus de l'utilisation attendue. Sous-estimer coûte toute la tx ; sur-estimer augmente juste proportionnellement le coût des frais de priorité (les frais de priorité sont `units × microLamports`, donc \~25 % au-dessus du budget coûte 25 % supplémentaires en frais de priorité).

## Estimation des frais de priorité

Le marché des frais local de Solana signifie que les frais de priorité sont **par-compte-inscriptible**. Une tx qui écrit sur un compte chaud (état de pool populaire) paie plus qu'une tx qui écrit sur un compte froid. Le niveau de frais global n'est pas la bonne métrique pour les swaps Raydium ; vous voulez les frais sur les pools spécifiques que vous touchez.

### Stratégie 1 : Estimateur du fournisseur RPC

Chaque fournisseur RPC majeur publie un estimateur de frais de priorité qui interroge les frais récents sur des comptes spécifiques :

```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;
```

Les niveaux de priorité selon la plupart des fournisseurs : `Min` / `Low` / `Medium` / `High` / `VeryHigh` / `UnsafeMax`. Mappez-les aux percentiles :

| Niveau   | Percentile | Cas d'usage                              |
| -------- | ---------- | ---------------------------------------- |
| Min      | 25e        | Trafic bot en arrière-plan, non-urgent   |
| Low      | 50e        | Swaps utilisateur normaux                |
| Medium   | 60e        | Par défaut pour les UIs portefeuille     |
| High     | 75e        | Arbitrage sensible au temps              |
| VeryHigh | 95e        | Liquidations, sorties de dernière chance |

Fournisseurs : Helius (`getPriorityFeeEstimate`), Triton (`getRecentPrioritizationFees` avec liste de comptes), QuickNode (similaire).

### Stratégie 2 : Requête RPC directe

Utilisez la RPC standard `getRecentPrioritizationFees` :

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

// fees: Array<{ slot, prioritizationFee }>
// N emplacements récents ; par défaut ~150 emplacements.

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

C'est la méthode RPC Solana vanille ; fonctionne avec n'importe quel fournisseur. Inconvénient : l'échantillon est petit (150 emplacements ≈ 60 secondes) et bruyant. Pour des estimations plus fluides, utilisez l'agrégation d'un fournisseur.

### Stratégie 3 : Auto-ajustement historique

Pour les bots fonctionnant en flux constant, suivez vos propres taux d'atterrissage vs expiration :

```
cible par pool : taux d'atterrissage 80 % à <30s
si current_land_rate < 80 % : priorityFee += 10 %
si current_land_rate > 95 % : priorityFee -= 5 %
```

Ceci se corrige plus rapidement que les estimateurs publics et capture la structure par-pool que les estimateurs publics ne voient pas toujours.

## Gestion des défaillances d'épuisement de CU

Symptôme : tx échoue avec `exceeded maximum number of instructions allowed (200000)` ou `ProgramFailedToComplete`.

Diagnostic :

```bash theme={null}
solana confirm <tx-sig> -v
# Cherchez « consumed N of M compute units » et quelle instruction a épuisé les ressources.
```

Correctifs :

1. **Augmentez la limite de CU.** Si votre tx utilisait 195k sur un budget de 200k, passez à 300k.
2. **Divisez la transaction.** Si vous atteignez le plafond de 1,4M par-tx, divisez en deux tx. Le farm `harvest then stake` est un classique à diviser quand les récompenses sont nombreuses.
3. **Réduisez les comptes.** Chaque compte inscriptible supplémentaire ajoute \~2 000 CU. L'élagage des comptes inutilisés aide dans les cas marginaux.
4. **Utilisez les tables de lookup.** Les recherches LUT coûtent \~50 CU par adresse résolue, économisant les 5 000 CU d'une référence de compte complète par entrée.

## Gestion des transactions bloquées

Symptôme : tx soumise, jamais confirmée, finit par expirer avec `BlockhashNotFound`.

Diagnostic :

* `getSignatureStatuses([sig])` retourne `null` → le leader ne l'a jamais vu.
* Retourne `{ confirmationStatus: null }` → le leader l'a vu mais ne l'a pas inclus.

Correctifs :

1. **Augmentez les frais de priorité.** Renvoyez avec 2× les frais actuels.
2. **Reconstruisez avec un blockhash frais.** La durée de vie du blockhash est \~60 secondes ; au-delà la tx est invalide indépendamment des frais.
3. **Diffusion multi-RPC.** Certaines RPCs ont une meilleure connectivité au leader que d'autres. Soumettez à 3–5 en parallèle.
4. **Basculez vers les bundles Jito.** Voir [`integration-guides/routing-and-mev`](/fr/integration-guides/routing-and-mev). Les bundles contournent les files d'attente publiques de paquets.

Squelette de logique 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,  // skip after first try to save latency
      });

      const result = await connection.confirmTransaction(sig, "confirmed");
      if (result.value.err) {
        // Logic error; don't retry.
        throw result.value.err;
      }
      return sig;

    } catch (e) {
      if (isExpiredError(e)) continue;  // retry
      if (isRevertError(e)) throw e;    // don't retry; deterministic failure
      throw e;
    }
  }
  throw new Error("submit: exhausted retries");
}
```

## Sous congestion

Quand le réseau est congestionné (les tableaux de bord Jupiter / Jito bundle montrent un arriéré, la latence RPC monte en flèche, les taux d'expiration des tx grimpent), ajustez :

| Paramètre                              | Conditions normales             | Conditions congestionnées                  |
| -------------------------------------- | ------------------------------- | ------------------------------------------ |
| Limite de CU                           | +25 % au-dessus de l'estimation | +25 % au-dessus de l'estimation (inchangé) |
| Percentile de frais de priorité        | 50e                             | 75e–95e                                    |
| Nombre de retries                      | 3                               | 5–7                                        |
| Backoff de retry                       | 500ms                           | 1000ms                                     |
| Utiliser les bundles Jito              | Optionnel                       | Fortement recommandé                       |
| Rafraîchissement du blockhash en retry | Oui                             | Oui, obligatoire                           |

Surveillance des signaux de congestion :

* Percentile 75e de frais de priorité > 500k micro-lamports : congestion.
* Percentile 50e de pourboire Jito > 0,001 SOL : congestion.
* RPC réponse p99 > 2s : problème spécifique RPC ou congestion.

## Budgétisation des frais pour les bots

Un bot de trading exécutant \~1000 tx/jour a besoin d'un budget de frais de priorité. Estimation rapide :

```
CU moyen par tx :           ~250 000
Frais 50e percentile :      ~20 000 micro-lamports/CU
Coût par tx :               250_000 × 20_000 × 1e-6 = 5_000 lamports = 5e-6 SOL
Coût quotidien (1000 tx) :  5e-3 SOL ≈ $1 @ 200 $ SOL
Coût mensuel :              ~$30
```

C'est le minimum. Pendant la congestion, multipliez par 5–10×. Prévoyez \~\$150–300/mois en frais de priorité pour un bot en flux constant.

Les bots qui doivent atterrir dans des emplacements spécifiques (liquidations, arb) paient continuellement le 95e percentile et dépensent \~10× plus. Les pourboires des bundles Jito dominent à cette échelle — souvent \$1000+/mois — mais l'alternative (être front-runné ou expirer) est pire.

## Pièges

### 1. Oublier la limite de CU

Par défaut c'est 200k CUs × (instructions dans tx). Un swap d'une seule instruction par défaut à 200k ; c'est suffisant pour CPMM sur SPL Token mais pas CLMM avec traversée de ticks ou quoi que ce soit Token-2022. Fixez-le toujours explicitement.

### 2. Frais de priorité sur le mauvais compte

Si vous estimez les frais de priorité contre le mint de token mais le compte chaud est l'état du pool, votre estimation est trop basse. L'état du pool est le bon compte inscriptible à cibler pour Raydium.

### 3. Les frais augmentent avec la limite de CU

`total_priority_fee = units × microLamports`. Augmenter `units` de 200k à 1M à 50k micro-lamports/CU multiplie les frais de priorité par 5×. Ne sur-budgétisez pas les CU juste au cas où ; mesurez.

### 4. Version tx par défaut

Les transactions legacy ont des limites de compte plus basses ; les transactions V0 avec les tables de lookup d'adresses débloquent des routes plus grandes. Le SDK utilise V0 par défaut en `txVersion: TxVersion.V0`. Ne reveniez à legacy que si vous avez besoin de compatibilité portefeuille.

### 5. `skipPreflight` cache les erreurs de CU

`skipPreflight: true` envoie la tx sans simulation locale. Vous gagnez \~100ms mais perdez les retours précoces sur l'épuisement de CU. Utilisez-le seulement sur les retries, pas à la première tentative.

## Pointeurs

* [`integration-guides/routing-and-mev`](/fr/integration-guides/routing-and-mev) — Stratégies de bundles Jito.
* [`integration-guides/aggregator`](/fr/integration-guides/aggregator) — assemblage de transactions.
* [`integration-guides/cpi-integration`](/fr/integration-guides/cpi-integration) — empilage de CU entre CPIs composés.
* [Docs du programme compute budget Solana](https://docs.solana.com/developing/programming-model/runtime#compute-budget)

Sources :

* [Solana `getRecentPrioritizationFees` RPC](https://docs.solana.com/api/http#getrecentprioritizationfees)
* [API Helius priority fee](https://docs.helius.dev/solana-apis/priority-fee-api)
* Repères : journaux d'exécution mainnet (tests d'intégration Raydium SDK, avril 2026).