El lanzamiento en dos posiciones
Desde la enmienda del 2026-09-12 no hay bonding curve. Todo el supply va a liquidez de
Uniswap v4 bloqueada, desde la propia transacción de creación. En el código desde el
2026-09-28: LiquidityLock.launchMarket lo hace todo dentro de la transacción de creación
del mercado, y los tests fijan el precio de apertura que lee la Lens, 3 401 582 525 wei por
token.
Por qué desapareció la curva
La antigua curva era un producto constante sobre reservas virtuales:
x = VIRTUAL_ETH + netReserve (3.75 ETH + lo que entró)
y = TOKEN_RESERVE - tokensSold (1.1 B − lo que salió)
Eso es exactamente una posición de liquidez concentrada: las reservas virtuales de v3/v4 son ese desplazamiento. La correspondencia no es una aproximación, es la misma ecuación escrita de otra forma.
Lo que se consigue al eliminarla: ninguna migración (el momento más arriesgado del protocolo), ninguna comisión de graduación que extraer, un solo camino de comisiones en lugar de dos, y mercados enrutables por los agregadores desde su primer bloque.
Las dos bandas
tick 195000
apertura"] -->|banda 1 · 700M tokens · 7.535 ETH| B["FDV 34.091 ETH
tick 171960
10x"] B -->|banda 2 · 300M tokens · sin límite| C["tick −887220
techo de precio"]
| Banda 1 | Banda 2 | |
|---|---|---|
| Tokens | 700 000 000 | 300 000 000 |
| Ticks | [171960, 195000] |
[−887220, 171960] |
| Profundidad | 7,535 ETH para recorrerla | 14,5 ETH a 2× · 45,7 ETH a 20× · 144,6 ETH a 200× |
tickSpacing 60, y sin comisión de LP.
Son los ajustes de lanzamiento por defecto. Desde el 2026-10-05, el supply, los tokens de
la banda 1 (la banda 2 se lleva el resto), el tick de lanzamiento, los ticks inferiores de
las dos bandas, el tick spacing y la comisión de LP forman un único ajuste del owner de
StockFun, setLaunchConfig en la factory, que se aplica a los mercados creados después.
Rechaza una forma que ningún pool podría contener: una banda vacía, ticks fuera del
spacing o desordenados, un tick spacing o una comisión de LP fuera de rango, bandas cuya
liquidez no cabe en un solo tick. Cada pool conserva la forma, la comisión de LP y el tick
spacing con los que se creó: el lock registra sus ticks, y la Lens da la comisión de LP y
el tick spacing de cada mercado.
La parte delicada: el precio de apertura
Ambas posiciones contienen solo tokens en el lanzamiento. Eso es lo que permite al protocolo no adelantar ningún ETH: todo el ETH que el pool llegue a contener proviene de los compradores.
Para que una posición contenga solo tokens, el precio actual debe estar en el extremo superior de su rango o por encima. De ahí:
sqrtStartX96 = TickMath.getSqrtPriceAtTick(BAND1_UPPER); // not sqrt(raw FDV)
El tick exacto de la FDV de lanzamiento es 194 977,95, y el tick utilizable más cercano
por encima es 195 000. Derivar sqrtStart de la FDV bruta situaría el precio dentro de
la banda 1, y la comprobación NotSingleSided de LiquidityLock rechazaría el depósito.
La cuantización deja una FDV efectiva de 3,4016 ETH en lugar de 3,409, una desviación del −0,22 %.
Cómo se ve en la práctica
Compras sucesivas de 2 ETH desde el lanzamiento, con los ajustes por defecto:
| Gastado | FDV | Supply adquirido |
|---|---|---|
| 2 ETH | ~27 600 $ | 36,1 % |
| 4 ETH | ~50 400 $ | 53,3 % |
| 10 ETH | ~164 000 $ | 74,8 % |
| 50 ETH | ~2,78 M $ | 93,9 % |
El primer ticket se lleva el 36,1 % del supply, frente al 36,99 % con la antigua curva. El lanzamiento se comporta como antes, con menos de un punto de diferencia, que era el criterio con el que se eligieron los parámetros.
El techo estructural de una banda
El ETH que una banda puede absorber, si el 100 % del supply estuviera en ella, es exactamente la media geométrica de sus dos FDV:
$$ E{\max} = \sqrt{\text{FDV}{\text{inicio}} \times \text{FDV}_{\text{fin}}}
$$
Eso es lo que restringe los parámetros: no puedes elegir libremente el precio de lanzamiento, el techo de la banda y la profundidad; el número de tokens cierra el sistema.
El modo de cierre
Como los tokens, el lock no es upgradeable: su código es lo que mantiene la liquidez en los pools. Desde el 2026-10-02 tiene una salida, el modo de cierre, para el caso de que el proyecto cierre.
- El anuncio. El owner de StockFun llama a
end(), y el lock registra, públicamente, la fecha de dentro de 30 días. A partir de ese momento no se puede lanzar ningún mercado nuevo, ni crear la posición de$STOCKFUN, así que ningún mercado recibe menos que el aviso previo completo. El trading y el cobro de comisiones continúan - El aviso previo. Durante 30 días, todos los pools siguen operando. El owner puede
cancelarlo en cualquier momento con
cancelEnd(), y los lanzamientos se reanudan - La recuperación. Una vez transcurridos los 30 días, el owner puede sacar todas las
posiciones de un pool —las dos bandas de un mercado, la posición única de
$STOCKFUN— y enviar su ETH y sus tokens, donaciones no cobradas incluidas, a cualquier dirección (recoverLiquidity). Un pool recuperado ya no cobra nada y deja de contar como bloqueado; una cancelación posterior lo deja vacío
Los 30 días son el aviso previo de los holders. Son una constante del lock, END_DELAY, no
un ajuste: el único plazo fijo del protocolo.
Fuera del modo de cierre, nada alcanza las posiciones. Desde el 2026-10-05 el lock guarda
la parte de un cobro de comisiones que su destinatario rechazó, para ese destinatario,
hasta que cualquiera la pague (payOwed); y el owner de StockFun puede sacar lo que se
envió al lock por error (rescue, rescueClaims, rescueNft): cualquier token, el ETH
por encima de las partes que guarda, claims de v4, un NFT. El lock no tiene ninguna
llamada genérica: a través del PoolManager, se podría llegar a la recuperación del modo
de cierre sin sus 30 días.