Raydium Swap: cómo funcionan los swaps de tokens en Solana y cómo construir uno

Qué ejecuta realmente un Raydium swap

Un Raydium swap no es una única llamada a un contrato a un solo pool. Es una transacción de Solana que contiene una o más instrucciones de swap, cada una dirigida a un programa de pool específico, además de la configuración de la cuenta de token asociada y cualquier envoltura o desenvuelta de SOL. La capa de enrutamiento de Raydium decide qué pools tocar y en qué orden para que el token de entrada llegue al token de salida al mejor precio disponible entre la liquidez que puede ver.

Hay tres familias de pools que encontrarás. Los pools heredados AMM v4 utilizan una curva de producto constante con un diseño adyacente al libro de órdenes de la arquitectura temprana de Raydium. Los pools CPMM son pools de producto constante con una ruta de creación más simple y sin permisos. Los pools CLMM son pools de liquidez concentrada donde la liquidez se coloca en rangos de precios, lo que puede producir diferenciales mucho más ajustados pero también un comportamiento diferente del impacto en el precio cerca de los límites del rango. Una ruta de swap puede cruzar cualquier combinación de estos.

La consecuencia práctica es que rara vez necesitas saber en qué pool cotiza un par. Lo que sí necesitas controlar es la cotización que aceptas, la tolerancia de slippage con la que firmas y el presupuesto de cómputo y la tarifa prioritaria que determinan si la transacción se confirma antes de que la cotización quede obsoleta.

• Mints de entrada y salida, más las cuentas de token asociadas de la billetera
• Una ruta a través de uno o más pools, cada uno con su propio programa
• Una restricción de salida mínima derivada de tu configuración de slippage
• Un límite de unidades de cómputo y una tarifa prioritaria para la confirmación
• Un blockhash reciente que expira en aproximadamente 60-90 segundos

Supuestos y requisitos previos antes de empezar

Esta guía asume que estás construyendo contra la mainnet de Solana con una billetera financiada y un endpoint RPC dedicado que controlas. Los endpoints públicos limitan la tasa agresivamente y causarán fallos intermitentes que parecen errores de swap pero son problemas de transporte. Si aún no has elegido un endpoint, la comparación del Asistente RPC de proveedores de Solana RPC cubre las ventajas y desventajas, y la guía de Solana devnet es el lugar adecuado para ensayar el flujo sin gastar fondos reales.

Necesitas Node.js 18 o superior para la API global fetch, un keypair de Solana y un pequeño saldo de SOL para cubrir las tarifas de transacción, las tarifas prioritarias y cualquier renta para las cuentas de token asociadas. Para swaps programáticos usarás la API de comercio de Raydium, que cotiza y construye transacciones por ti, o el SDK v2 actual de Raydium si necesitas control directo en la cadena. El SDK v1 archivado es anterior al soporte de CPMM y CLMM y no debe usarse para nuevos desarrollos.

• Un RPC_URL de Solana que controlas, idealmente con un respaldo
• Una PRIVATE_KEY o adaptador de billetera para firmar
• SOL para tarifas y, si se hace swap desde SOL, para envolver
• Una política de slippage expresada en puntos básicos
• Una estrategia de tarifa prioritaria adecuada a las condiciones actuales de la red

El modelo mental de cotizar, construir, firmar, enviar

Cada Raydium swap, ya sea que hagas clic en un botón en la interfaz o llames a una API, sigue el mismo ciclo de vida de cuatro etapas. Primero, se calcula una cotización a partir del estado actual del pool: dado un monto de entrada y mints, qué monto de salida es alcanzable y por qué ruta. Segundo, se construye una transacción que codifica esa ruta con tu billetera como pagador y tu slippage como protección de salida mínima. Tercero, la firmas localmente para que la clave privada nunca salga de tu entorno. Cuarto, la envías a un nodo RPC, que la transmite al clúster.

La idea crítica es que las etapas uno y dos son orientativas y la etapa cuatro es autoritativa. La cotización refleja el estado del pool en el momento en que se calculó. Entre la cotización y la confirmación, otros traders mueven los pools, por lo que el resultado en la cadena puede diferir de la cotización. Tu tolerancia de slippage es el contrato entre ambos: le dice al programa cuánto peor que la salida cotizada aceptarás antes de que la transacción se revierta. Establecerla demasiado ajustada causa fallos en mercados volátiles; establecerla demasiado holgada te expone al impacto de precio tipo sándwich.

Obtener una cotización y construir un swap con la API de comercio

La API de comercio de Raydium expone un endpoint de cómputo que devuelve una cotización y una transacción serializada en una sola llamada. El ejemplo siguiente utiliza marcadores de posición para el endpoint RPC y el keypair; sustituye tus propios valores. Intercambia una cantidad fija de lamports de SOL por USDC, establece una tolerancia de slippage de 50 puntos básicos y solicita una tarifa prioritaria. Trata la transacción devuelta como opaca: fírmala, envíala y confírmala en lugar de intentar analizar sus instrucciones.

import { Connection, Keypair, VersionedTransaction } from '@solana/web3.js';
import bs58 from 'bs58';

const RPC_URL = process.env.RPC_URL!;
const wallet = Keypair.fromSecretKey(bs58.decode(process.env.PRIVATE_KEY!));
const connection = new Connection(RPC_URL, 'confirmed');

const WSOL = 'So11111111111111111111111111111111111111112';
const USDC = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v';

async function swapSolToUsdc(lamportsIn: number) {
  const url = new URL('https://transaction-v1.raydium.io/compute/swap-base-in');
  url.searchParams.set('inputMint', WSOL);
  url.searchParams.set('outputMint', USDC);
  url.searchParams.set('amount', String(lamportsIn));
  url.searchParams.set('slippageBps', '50');
  url.searchParams.set('txVersion', 'V0');
  url.searchParams.set('wallet', wallet.publicKey.toBase58());

  const quote = await (await fetch(url)).json();
  if (!quote.success) throw new Error(JSON.stringify(quote));

  const tx = VersionedTransaction.deserialize(
    Buffer.from(quote.data.transaction, 'base64')
  );
  tx.sign([wallet]);

  const signature = await connection.sendTransaction(tx, {
    maxRetries: 3,
    skipPreflight: false,
  });
  const latest = await connection.getLatestBlockhash('confirmed');
  const result = await connection.confirmTransaction(
    { signature, ...latest },
    'confirmed'
  );
  return { signature, result, quote: quote.data };
}

swapSolToUsdc(10_000_000).then(console.log).catch(console.error);

Verificar el resultado del swap en la cadena

Una firma confirmada no es prueba de que recibiste el monto esperado. Siempre lee los metadatos de la transacción y compara los cambios reales de saldo de tokens con la cotización. El fragmento siguiente obtiene la transacción analizada e imprime los saldos antes y después para las cuentas de token de la billetera, que es la verdad fundamental de lo que se movió.

async function inspectSwap(signature: string) {
  const tx = await connection.getParsedTransaction(signature, {
    maxSupportedTransactionVersion: 0,
    commitment: 'confirmed',
  });
  if (!tx) throw new Error('transaction not found');

  const pre = tx.meta!.preTokenBalances ?? [];
  const post = tx.meta!.postTokenBalances ?? [];
  const owner = wallet.publicKey.toBase58();

  const rows = post
    .filter((b) => b.owner === owner)
    .map((b) => {
      const before = pre.find((p) => p.accountIndex === b.accountIndex);
      const delta =
        Number(b.uiTokenAmount.uiAmountString) -
        Number(before?.uiTokenAmount.uiAmountString ?? 0);
      return { mint: b.mint, delta };
    });

  console.table(rows);
  console.log('fee lamports:', tx.meta!.fee);
  console.log('compute units:', tx.meta!.computeUnitsConsumed);
}

inspectSwap('<SIGNATURE>');

Registrar mediciones de swap que puedas comparar

Debido a que el estado del pool y las condiciones de la red cambian constantemente, un solo swap te dice poco. Para evaluar una estrategia de enrutamiento, una política de tarifas prioritarias o un proveedor de RPC, ejecuta una serie controlada y registra los mismos campos cada vez. La tabla siguiente es una plantilla; complétala con tus propios valores observados en lugar de confiar en los números de otros.

Ejecuta al menos diez iteraciones por configuración e informa la mediana y la tasa de fallos, no el mejor caso. El tiempo de confirmación debe medirse desde el envío hasta el compromiso confirmado usando un reloj monotónico. Si estás comparando endpoints RPC, mantén constantes la billetera, el monto y el slippage y varía solo el endpoint para que la comparación sea significativa.

Solución de problemas de swaps que fallan o entregan menos

La mayoría de los fallos de swap se dividen en un pequeño número de categorías, y cada una tiene una firma distinta en los registros de la transacción. Leer los registros antes de cambiar cualquier cosa te evitará perseguir la solución equivocada.

Slippage excedido es el más común. El programa devuelve un error que indica que se violó la restricción de salida mínima, lo que significa que el pool se movió más allá de tu tolerancia entre la cotización y la ejecución. Amplía el slippage moderadamente, reduce el tamaño de la operación o vuelve a cotizar inmediatamente antes de enviar. Blockhash no encontrado significa que tu transacción expiró antes de confirmarse; obtén un blockhash nuevo y reintenta, e investiga por qué el envío fue lento. Fondos insuficientes para renta aparece cuando la billetera no tiene SOL para crear una cuenta de token asociada para un token que nunca ha tenido. Presupuesto de cómputo excedido significa que la ruta necesitaba más unidades de cómputo que el límite; aumenta el límite en lugar de la tarifa prioritaria.

Los tiempos de espera y las respuestas 429 de la capa RPC son fallos de transporte, no fallos de swap. Se agrupan en endpoints públicos compartidos y desaparecen cuando pasas a un nodo dedicado. Si los ves repetidamente, la solución es infraestructura, no parámetros de transacción.

• Slippage excedido: vuelve a cotizar, amplía la tolerancia o reduce el tamaño
• Blockhash no encontrado: actualiza el blockhash y reintenta rápidamente
• Fondos insuficientes para renta: financia la billetera con SOL
• Presupuesto de cómputo excedido: aumenta el límite de CU
• 429 o tiempo de espera: cambia a un endpoint RPC dedicado

Limitaciones y compensaciones de cada enfoque de swap

La interfaz alojada es la vía más rápida para un trader humano pero no ofrece control programático y depende de un frontend que no operas. La API de comercio es la ruta programática más simple y maneja el enrutamiento entre tipos de pool por ti, pero introduce una dependencia de un servicio alojado y te da visibilidad limitada sobre la construcción de la ruta. El SDK v2 te da control directo sobre las instrucciones y la selección de pools, lo cual importa para la creación de mercado, el arbitraje y la lógica de tarifas personalizada, a costa de un código significativamente mayor y la responsabilidad de la selección de ruta.

Los pools CLMM merecen una consideración aparte. La liquidez concentrada puede ofrecer mejores precios dentro de un rango, pero el impacto en el precio cerca de los bordes del rango puede ser discontinuo, y una ruta que parece barata en el momento de la cotización puede degradarse rápidamente. Para swaps grandes, dividir entre rutas o usar un enfoque tipo límite puede ser preferible a una única orden de mercado. Ninguno de estos enfoques elimina la exposición a MEV; las tarifas prioritarias y la configuración de slippage cambian la economía pero no eliminan el riesgo.

Endurecimiento operativo para servicios de swap en producción

Si estás ejecutando swaps como un servicio en lugar de como una operación puntual, la fiabilidad de tu capa RPC domina todo lo demás. Un nodo dedicado de Solana elimina el problema de vecino ruidoso de los endpoints compartidos y te da un comportamiento consistente de sendTransaction bajo carga. Combínalo con un endpoint de respaldo y una política de reintentos que distinga los errores de transporte reintentables de los errores de programa terminales. Instrumenta cada swap con los campos de la tabla de medición para que puedas detectar regresiones en el tiempo de confirmación o la tasa de fallos antes que tus usuarios.

Para equipos que operan a escala, un nodo dedicado con rendimiento predecible suele ser más barato que el tiempo de ingeniería dedicado a depurar fallos intermitentes en infraestructura compartida. Revisa las opciones de nodo dedicado y el modelo de precios de RPC para dimensionar el compromiso según tu volumen de transacciones esperado.

Próximos pasos de un swap funcional a uno fiable

Una vez que un solo swap tiene éxito de principio a fin, el trabajo pasa de la corrección a la fiabilidad y el costo. Ensaya el flujo completo en devnet, luego ejecuta la serie de mediciones en mainnet con montos pequeños antes de escalar. Compara tus tiempos de confirmación observados y tasas de fallos entre al menos dos configuraciones de RPC para que sepas qué variable importa realmente. Si aún estás seleccionando un endpoint, comienza con la comparación de proveedores de Solana RPC y la guía más amplia de endpoints RPC, luego valida tu elección con tus propias mediciones en lugar de afirmaciones de marketing.

A partir de ahí, explora el directorio de redes para otras cadenas que puedas necesitar soportar, y considera si tu servicio de swap debería cotizar y construir localmente con el SDK para una menor latencia. El tema consistente es que el rendimiento de un Raydium swap es una función del estado del pool, los parámetros de la transacción y la calidad del RPC en conjunto; optimizar solo uno de los tres deja a los otros dos como tu cuello de botella.