Saltar al contenido principal

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 fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.Ver versión en inglés →
Una transacción en Solana es una lista de instrucciones que se ejecutan de forma atómica. Entender la estructura de la transacción — instrucciones, cuentas, firmantes, presupuesto de cómputo — es requisito previo para construir, depurar u optimizar cualquier cosa con Raydium. Esta página cubre esa estructura, los límites que la restringen, y cómo se apilan las dos categorías de tarifas (tarifas de red de Solana, tarifas del protocolo Raydium) en un swap real.

Anatomía de la transacción

Una transacción en Solana tiene tres componentes principales:
  • Mensaje: la lista ordenada de instrucciones, las cuentas que referencian, y el blockhash reciente.
  • Firmas: una por cada firmante, atestiguando que la transacción fue autorizada.
  • Blockhash reciente: demuestra que la transacción es reciente; las transacciones con blockhashes obsoletos (>150 slots de antigüedad) son rechazadas.

Instrucciones

Una instrucción especifica:
  • program_id — el programa a invocar.
  • accounts — las cuentas (y sus indicadores de escribible/firmante) que el programa puede tocar.
  • data — bytes opacos que el programa interpreta.
Una única transacción puede contener múltiples instrucciones. Se ejecutan en orden; si alguna falla, todas las instrucciones anteriores se revierten (atómico). Una transacción típica de swap en Raydium incluye:
  1. ComputeBudget::SetComputeUnitLimit — aumentar el límite de CU por defecto.
  2. ComputeBudget::SetComputeUnitPrice — establecer una tarifa de prioridad.
  3. CreateAssociatedTokenAccount opcional — crear el ATA de salida si el usuario no tiene uno.
  4. Raydium::SwapBaseInput — ejecutar el swap.
  5. CloseAccount opcional — cerrar un ATA de SOL envuelto.
El SDK empaca estas instrucciones automáticamente a través de raydium.trade.swap().

Cuentas en transacciones

Toda cuenta tocada por cualquier instrucción en la transacción debe estar listada en las claves de cuenta de la transacción. Cada cuenta está marcada:
  • Firmante / no firmante: ¿debe el propietario de la cuenta firmar la transacción?
  • Escribible / solo lectura: ¿puede la transacción modificar la cuenta?
El tiempo de ejecución (runtime) hace cumplir estas marcas: un programa que intente escribir en una cuenta no escribible falla, y el runtime rechaza transacciones con firmantes requeridos faltantes. Para un swap CPMM, la lista de cuentas tiene ~13 entradas (ver solana-fundamentals/account-model). Los swaps CLMM con múltiples cruces de tick pueden tener 20+.

Límite de tamaño de transacción

Solana limita las transacciones a 1232 bytes incluyendo firmas, mensaje y encabezados. Esta es la obstrucción más común para transacciones complejas — el CLMM de Raydium con enrutamiento multi-hop regularmente se acerca a este límite. Desglose de un swap típico de Raydium de ~1000 bytes:
ComponenteTamaño
Firma64 B
Contador de firmas1 B
Encabezado del mensaje3 B
Blockhash32 B
Claves de cuenta (13 × 32 B)416 B
Instrucciones (4 × ~100-150 B)400–600 B
Total~900–1100 B

Tablas de búsqueda de direcciones (ALT)

Las ALT permiten que una transacción referencie cuentas por un índice de 1 byte en una tabla publicada en lugar de una clave pública completa de 32 bytes. Esto comprime una transacción drásticamente:
  • Una transacción que referencia 20 cuentas directamente: ~640 B de claves públicas.
  • La misma transacción usando ALT: ~20 B de índices + referencias de ALT.
Raydium mantiene ALT para rutas de swap CPMM/CLMM en mainnet. El SDK las usa automáticamente. Los agregadores que construyen rutas multi-hop dependen de ellas mucho.
import { VersionedTransaction } from "@solana/web3.js";

// El SDK construye una tx v0 (versionada) con referencias de ALT
const { transaction } = await raydium.trade.swap({ /* ... */ });
// transaction es una VersionedTransaction, no una Legacy Transaction.

Presupuesto de cómputo

Cada transacción tiene un presupuesto de unidad de cómputo (CU). Excederlo termina la ejecución y falla la transacción.
  • Por defecto: 200,000 CU por transacción.
  • Máximo: 1,400,000 CU por transacción (aumentado vía ComputeBudget::SetComputeUnitLimit).
  • Límite por bloque: 48M CU por bloque (a nivel de protocolo).
Consumo típico de CU de Raydium (ver integration-guides/priority-fee-tuning para la tabla completa):
InstrucciónCU
Swap CPMM~140,000
Swap CLMM (sin cruces de tick)~170,000
Swap CLMM (4 cruces de tick)~320,000
Farm v6 stake~130,000
Creación de pool CPMM~250,000
Siempre establece un límite de CU explícito vía ComputeBudget; de lo contrario, obtendrás el valor por defecto de 200k, que es demasiado bajo para la mayoría de instrucciones de Raydium.
import { ComputeBudgetProgram } from "@solana/web3.js";

tx.add(
  ComputeBudgetProgram.setComputeUnitLimit({ units: 300_000 }),
);
Si estableces tu límite de CU demasiado bajo, la transacción falla cuando alcanza el límite; si lo estableces demasiado alto, riesgas ser deprioritizado bajo congestión (y, dependiendo del modelo de precio, pagas por cómputo que nunca usaste).

Tarifas de prioridad

Más allá de la tarifa de transacción base (5000 lamports por firma), los validadores priorizan cada vez más transacciones que pagan tarifas de prioridad: una propina por CU en microlamports.
priority_fee = compute_unit_price (micro-lamports) × compute_unit_limit
Ejemplo: 10,000 µL/CU × 300,000 CU = 3,000,000 µL = 0.003 SOL. Las tarifas de prioridad son locales — solo afectan el ordenamiento dentro de un bloque; no mejoran tu probabilidad de ser incluido vs. no. Establecer una tarifa de prioridad razonable es esencial durante la congestión.
tx.add(
  ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 10_000 }),
);
Ver integration-guides/priority-fee-tuning para cómo dimensionar esto dinámicamente.

Límites de contador de instrucciones y contador de cuentas

Más allá del límite total de 1232 bytes:
  • Máximo de cuentas por transacción: 128.
  • Máximo de cuentas por instrucción (CPI): 64.
  • Máximo de instrucciones por transacción: sin límite duro, limitado solo por el límite de tamaño.
  • Profundidad máxima de CPI: 4 (un programa puede llamar otro, que puede llamar otro, 4 niveles de profundidad).
Los swaps CLMM de Raydium que cruzan varios arrays de tick pueden ejercer presión contra el límite de cuentas — un único swap toca el pool, bóvedas de entrada/salida, ATA de entrada/salida, varios arrays de tick, posiblemente cuentas extras del programa de transfer-hook, más referencias obligatorias de presupuesto de cómputo / sistema / programa token. Los diseños que componen Raydium vía CPI (p. ej., auto-compounders) necesitan dar cuenta de esto.

Categorías de tarifas en un swap de Raydium

Una transacción de swap del usuario paga tarifas en dos categorías:

Tarifas de red de Solana

Pagadas a validadores en SOL.
  • Tarifa de firma base: 5000 lamports por firma. Casi siempre 1 firma = 0.000005 SOL.
  • Tarifa de prioridad: CU-price × CU-limit en microlamports. Varía con la congestión; ver integration-guides/priority-fee-tuning.
Estas tarifas van a los validadores, no están relacionadas con Raydium, y se cobran incluso para transacciones fallidas (excepto en algunos casos extremos de tarifas de prioridad).

Tarifas del protocolo Raydium

Deducidas de la cantidad del swap.
  • Tarifa de swap: porcentaje de entrada (CPMM típicamente 0.25%, CLMM 0.01%–1% por tier). Dividida entre LP y destinos del protocolo. Ver ray/protocol-fees.
Estas tarifas son internas a la contabilidad de Raydium — el usuario las ve como una cantidad de salida menor que la que produciría un pool sin tarifas.

Ejemplo: $1000 USDC → SOL vía CPMM tier 0.25%

Categoría de tarifaCantidadVa a
Tarifa de firma base0.000005 SOL (~$0.0007)Validador
Tarifa de prioridad (10k µL × 300k CU)0.003 SOL (~$0.45)Validador
Tarifa de swap CPMM (0.25%)$2.50LP + protocolo
Costo total del usuario~$2.95
El slippage (impacto de precio + movimiento de mercado) no es una tarifa pero afecta el resultado final.

Transacciones versionadas

Solana tiene dos formatos de transacción:
  • Legacy: el formato original, sin soporte para ALT.
  • v0 (Versionado): soporta ALT, extensible a versiones futuras.
Todas las herramientas modernas de Solana usan v0. El SDK de Raydium emite transacciones v0 por defecto.
// Construyendo una tx v0 directamente
import { VersionedTransaction, TransactionMessage } from "@solana/web3.js";

const msg = new TransactionMessage({
  payerKey:        owner.publicKey,
  recentBlockhash: blockhash,
  instructions:    [ /* ... */ ],
}).compileToV0Message([lookupTableAccount]);

const tx = new VersionedTransaction(msg);
tx.sign([owner]);

Frescura del blockhash

Una transacción debe incluir un blockhash de los últimos ~150 slots (~60 segundos). Más allá de esa ventana, los validadores lo rechazan. Para bucles de reintento, obtén un blockhash fresco en cada reintento:
async function sendWithRetry(tx, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    const { blockhash, lastValidBlockHeight } = await connection.getLatestBlockhash();
    tx.message.recentBlockhash = blockhash;
    tx.sign([owner]);
    try {
      return await connection.sendRawTransaction(tx.serialize());
    } catch (e) {
      if (i === maxRetries - 1) throw e;
    }
  }
}
Ver integration-guides/priority-fee-tuning para el patrón completo de reintento con tarifas de escalada.

Ejecución paralela

Solana ejecuta transacciones sin conflictos en paralelo en validadores multi-core. Dos transacciones entran en conflicto si ambas escriben la misma cuenta. Implicaciones para Raydium:
  • Dos swaps en el mismo pool no pueden ejecutarse en paralelo — ambos escriben el estado del pool.
  • Un swap en Pool A y un swap en Pool B se ejecutan en paralelo si las listas de cuentas no se superponen.
  • Una transacción de solo lectura nunca bloquea un escritor en la misma cuenta (solo lectura es concurrente consigo mismo pero no con escrituras).
Por eso Solana puede sostener alto rendimiento en DEX a pesar de la serialización de un único pool.

Niveles de confirmación de transacción

Al enviar una transacción, eliges un nivel de confirmación:
NivelEsperaFinalidad
processed~400 msNo finalizado; puede revertirse
confirmed~1 sSupermayoría votó
finalized~13 sSupermayoría enraizada
Para UX de swap, confirmed es estándar. Para operaciones manejando valor grande (creación de pool, top-ups de recompensa), finalized es más seguro.
await connection.sendAndConfirmTransaction(tx, [owner], {
  commitment: "confirmed",
});

Simulación

Solana soporta simular una transacción antes de enviarla:
const sim = await connection.simulateTransaction(tx);
console.log(sim.value.logs);
console.log(sim.value.unitsConsumed);
El SDK de Raydium usa simulación internamente al calcular getBestSwapInfo para verificar que la ruta elegida realmente funcione. La simulación no es gratis — consume capacidad de RPC — pero atrapa errores antes de pagarlos.

Referencias

Fuentes: