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 →
LaunchLab soporta tres formas de curva seleccionadas en Initialize: constant-product (la más común, forma de reserva virtual del estándar x · y = k), linear-price y fixed-price. La fórmula del umbral de graduación se comparte entre las tres. Esta página detalla la matemática de constant-product; las formas lineal y fija se resumen al final.

Parámetros almacenados en LaunchState

Los nombres de campo en la estructura Rust coinciden con los campos PoolState descritos en accounts; las unidades anteriores son conceptuales.

Curva constant-product con reservas virtuales (curve_type = 0)

La curva predeterminada y más utilizada. Todos los lanzamientos estilo Pump usan esta forma. La curva pretende que hay una reserva de quote virtual V_q y una reserva de base virtual V_b desde el inicio (almacenadas como virtual_quote y virtual_base en PoolState), por lo que el pool efectivo se parece a un CPMM con esas reservas. Las compras siguen la matemática x · y = k:
resuelto para base_out:
Precio efectivo en base vendida s:
El mismo invariante x · y = k que LaunchLab aplica pre-graduación es entonces la curva CPMM post-graduación, por lo que la transición es mecánicamente sin problemas: el precio marginal en base_sold = base_supply_graduation es igual al precio al que se abre el pool post-graduación con (quote_vault, base_vault_remaining) como sus reservas.

Curva de precio fijo (curve_type = 1)

Una curva de precio plano. Cada compra/venta ocurre a un precio constante, configurable en Initialize:
Útil para lanzamientos justos donde el equipo quiere precios uniformes para todos los participantes independientemente de cuándo compren. La graduación se dispara cuando base_supply_graduation ha sido vendido (la relación de costo lineal hace que quote_reserve_target sea sencillo de derivar).

Curva de precio lineal (curve_type = 2)

El precio aumenta linealmente con base_sold:
Costo integrado:
Cuadrático en base_sold — los compradores tempranos pagan casi cero, los compradores tardíos pagan sustancialmente más, con el precio marginal siempre aumentando a una pendiente fija. La implementación en cadena vive en curve/linear_price.rs.

Comparación de formas de curva

Umbral de graduación

quote_reserve_target se calcula en Initialize como el quote requerido para impulsar base_sold de 0 a base_supply_graduation:
Un lanzamiento se gradúa tan pronto como quote_vault.balance ≥ quote_reserve_target. Debido a que las compras vienen en tamaños discretos, el saldo real en la graduación puede exceder ligeramente el objetivo — el excedente se convierte en liquidez adicional del lado de quote en el pool CPMM resultante.

Ejemplo trabajado — un lanzamiento cuadrático

Parámetros:
  • base_supply_max = 1_000_000_000 (1 mil millones de tokens base, 6 decimales)
  • base_supply_graduation = 800_000_000 (80% vendido dispara la graduación)
  • k = 40 (escala de precio)
  • Tarifas: 1% compra, 1% venta, divididas lp:creator:protocol = 60:20:20.
Precio inicial (s = 0): 0 (cuadrático puro comienza en cero). Precio al 50% vendido (s = 500_000_000):
Precio en graduación (s = 800_000_000):
Quote requerido para alcanzar la graduación (costo integrado):
Entonces ≈ 6.827 unidades nativas de quote (en cualquier mint de quote de 6 decimales configurado, p. ej. ~6,827 USDC si el quote es USDC). Tarifa aplicada encima:
Primera compra de 10 USDC:
  • Estado virtual: s = 0, quote_vault = 0.
  • Restar tarifa: quote_after_fee = 10 × 0.99 = 9.9.
  • Resolver (40 / (3e18)) × s³ = 9.9e6 — 9.9 USDC en unidades nativas de 6 decimales, las mismas unidades en las que está el 6.827e9 de arriba ⇒ s ≈ 9.06e7 tokens base comprados.
  • Tarifa del 1% (0.1 USDC) dividida: lp 0.06, creator 0.02, protocol 0.02. La parte de lp permanece en quote_vault; las otras dos se enrutan a sus contadores de acumulación respectivos.
Compra al 75% vendido (acercándose a la graduación): Los mismos 10 USDC compran mucho menos base ahora porque la curva es pronunciada. Resolviendo en s₀ = 750e6 con quote_in_after_fee = 9.9e6 da ∆s ≈ 4.4e5 — una reducción de ~200× en base por USDC comparado con la primera compra.

Mecánica de tarifas durante la fase de curva

En cada Buy:
  • lp_share se deja en quote_vault. Esto es lo que hace que la curva efectiva sea más ajustada (más reserva de quote contra el mismo suministro de base).
  • protocol_share incrementa LaunchState.state_data.protocol_fees_quote.
  • creator_share incrementa LaunchState.state_data.creator_fees_quote.
En Sell se aplica la misma división pero la tarifa se toma del quote_out saliente. Ambos contadores se barren a través de CollectFees (admin o creator, cada uno a su propio contador).

Precisión

  • Cantidades del lado base: u64.
  • Cantidades del lado quote: u64.
  • Cubos / productos intermedios: u128.
  • “Comprar quote exacto” y “vender quote exacto” se invierten en forma cerrada — la curva de producto constante algebraicamente, la curva de precio fijo por división, la curva de precio lineal mediante una raíz cuadrada. No hay solucionador de Newton en el programa, ni tope de iteraciones, ni error NotConverged.

Transición a CPMM

Cuando se dispara Graduate:
Para la curva de producto constante — la predeterminada de LaunchLab y el único tipo activo — cpmm_initial_price es exactamente price(base_sold), el precio marginal de la curva en el momento de la transición, así que un observador que cambia de la UI de curva a la UI de CPMM no ve ningún salto. Para una curva de precio cuadrático no lo es: el promedio integrado se sitúa por encima del precio marginal (por un factor de 4/3 en el ejemplo de arriba), así que se espera un escalón en la transición.

Dónde ir a continuación

Fuentes: