Matemáticas de AMM v4

Invariante de producto constante con la convención de comisiones de AMM v4, conversión de precio de reserva a libro de órdenes, construcción de cuadrícula de órdenes objetivo y el paso de liquidación de PnL.

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 invariante

El pool mantiene coin_reserve × pc_reserve = k, donde (después de la eliminación de OpenBook en 2026-07):

coin_reserve = coin_vault_balance - accrued_pnl_coin
pc_reserve   = pc_vault_balance   - accrued_pnl_pc

Hay dos cosas a notar:

1. Las reservas ahora son solo de bóveda. El término histórico de orden abierta (tokens que el pool tenía en depósito como órdenes limitadas de OpenBook) ha sido eliminado — en la práctica era cero mucho antes de la eliminación. Puedes calcular k directamente desde los saldos de bóveda en cadena.
2. La acumulación de PnL (need_take_pnl_*) se resta para que la curva se conserve cuando el administrador retira comisiones. El mismo principio que la exclusión de protocol_fees_* en CPMM.

El programa calcula esto mediante calc_total_without_take_pnl_no_orderbook (la variante anterior consciente del libro de órdenes ha desaparecido).

Cada operación Swap* garantiza que k' ≥ k después de agregar la parte de comisión del LP nuevamente en las reservas.

​

Convención de comisiones

AMM v4 usa comisiones de razón (pares numerador/denominador) en lugar de la convención 1/1_000_000 de CPMM / CLMM. La estructura Fees en cadena (ver Fees::initialize en el código fuente del programa) tiene valores predeterminados de:

Fees {
  min_separate_numerator:    5,
  min_separate_denominator:  10_000,   //  5/10_000 = 0.05%

  trade_fee_numerator:      25,
  trade_fee_denominator:    10_000,    // 25/10_000 = 0.25% — usado para precios de órdenes limitadas de OpenBook

  pnl_numerator:            12,
  pnl_denominator:          100,       // 12/100   = 12%   — parte del protocolo DE la comisión de swap

  swap_fee_numerator:       25,
  swap_fee_denominator:     10_000,    // 25/10_000 = 0.25% — comisión bruta en swaps de ruta AMM
}

Interpretación (valores predeterminados publicados en mainnet):

• Comisión de swap total: swap_fee = amount_in × 25 / 10_000 = 0.25% de la entrada bruta.
• Parte del protocolo: pnl_numerator / pnl_denominator = 12 / 100 = 12% de la comisión de swap, lo que resulta en 0.25% × 12% = 0.03% del volumen. Esta parte se acumula en los contadores de PnL y es retirada por WithdrawPnl.
• Parte del LP: el 88% restante de la comisión de swap, lo que resulta en 0.25% × 88% = 0.22% del volumen. Se queda en el pool e infla k.
• Sin parte de fondo. AMM v4 no tiene la división de comisión de fondo de CPMM/CLMM.

Ten en cuenta que pnl_numerator / pnl_denominator es una fracción de la comisión, no del volumen de operaciones — una lectura errónea común de estos nombres de campo.

trade_fee_numerator / trade_fee_denominator (también 25 / 10_000) fue usado históricamente por la integración de OpenBook al calcular precios inclusivos de comisión para la cuadrícula de órdenes limitadas del AMM. Con el código de OpenBook eliminado, este campo es vestigial; la comisión de swap activa es swap_fee_*.

Las desviaciones de estos valores predeterminados son raras pero existen en algunos pools heredados; siempre lee las comisiones de AmmInfo.fees antes de cotizar.

​

Matemáticas de swap directo (ruta AMM)

El caso más simple: el usuario realiza un swap contra las bóvedas del pool sin interactuar con OpenBook. Las reservas internas del pool (incluidas las asignaciones en libro) son el denominador.

SwapBaseIn (entrada exacta):

amount_after_fee = amount_in − ceil(amount_in × swap_fee_numerator / swap_fee_denominator)
amount_out = amount_after_fee × out_reserve
           / (in_reserve + amount_after_fee)
require(amount_out >= minimum_amount_out)

Las reservas utilizadas aquí son los saldos de bóveda (menos PnL acumulado). Históricamente, la fórmula también agregaba los tokens que el AMM tenía bloqueados en órdenes de OpenBook; ese término ha sido eliminado — las reservas efectivas ahora equivalen a los saldos de bóveda brutos menos PnL pendiente. La ruta MonitorStep / liquidación implícita que solía actualizar el lado de OpenBook ha sido eliminada.

SwapBaseOut (salida exacta):

amount_in_after_fee = ceil(in_reserve × amount_out / (out_reserve − amount_out))
amount_in_gross     = ceil(amount_in_after_fee × swap_fee_denominator
                            / (swap_fee_denominator − swap_fee_numerator))
require(amount_in_gross <= maximum_amount_in)

​

Interacción con libro de órdenes (histórica)

Eliminada. La construcción de cuadrícula descrita en esta sección refleja cómo AMM v4 originalmente reflejaba la curva en un mercado de OpenBook. La integración de OpenBook — incluyendo el crank MonitorStep y la lógica de cuadrícula build_orders — ha sido eliminada del programa (actualización 2026-07). Las matemáticas a continuación se preservan puramente como contexto histórico para lo que las cuentas target_orders / amm_open_orders en cadena fueron una vez dimensionadas.

Separado de los swaps de usuario, AMM v4 históricamente colocaba una cuadrícula de órdenes limitadas en el mercado de OpenBook. La cuadrícula se calculaba a partir de parámetros de AmmInfo:

• depth — número de niveles de precio por lado.
• amount_wave — unidad base de tamaño por nivel.
• min_size, coin_lot_size, pc_lot_size — restricciones del mercado de OpenBook.
• state_data.swap_acc_coin_fee, swap_acc_pc_fee — contadores de comisión acumulada desde el último TakePnl.

El programa deriva precios por nivel caminando desde el precio de curva actual en pasos de razón constante:

price_level(k) = curve_price × (1.0001 ^ k)       # conceptualmente
size_level(k)  = amount_wave × f(depth, k)        # afilado por profundidad

Los precios y tamaños exactos se determinan por target_orders calculados en build_orders y comparados con amm_open_orders en cada MonitorStep. Cualquier divergencia resulta en cancelaciones + nuevos posts. Las órdenes recién completadas en OpenBook se liquidan en las bóvedas del pool en la siguiente operación que actualiza el lado de OpenBook.

Los integradores rara vez necesitan calcular la cuadrícula — el mantenedor de Raydium la mantiene — pero es útil saber que:

• Un pool con liquidez significativa en libro tiene esa liquidez contribuyendo a k, no inactiva.
• Un mercado de OpenBook obsoleto (cola de eventos llena, cranks bloqueados) previene actualizaciones de cuadrícula; el AMM puede entonces cotizar precios que divergen del libro de órdenes visible hasta el siguiente crank.

​

Paso de liquidación (PnL)

La parte del protocolo del 0.03% se acumula en state_data.need_take_pnl_coin y state_data.need_take_pnl_pc. TakePnl mueve estas cantidades fuera de las bóvedas al destino especificado por el administrador, luego pone a cero los contadores.

Propiedad crucial: las reservas en el invariante siempre se calculan menos PnL acumulado, por lo que TakePnl no mueve la curva. Esto coincide con la convención de CPMM.

​

Ejemplo trabajado

Estado del pool:

• coin_reserve = 1_000_000_000_000 (1,000,000 lado coin; 6 decimales)
• pc_reserve = 2_000_000_000_000 (2,000,000 lado pc; 6 decimales)
• Comisiones: swap = 25/10_000 predeterminado, pnl = 3/10_000.

Usuario: SwapBaseIn entrada exacta 1_000_000_000 coin (1,000 coin).

swap_fee        = ceil(1_000_000_000 * 25 / 10_000)    = 2_500_000
amount_after_fee =                                      997_500_000

amount_out = amount_after_fee * pc_reserve
           / (coin_reserve + amount_after_fee)
           = 997_500_000 * 2_000_000_000_000
           / (1_000_000_000_000 + 997_500_000)
           ≈ 1_995_015_009  (1,995.015 pc)

// De la comisión de swap de 2_500_000:
pnl_share = 2_500_000 * 3 / 25  = 300_000    (va al protocolo vía need_take_pnl_coin)
lp_share  = 2_500_000 * 22 / 25 = 2_200_000  (se queda en coin_reserve)

new coin_reserve = 1_000_000_000_000 + 1_000_000_000                 = 1_001_000_000_000
                   (de los cuales 300_000 es PnL acumulado)
  curve coin_reserve = 1_001_000_000_000 − 300_000 = 1_000_999_700_000
new pc_reserve   = 2_000_000_000_000 − 1_995_015_009                 ≈ 1_998_004_984_991

k' = curve_coin_reserve * new_pc_reserve
   ≈ 2.000_002_701E24
k  = 1_000_000_000_000 * 2_000_000_000_000
   = 2.0E24
k' > k   ✓

La parte del LP (2_200_000) no se desglosa en ningún lugar — es simplemente el residual que eleva k'.

​

Reglas de precisión

• Las multiplicaciones de reservas usan u128; las divisiones finales redondean hacia cero.
• swap_fee redondea hacia arriba (para que el pool no cobre de menos).
• amount_in para SwapBaseOut redondea hacia arriba (para que el usuario no pague de menos).
• Los pools con ratios de reserva extremos pueden alcanzar ZeroTradingTokens en entradas muy pequeñas; la misma convención que CPMM.

​

Limitaciones vs CPMM

• Las reservas de AMM v4 ahora son solo de bóveda, por lo que puedes cotizar directamente desde los saldos de bóveda (menos need_take_pnl_*) — el requisito anterior de agregar los montos open_orders.free / open_orders.locked ya no se aplica. La cotización del SDK / API sigue siendo la opción más simple.
• AMM v4 no expone un TWAP estructurado en cadena. Los consumidores externos que quieran un precio respaldado por AMM-v4 deben calcularlo ellos mismos a partir de registros de operaciones.
• Token-2022 no es compatible.

​

Dónde ir a continuación

• products/amm-v4/instructions — donde SwapBaseIn, Deposit, etc. se conectan.
• products/amm-v4/fees — mecánica completa de comisiones, detalles de TakePnl.
• algorithms/constant-product — la derivación compartida.

Fuentes:

• Código fuente del programa Raydium AMM — raydium-io/raydium-amm
• Módulo Liquidity del SDK v2 de Raydium