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 →
El modelo de cuentas de Solana es lo más importante que debes entender antes de leer el código de Raydium. A diferencia de Ethereum, donde el estado vive junto al código del contrato, los programas de Solana son completamente sin estado: todo el estado vive en “cuentas” separadas sobre las que los programas operan. Cada pool, posición y bóveda de Raydium es una cuenta — entender cómo funcionan esas cuentas hace que el resto de la documentación tenga sentido.

​
La división fundamental: programas versus cuentas

​
Programas

Un programa en Solana es código ejecutable — un binario compilado cargado desde un archivo, desplegado en una Pubkey, e invocable mediante transacciones. Los programas no tienen estado asociado; contienen solo lógica. Los programas de Raydium:
  • CPMM: CPMMoo8L3F4NbTegBCKVNunggL7H1Zpdmwpwh8KMoZ0F
  • CLMM: CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK
  • AMM v4: 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8
Cada uno es un binario fijo. El programa no “recuerda” nada entre invocaciones.

​
Cuentas

Una cuenta es una fila de datos en la cadena. Cada cuenta tiene:
  • pubkey — su dirección.
  • owner — el programa que la posee (controla las escrituras).
  • data — los bytes sin procesar.
  • lamports — saldo de SOL (1 SOL = 1.000.000.000 lámports).
  • rent_epoch — campo heredado de cobro de renta (ignorado desde que la exención de renta se hizo obligatoria).
Cuando consultas un pool de Raydium, estás leyendo una o más cuentas. Cuando se ejecuta un swap, el programa CPMM lee/escribe varias cuentas — el estado del pool, los bóvedas, el estado de observación, y las cuentas de token del usuario.

​
Propiedad

Cada cuenta es propiedad de exactamente un programa. Solo el código de ese programa puede modificar el campo data de la cuenta. Un usuario puede modificar lamports (enviar/recibir SOL) en una cuenta que pueda firmar, pero modificar data requiere que el programa propietario lo haga en su nombre. Ejemplos:
  • Tu billetera de usuario: propiedad del Programa del Sistema. Los lámports viven aquí; firmas para transferir.
  • Tu cuenta de token USDC: propiedad del Programa SPL Token. La instrucción transfer del programa de token actualiza el saldo.
  • Una cuenta de estado del pool de Raydium: propiedad del programa CPMM. Solo las instrucciones de CPMM pueden modificar las reservas, tarifas, etc.
  • El PersonalPositionState del NFT de posición de Raydium: propiedad del programa CLMM.
“Propiedad de” es estricto: si el programa A escribe en una cuenta propiedad del programa B, el tiempo de ejecución de Solana rechaza la transacción.

​
Renta y exención de renta

Crear una cuenta consume espacio de almacenamiento. Solana cobra renta por ese espacio, pero desde 2020 todas las cuentas nuevas deben ser exentas de renta — lo que significa que contienen suficientes lámports para que la renta que deberían durante 2 años esté prepagada. En la práctica:
  • Una cuenta exenta de renta vive para siempre.
  • Cerrar la cuenta devuelve los lámports al firmante que cierra.
Para una cuenta de 165 bytes (por ejemplo, una cuenta de token SPL), la exención de renta es ~0,00204 SOL. Para un estado del pool CPMM de Raydium de 1.440 bytes, es ~0,011 SOL.

​
Costos de renta de Raydium

CuentaTamañoRenta
CPMM PoolState~1.440 B~0,011 SOL
CLMM PoolState~1.500 B~0,012 SOL
CLMM TickArray~9.000 B~0,063 SOL
CLMM PersonalPositionState~280 B~0,003 SOL
ATA165 B~0,002 SOL
Vault (Token Account)165 B~0,002 SOL
La creación de pool requiere renta para varias cuentas a la vez — por eso la creación de pool CPMM cuesta ~0,15 SOL en total.

​
Cuentas de datos versus ejecutables

Las cuentas vienen en dos sabores:

​
Cuentas de datos

Contienen estado (reservas del pool, saldos de tokens, posiciones del usuario). executable = false. Esta es la gran mayoría.

​
Cuentas ejecutables

Contienen bytecode del programa. executable = true. Estos son programas (CPMM, CLMM, etc.). Los programas no tienen datos más allá de su bytecode.

​
Cuentas derivadas del programa (PDAs)

Una PDA es una cuenta de datos cuya dirección se deriva determinísticamente de un programa y algunas semillas — no existe clave privada para esta dirección. Solo el programa de derivación puede firmar en nombre de una PDA mediante invoke_signed. Raydium usa PDAs extensivamente:
  • PDAs de estado del pool: derivadas de [poolTypeDiscriminator, mintA, mintB, ammConfig].
  • PDAs de bóveda: derivadas de [pool, mint].
  • PDA de estado de observación: derivada de [observationSeed, pool].
Las PDAs permiten a Raydium crear cuentas en direcciones predecibles sin gestionar claves. Cualquiera puede calcular la dirección PDA para un pool conocido dadas las semillas. Consulta solana-fundamentals/pdas-and-cpis.

​
Transacciones y referencias de cuentas

Cada transacción de Solana lleva una lista explícita de cuentas que va a leer/escribir. El tiempo de ejecución aplica:
  • Las cuentas listadas se pueden leer o escribir (según su bandera is_writable).
  • Las cuentas no listadas no se pueden tocar.
Para un swap de Raydium, la lista de cuentas de la transacción incluye: 
[readonly] programa CPMM
[writable] estado del pool
[readonly] configuración de amm
[readonly] autoridad del pool (PDA)
[writable] bóveda de entrada
[writable] bóveda de salida
[writable] ATA de entrada del usuario
[writable] ATA de salida del usuario
[readonly] mint de entrada
[readonly] mint de salida
[readonly] programa de token de entrada
[readonly] programa de token de salida
[writable] estado de observación
[signer,writable] usuario
Esta enumeración explícita es por qué las transacciones de Solana son rápidas y paralelizables — el tiempo de ejecución puede determinar transacciones sin conflictos de antemano.

​
Tamaño de cuenta y diseño de datos

Cada cuenta de Raydium tiene un tamaño fijo o limitado. El diseño se define en código (structs de Rust con #[repr(C)]) y está documentado en sdk-api/anchor-idl. Los programas de Anchor preponen un discriminador de 8 bytes a cada cuenta que crean, derivado de hash("account:<StructName>")[0..8]. Esto permite a los clientes identificar el tipo de una cuenta solo leyendo los primeros 8 bytes — crucial para escaneos de getProgramAccounts que enumeran todas las cuentas de un tipo.

​
Leer un estado del pool de Raydium

Mediante el SDK: 
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
Mediante RPC sin procesar + diseño: 
const accountInfo = await connection.getAccountInfo(poolId);
const data = accountInfo.data;
// Salta los primeros 8 bytes (discriminador), luego analiza según el diseño del struct.
const poolState = CpmmPoolStateLayout.decode(data.slice(8));
El diseño está en src/raydium/cpmm/layout.ts en la fuente del SDK.

​
Ejemplo trabajado: lectura de una cuenta de token

Leamos el saldo de USDC de un usuario. 
import { Connection, PublicKey } from "@solana/web3.js";
import { getAssociatedTokenAddressSync, AccountLayout } from "@solana/spl-token";

const connection = new Connection("https://api.mainnet-beta.solana.com");
const user       = new PublicKey("YourUserWallet...");
const usdcMint   = new PublicKey("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");

// 1. Calcula la dirección de ATA (derivación estilo PDA).
const ata = getAssociatedTokenAddressSync(usdcMint, user);

// 2. Lee la cuenta.
const accountInfo = await connection.getAccountInfo(ata);
if (!accountInfo) {
  console.log("ATA aún no existe (el usuario nunca ha tenido USDC).");
  return;
}

// 3. Verifica que el propietario es el programa SPL Token.
console.assert(accountInfo.owner.toBase58() === "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA");

// 4. Decodifica los datos.
const parsed = AccountLayout.decode(accountInfo.data);
console.log("Saldo (unidades más pequeñas):", parsed.amount.toString());
console.log("Mint:",                          new PublicKey(parsed.mint).toBase58());
console.log("Propietario:",                   new PublicKey(parsed.owner).toBase58());
Este patrón — derivar dirección, obtener cuenta, verificar propietario, decodificar — se aplica a cada lectura en cadena, incluyendo pools de Raydium.

​
Por qué esto importa para Raydium

El modelo de cuentas da forma al diseño de Raydium:
  • El estado del pool es una cuenta única — todo sobre un pool (mints, reservas, tarifas, admin) vive en una cuenta propiedad del programa del pool.
  • Los tokens LP son cuentas de token SPL estándar — Raydium delega la tokenización al programa SPL Token.
  • Los arreglos de tick se dividen en fragmentos — CLMM no puede tener un arreglo de ticks único y creciente porque las cuentas tienen tamaño asignado fijo; en su lugar, usa PDAs de TickArray fragmentadas.
  • Los NFTs de posición son NFTs de Metaplex — las posiciones de CLMM son NFTs estándar según Metaplex; el estado de la posición es una PDA separada.
Entender esto te permite responder correctamente preguntas “¿dónde vive X?”:
  • “¿Dónde están las reservas del pool?” → dos cuentas de bóveda (cuentas de token) propiedad del programa SPL Token, con autoridad delegada a una PDA del programa del pool.
  • “¿Dónde están los datos de tick para CLMM?” → una serie de PDAs de TickArray, cada una cubriendo 60 ticks consecutivos.
  • “¿Dónde está mi stake de granja?” → una PDA de UserLedger derivada de [user, farmId], propiedad del programa de granja.

​
Referencias

Fuentes: