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

# Modelo de cuentas

> La arquitectura centrada en cuentas de Solana — las cuentas contienen estado, los programas son código sin estado que opera sobre cuentas. Renta, propiedad, cuentas de programa versus cuentas de datos, y qué significa todo esto cuando lees el estado de los pools de Raydium.

<Info>
  **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 →](/solana-fundamentals/account-model)
</Info>

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

| Cuenta                     | Tamaño    | Renta       |
| -------------------------- | --------- | ----------- |
| 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 |
| ATA                        | 165 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`](/es/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`](/es/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:

```ts theme={null}
const pool = await raydium.cpmm.getPoolInfoFromRpc({ poolId });
console.log(pool.poolInfo);
```

Mediante RPC sin procesar + diseño:

```ts theme={null}
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.

```ts theme={null}
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

* [`solana-fundamentals/programs-and-anchor`](/es/solana-fundamentals/programs-and-anchor) — cómo los programas procesan cuentas.
* [`solana-fundamentals/pdas-and-cpis`](/es/solana-fundamentals/pdas-and-cpis) — derivación de PDA y CPI.
* [`solana-fundamentals/transactions-and-fees`](/es/solana-fundamentals/transactions-and-fees) — cómo se referencian las cuentas en transacciones.
* [`sdk-api/anchor-idl`](/es/sdk-api/anchor-idl) — diseños de cuentas para los programas de Raydium.

Fuentes:

* [Documentos de Cuentas de Solana](https://docs.solana.com/developing/programming-model/accounts).
* [Programa SPL Token](https://spl.solana.com/token) — donde viven las cuentas de token.