$STOCKFUN

El token del protocolo. Captura valor de todo el launchpad y se aplica a sí mismo la regla que impone a los demás.

El flywheel

Cada trade, en cada mercado, acredita la línea del buyback, un 0,5 % por defecto, al saldo del buyback en el hook, adeudado al BuybackBurner. El burner retira ese saldo al inicio de cada burn, y cualquiera puede enviárselo con claimBuybackFees(); desde el 2026-10-01, el hook ya no lo envía durante el trade. El burner no tiene owner propio, ni withdraw, ni sweep: mientras el pool de $STOCKFUN esté bloqueado, lo único que su código actual puede hacer con el ETH que recibe es comprar $STOCKFUN y enviarlo a la dirección de burn, que está fijada en el código. Desde el 2026-10-05 el owner de StockFun tiene una palanca sobre él, rescue: un token que se le envió por error, en cualquier momento, y su ETH solo cuando ningún burn pueda ya gastarlo, antes de que se designe el mercado del protocolo o una vez que el modo de cierre haya recuperado el pool de $STOCKFUN.

«Recomprado y luego quemado» es, por tanto, una propiedad del código más que una promesa, mientras el burner no reciba un upgrade: desde el 2026-10-02, el owner de StockFun puede hacerle un upgrade, con efecto inmediato, como a todos los módulos salvo los tokens y el lock de liquidez.

Su propio mercado

$STOCKFUN tiene un TreasuryVault, con el basket Index, alimentado por el mismo 2 % que cualquier mercado y distribuido por airdrop a los holders de $STOCKFUN como cualquier tesorería. El protocolo se aplica a sí mismo su propia regla. Ningún $STOCKFUN está reservado para el equipo. Sus ciclos de airdrop dejan fuera la dirección de burn, como en cualquier mercado, y al operador del lanzamiento, que tiene todo el supply durante los pocos bloques entre la acuñación y el lock: desde el 2026-10-05, el script de lanzamiento incluye esa dirección en la lista antes de la acuñación.

El buyback que alimenta ese vault no es un defecto del modelo, es el flywheel: una compra de $STOCKFUN hecha por el propio burner paga un 5 %, del que un 2 % vuelve al vault del protocolo y un 0,5 % al siguiente burn. La serie converge.

Lo que lo distingue

Los esquemas son los ajustes por defecto del impuesto, que el owner de StockFun puede cambiar: consulta Comisiones.

El contrato

$STOCKFUN es un ERC-20 simple y no es upgradeable. Todo su supply, 1 000 000 000 de tokens por defecto, se acuña una sola vez, en el constructor, para el operador del lanzamiento, que lo deposita entero en la posición bloqueada: nada queda reservado para el equipo. No tiene mint, ni función de burn, ni pausa, ni blacklist, ni lógica propia más allá de un setter y sus rescues, que pertenecen al owner de StockFun. El setter, setRecorder, designa el registrador de tenencias al que se notifica cada cambio de saldo, ya que su tesorería también se distribuye por airdrop a sus holders. Si la notificación falla, la transferencia falla: es la única excepción deliberada a la regla de aislamiento del protocolo, consulta Arquitectura. Los rescues, desde el 2026-10-05, solo sacan lo que se envió por error a la propia dirección del token.

El script de lanzamiento, LaunchProtocol, exige que el contrato del airdrop esté designado antes en la factory. Fija la lista de exclusiones de $STOCKFUN, con el operador del lanzamiento, en la dirección que tomará el token, luego despliega allí el token y deposita su supply en la posición bloqueada. Desde el 2026-10-06, una ejecución que se detuvo antes de que se designara el mercado del protocolo se reanuda con el token y el vault que dejó, que el script comprueba primero, en lugar de acuñar un segundo $STOCKFUN. Consulta Despliegue.

El burn

«Quemar» significa enviar a 0x000000000000000000000000000000000000dEaD. El supply total nunca se mueve: lo que disminuye es el supply circulante, y cualquiera puede verificar la diferencia con una llamada a balanceOf.

Es más honesto que un burn real: nada se esconde tras un totalSupply cambiante, todo es un saldo público.