Skip to main content
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 →
A partir de la actualización 2026-07, la dependencia de OpenBook / Serum de AMM v4 ha sido eliminada — ninguna instrucción lee o escribe el estado de OpenBook. Las cuentas de mercado que se muestran a continuación se conservan solo como marcadores de posición en los diseños de instrucciones v1 heredadas (aceptadas pero ignoradas) y como campos de referencia en AmmInfo. Usa los puntos de entrada de intercambio V2, que las omiten completamente. Esta página aún agrupa las cuentas en secciones “propiedad del pool” y “OpenBook (heredado)” para leer transacciones antiguas.

Inventario

Un pool AMM v4 registra un mercado vinculado en AmmInfo en la creación. La imagen completa: Nota: el prefijo “serum” se mantiene en el IDL y los nombres de campos de AMM v4 por compatibilidad hacia atrás. Estas cuentas ya no son funcionales después de la eliminación de OpenBook.

AmmInfo

La cuenta de estado raíz del pool. Grande (≈ 752 bytes) porque lleva referencias de pool y OpenBook en línea.
El diseño de la estructura no ha cambiado (compatible a nivel de bytes) por lo que los deserializadores existentes siguen funcionando, pero después de la eliminación de OpenBook los campos marcados como DEPRECADO arriba ya no se escriben — los contadores de volumen swap_* se congelan en su último valor. Para análisis de volumen, usa registros de transacciones en lugar de estos campos. Solo need_take_pnl_* y pool_open_time se mantienen activamente.
Campos orientados al integrador:
  • coin_vault, pc_vault — las bóvedas de Token SPL del pool. coin es token_0 por convención de Serum/OpenBook (base), pc es token_1 (cotización).
  • coin_decimals, pc_decimals — coincidiendo con los mints.
  • open_orders, target_orders, market — campos de referencia heredados. Aún presentes en AmmInfo y aún se pasan posicionalmente en los diseños de instrucciones v1, pero el programa ya no los lee ni valida. Los puntos de entrada de intercambio V2 los omiten.
  • fees.swap_fee_numerator / swap_fee_denominator — la comisión comercial combinada. Por defecto 25 / 10_000 = 0.25%.
  • status — un único estado enumerado u64 que controla las operaciones, no una máscara de bits. Configurable por el administrador a través de SetParams con param = 0 (Status). Ver Estado más abajo.
  • lp_amount — el total interno de LP del pool. No es igual a lp_mint.supply: está exactamente un token LP entero (10^coin_decimals unidades base) por encima, porque esa cantidad se cuenta en la inicialización pero nunca se acuña. Toda la matemática pro-rata usa lp_amount, así que úsalo tú también.
  • amm_owner — se escribe en la creación a partir de la clave de administrador codificada del programa, no a partir del creador.
  • state_data.need_take_pnl_* — delta entre comisiones acumuladas brutas y lo que se ha barrido. TakePnl pone estos a cero.

El cableado de OpenBook

Eliminado. La dependencia de OpenBook / Serum ha sido eliminada del programa (actualización 2026-07). Las cuentas descritas en esta sección ya no se validan ni se usan. Permanecen como campos de referencia en AmmInfo y como marcadores de posición posicionales en los diseños de instrucciones v1 heredadas. Usa los puntos de entrada de intercambio V2 (SwapBaseInV2 / SwapBaseOutV2) que omiten estas cuentas completamente.
Cuando llamas a una instrucción heredada v1 SwapBaseIn / SwapBaseOut, Deposit o Withdraw, el número de cuentas aún debe coincidir con el diseño antiguo (las cuentas de mercado ocupan sus posiciones históricas), pero su contenido ya no se verifica — no se emite ningún CPI contra ellas. El código nuevo debe usar las variantes de intercambio V2, que no toman estas cuentas en absoluto.
El amm_open_orders del AMM es una cuenta propiedad de OpenBook que contiene el estado de orden limitada del pool en este mercado: órdenes activas, saldos liquidados, referentes, etc. amm_target_orders es del lado del AMM: contiene la cuadrícula prevista del AMM (precio/tamaño para cada ranura de orden) para que el programa pueda comparar barato contra lo que está actualmente publicado y colocar / cancelar la diferencia.

PDAs de autoridad

Hay exactamente un PDA amm_authority para todo el programa AMM v4. Su semilla es trivial (["amm authority"]) y su bump se almacena en cada AmmInfo. Esta autoridad firma todos los movimientos de tokens para todos los pools AMM v4.
No hay una segunda autoridad con alcance de pool: este único PDA cubre todo lo que el programa firma. Su bump es 254 en mainnet y se refleja en cada AmmInfo como nonce; WithdrawExcessLamports lo vuelve a derivar con ese nonce codificado.

Bóvedas

Las bóvedas de Token SPL del pool son cuentas de token estándar cuyo owner es amm_authority. No son ATAs — sus direcciones son PDAs derivadas en Initialize2 a partir de [AMM_V4_PROGRAM_ID, market, "coin_vault_associated_seed"] y [AMM_V4_PROGRAM_ID, market, "pc_vault_associated_seed"]. El mint no es una semilla, y tampoco lo es amm_id. Las direcciones se almacenan en AmmInfo; la derivación es una curiosidad única. Token-2022 no es compatible. El programa codifica el ID del programa de Token SPL para todos los movimientos de bóveda. Intentar vincular un pool AMM v4 a un mint de Token-2022 falla en Initialize2 con InvalidSplTokenProgram.

Mint de LP

Un mint clásico de Token SPL cuya autoridad es amm_authority. El suministro total rastrea la propiedad de LP del pool; quemar LP devuelve tokens de ambas bóvedas pro-rata. Sí existe un espejo en el estado: AmmInfo.lp_amount. No es igual al suministro del mint — está exactamente un token LP entero (10^coin_decimals unidades base) por encima, porque esa cantidad se cuenta en la inicialización pero nunca se acuña. Cada cálculo pro-rata del programa divide por lp_amount, así que usa ese campo en lugar del suministro en cadena del mint.

Estado

AmmInfo.status es un único estado enumerado u64, no una máscara de bits. Compáralo por igualdad — un cliente que comprueba status & 1 clasifica mal todos los pools activos, porque el estado normal de operación es 6, que tiene el bit 0 activado. Initialize2 escribe 7 cuando open_time está en el futuro y 6 en caso contrario; un pool en 7 pasa por sí mismo a 6 en el primer swap en o después de state_data.pool_open_time. Un valor fuera de 0..=7 hace que AmmStatus::from_u64 entre en pánico. El multisig de Raydium establece el estado a través de SetParams con param = 0 (Status); solo se aceptan los valores 1–7. (AdminCancelOrders ha sido eliminado.)

Observación / oráculo

AMM v4 no tiene una cuenta de observación dedicada, y desde la eliminación de OpenBook tampoco hay estado de libro de órdenes del que derivar una. Si necesitas un TWAP de Raydium con soporte de programa, usa CPMM o CLMM — ambos mantienen un búfer de anillo ObservationState. En caso contrario, indexa los logs de swap fuera de cadena.

Derivar las cuentas de un pool desde cero

Las cuentas de pool de AMM v4 son PDAs simples cuya clave es el mercado vinculado — no son keypairs con semilla, ni PDAs por par. Todas ellas usan la misma forma de tres semillas [AMM_V4_PROGRAM_ID, market, <label>] bajo AMM_V4_PROGRAM_ID:
El mercado vinculado es la única semilla variable, que es la razón por la que un mercado se corresponde con exactamente un pool de AMM v4. El SDK y la API precomputan estos para ti; ver Liquidity.getAssociatedPoolKeys de raydium-sdk-v2. En la práctica, los integradores leen el conjunto completo de cuentas del pool desde GET https://api-v3.raydium.io/pools/info/ids?ids=<POOL_ID> o desde el SDK. La derivación manual rara vez es necesaria.

Referencia rápida del ciclo de vida

Los pools y sus cuentas persisten indefinidamente. Incluso si la liquidez se retira completamente, AmmInfo permanece.

Qué leer dónde

Fuentes: