Estado de avance

Este libro describe el protocolo tal como se ha decidido. Parte de lo que describe aún no está en el código. Esta página dice con precisión qué parte.

Decidido e implementado

• La comisión, un 5 % por defecto, y sus dos esquemas
• El TreasuryVault, sus límites de oráculo y su ausencia de retiro
• El BuybackBurner y el flywheel de $STOCKFUN
• El modo de emergencia, inmediato desde el 2026-10-05
• El rail cross-chain hacia Robinhood Chain, preparado y probado en simulación, en un solo sentido desde que se eliminó el camino de vuelta el 2026-09-28, y ejecutado de punta a punta en dos testnets sobre LayerZero el 2026-10-06 (más abajo)
• El lanzamiento single-sided del token de protocolo $STOCKFUN
• La eliminación del buyback del creador, el 2026-09-28
• El rediseño del lanzamiento, el 2026-09-28: ya no hay bonding curve ni graduación; cada mercado se crea con sus dos posiciones bloqueadas, 700M y 300M por defecto, y la compra opcional del creador en la misma transacción
• La comisión de creación, 0,001 ETH por defecto, un ajuste del owner desde el 2026-10-05
• El anti-snipe decreciente y la whitelist del creador, 20 direcciones como máximo por defecto, exentas cuando operan a través del router oficial; el router oficial sigue siendo modificable por el owner
• Las comisiones del creador guardadas en el hook, mercado por mercado, y reclamadas por el creador; desde el 2026-10-01, también las partes del equipo y del buyback, pagadas mediante reclamaciones que cualquiera puede disparar
• Las tenencias registradas onchain para cada token de mercado y para $STOCKFUN, desde el 2026-10-02 por el registrador de tenencias, al que cada token llama en cada transferencia. El 2026-10-01, con el registro todavía en los tokens, costaba unos 52 000 a 61 000 de gas más por transferencia entre dos wallets, por encima de los 20 000 a 40 000 estimados cuando se decidió. El PoolManager de Uniswap no se registra, así que un swap paga por el lado del trader y, desde el 2026-10-01, una escritura para el supply registrado: 113 529 de gas por una compra a través del router y 137 250 por una venta, para una wallet que ya tiene el token (125 862 y 150 416 antes de las correcciones del 2026-10-01, que además eliminaron dos envíos de cada trade)
• Sin comisión de LP de Uniswap en los pools de StockFun por defecto, desde el 2026-09-29: el impuesto es todo el costo de un trade
• Las correcciones de la auditoría de seguridad del 2026-09-29, aplicadas el 2026-09-30 y el 2026-10-01: liquidez solo desde el lock de liquidez; partes del equipo y del buyback reclamadas fuera de cualquier trade; conversiones por montos que indica el keeper, con el efectivo reservado acción por acción; el supply registrado, el denominador del airdrop, en cada token; un rail de Robinhood Chain en el que un mercado ya no bloquea un lote y un hub remoto en pausa sigue aplicando los cambios de rol. Cada hallazgo corregido tiene tests de regresión
• El pipeline de seguridad del 2026-10-01, una segunda ronda de auditoría que completó varias de esas correcciones: en Robinhood Chain, una ruta v3 se ejecuta pool a pool y un ticket canónico de contabilidad no paga más registros de los que puso en la cola; una emergencia que deja el efectivo de un vault por debajo de sus reservas las anula; el keeper retiene n−1 unidades en la última acción de un basket. Cada corrección tiene tests de regresión
• El rediseño upgradeable del 2026-10-02: todos los módulos salvo los tokens, el lock de liquidez y el deployer de los vaults espejo detrás de un proxy, upgradeables por el owner de StockFun con efecto inmediato; los vaults, un proxy por mercado, en las dos cadenas; los tokens reducidos a un ERC-20 simple con un único setter, setRecorder, y, desde el 2026-10-05, sus rescues; el registro de tenencias en su propio módulo; el proxy del hook minado con los 14 permisos v4; el modo de cierre del lock de liquidez, con su aviso previo de 30 días; las disposiciones del almacenamiento registradas y verificadas por un script. Un swap cuesta unos 27 000 de gas más, medido de forma aislada: una compra 237 190 de gas en lugar de 210 105, una venta 285 031 en lugar de 258 278
• El contrato del airdrop, el 2026-10-04: AirdropDistributor en Ethereum, upgradeable y ligado a la factory, alimentado por sendToAirdrop en los dos vaults, y la ruta del airdrop en el hub remoto. Ciclos diarios cuya ventana se cierra a las 13:00 UTC, partes calculadas a partir de las tenencias registradas, una reclamación por cada holder a su cargo, sin vencimiento, tope ni mínimo, una lista de exclusiones por token, acciones apartadas para una ventana sin tenencias elegibles, el modo de emergencia. Los 514 tests fuera de las suites de fork pasan, invariante con estado incluido; LayerZero se sustituye por mocks en los tests. Codex revisó el diseño, el código y dos veces las correcciones, y su comprobación final no encontró ningún bug. No desplegado
• Las decisiones del 2026-10-05: ninguna asignación al equipo, todo el supply de $STOCKFUN en su posición bloqueada; una transferencia de emergencia inmediata y un cambio de adaptador inmediato; cada cifra del protocolo, un ajuste onchain del owner, en las dos cadenas, con los valores actuales por defecto, y cada pool conserva la comisión de LP y el tick spacing con los que se creó. Codificado y probado, no desplegado
• La regla de diseño del fundador del 2026-10-05: un fallo nunca bloquea el resto, y cada contrato que puede guardar fondos tiene una palanca para sacar lo que se queda atascado, con una única excepción deliberada, la notificación del token a su registrador de tenencias; consulta Arquitectura. El cuarto bucle de auditoría de ese día la llevó al código: entregas del bridge que nunca bloquean otro mercado, reclamaciones que pagan lo que pueden, cada tramo de compra, cada acción del airdrop y cada mercado de un lote por separado, deudas guardadas para un destinatario que rechaza ETH en lugar de un mercado detenido, una Lens que lee un vault a la vez, y rescues en los módulos sin modo de emergencia. Codificado y probado, no desplegado
• Los cinco bucles de auditoría del 2026-10-05 y sus correcciones, entre ellas: cuentas liquidadas tras una transferencia de emergencia, nunca pagadas con cargo a otro mercado; el lote del bridge reservado al keeper, y el despliegue previo de los vaults espejo, al keeper y al owner; un registrador designado en un token en circulación que ya no bloquea el trading ni mide una ventana anterior a él; el operador del lanzamiento de $STOCKFUN excluido del airdrop antes de la acuñación; los tickets del rail canónico cotizados a la tarifa base; la comprobación del almacenamiento en cada nivel; la regla anterior. Cada corrección tiene un test de regresión; al final del día pasan 614 tests de Foundry, con tres suites en fork omitidas a falta de RPC. No desplegado
• El paso del airdrop en el keeper y la pantalla de reclamación de la dapp, el 2026-10-05, con las nuevas tareas del keeper: pagar lo que el hook y el lock guardan para un destinatario, alertar sobre lo que sigue fallando, planificar cada tramo de acción por separado, un archivo de estado que sobrevive a los reinicios y el cobro diario de las comisiones de LP. No desplegado
• La pasada offchain del quinto bucle de auditoría, el 2026-10-06: el keeper convierte el ETH de un vault una vez por ventana del airdrop, como se decidió el 2026-09-27, registra cada transacción antes de esperar su recibo y mantiene un bloqueo en su carpeta de estado, y ya no paga una atestación de Ondo por una compra que solo puede fallar; un basket contiene como máximo cinco acciones; la Lens lleva el estado y las deudas de cada vault; el script de lanzamiento de $STOCKFUN reanuda una ejecución detenida; la app cuenta el ETH que se debe a un vault, deja margen en las reclamaciones para una acción aún en camino, recuerda una acción que su token rechazó, y nunca muestra una cifra sin leer como nada. Pasan 619 tests de Foundry, con tres suites en fork omitidas a falta de RPC. Un ensayo en una cadena privada el mismo día ejecutó el keeper de punta a punta a lo largo de dos ventanas y superó sus seis escenarios. Consulta El keeper y La dapp. No desplegado
• Los hallazgos del ensayo, corregidos el 2026-10-06: el keeper coloca las acciones que el contrato del airdrop tiene apartadas para un mercado incluso cuando su vault no tiene nada nuevo que enviar, de modo que un mercado que tuvo un trade y luego se quedó inactivo ya no mantiene su primer airdrop fuera del alcance de sus holders; registra un vault encontrado por debajo del umbral por su ventana, nunca por su propio reloj; y el archivo de despliegue local se comprueba frente a la cadena antes de que lo usen el keeper, la app o el worker. Pasan 620 tests de Foundry, con tres suites en fork omitidas a falta de RPC. Consulta El keeper. No desplegado
• El sexto bucle de auditoría, corregido el 2026-10-06: en el bridge canónico, el keeper vigila cada ticket hasta saber que se ejecutó, sea cual sea el abono de su transferencia, y abona una transferencia solo por los eventos del hub remoto; el USDC de un vault sale una vez después de cada conversión de su ETH y como máximo una vez por ventana en los demás casos, como se decidió para el ETH el 2026-09-27, mientras las compras en Robinhood Chain siguen haciéndose en cada pasada; una búsqueda de acciones apartadas que no puede colocar nada, para un vault sin nada que enviar, ya no se envía cada día; un vault por debajo del umbral se comprueba con un saldo leído después del cierre de la ventana; cada vault se cotiza en su propio router; la app marca el precio de $STOCKFUN como «(last read)» mientras la Lens no puede leerlo. Consulta El keeper. No desplegado
• El séptimo bucle de auditoría, corregido el 2026-10-06: el keeper solo envía al airdrop lo que vale lo que cuesta enviarlo, y el polvo que el bridge no puede transportar ya no cuenta como algo que enviar; lee cada ticket canónico empezando por el recibo de su creación, de modo que un depósito vivo nunca se toma por ejecutado; cada búsqueda de logs se detiene unos pocos bloques por debajo del último bloque; se niega a arrancar con un RPC que sirve otra cadena que la configurada; su webhook de alertas guarda y vuelve a enviar lo que no aceptó; un ajuste vacío toma su valor por defecto. El Worker de datos de la app lee cada contrato upgradeable por separado, muestra el volumen de 24 horas como desconocido mientras fallan sus lecturas de trades, y comprueba la cadena de cada endpoint; el gráfico de precios sitúa cada punto en su momento. Pasan 620 tests de Foundry (615 fuera de los archivos de fork, y los cinco de la suite en fork de Robinhood Chain sobre su RPC público; las tres suites en fork de Ethereum, omitidas a falta de RPC); pasan los 277 tests del keeper, los 51 del paquete compartido, los 9 del back end y los 137 del worker. Consulta El keeper y La dapp. No desplegado
• Las protecciones de los feeds de precios en Robinhood Chain, codificadas el 2026-10-06: el oráculo retiene el precio de una acción mientras su token indica que su oráculo está en pausa por una operación corporativa, activada para todas las acciones, y todos los precios mientras el feed de disponibilidad del secuenciador de Chainlink indica que el secuenciador está caído o acaba de volver. No existe ningún feed así para Robinhood Chain, así que esa segunda comprobación queda desactivada en el despliegue, por una elección explícita, hasta que se publique uno. Ambas son ajustes del owner, desactivadas en Ethereum. Consulta El rail de Robinhood. No desplegado
• El octavo bucle de auditoría, corregido el 2026-10-06: el formulario de lanzamiento de la app solo ofrece los baskets leídos de la cadena y vuelve a comprobar el elegido antes de enviar; el keeper sigue un lote del bridge una vez que su bloque tiene unos pocos bloques de profundidad, distingue el polvo del bridge de una acción cuya comisión no se puede cotizar, guarda una sola alerta en espera por alerta distinta, retiene un archivo de estado de otra cadena hasta haber leído la cadena de su RPC, exige los dos identificadores de cadena, lee un ticket unos pocos bloques por debajo del último y cuenta una sola vez la apertura del rail local; el keeper, su preflight y su inspector, el Worker y la app conocen ahora las protecciones de los feeds de precios; la ventana de trades del Worker nunca retrocede, y el panel de trading cobra a una wallet de la whitelist el impuesto normal. Pasan 640 tests de Foundry (633 fuera de los archivos de fork, y los siete del archivo en fork de Robinhood Chain sobre su RPC público; las tres suites en fork de Ethereum, omitidas a falta de RPC); pasan los 306 tests del keeper, los 51 del paquete compartido, los 9 del back end y los 155 del worker. Consulta El keeper y La dapp. No desplegado
• El gas de la entrega del airdrop con la actualización Glamsterdam de Ethereum, que Sepolia activó el 2026-10-06: la decisión del fundador de ese día, con el keeper simulando cada entrega y eligiendo su gas dentro de los límites que el owner de StockFun fija en el hub remoto, y volviendo a ejecutar una entrega que siga atascada, con una alerta en un segundo fallo. Codificado y probado, aplicado mediante upgrade en la ejecución en testnet, no desplegado en mainnet. Consulta El keeper
• El noveno bucle de auditoría, corregido el 2026-10-06, con los hallazgos de la ejecución de LayerZero en testnet: el keeper lee en el bloque de su propia última transacción durante un minuto y estima allí el gas de lo que envía a continuación, da a cada transacción su estimación más un 25 %, entrega sus alertas en espera en el orden en que se lanzaron por última vez, ya no alerta de un ticket que borró su propia reejecución, y su preflight se ejecuta sobre el despliegue de testnet; el Worker conserva lo que aprendió de sus RPC cuando su objeto de Cloudflare duerme, y registra el bloque propio de Robinhood Chain; la app da a cada escritura su propio límite de gas, marca un bote que es una estimación, y nunca toma por ninguna una aprobación que no pudo leer. Desde este bucle, un segundo agente revisa cada corrección antes de que se suba, y sus hallazgos se corrigen de la misma manera. Pasan 653 tests de Foundry (646 fuera de los archivos de fork, y los siete del archivo en fork de Robinhood Chain sobre su RPC público; las tres suites en fork de Ethereum, omitidas a falta de RPC); pasan los 370 tests del keeper (372 tras la última corrección de la puerta), los 51 del paquete compartido, los 9 del back end y los 189 del worker. Consulta Tests y verificación. No desplegado en mainnet
• El décimo bucle de auditoría, corregido el 2026-10-06: cada difusión de despliegue toma la estimación de gas del nodo, ya que la cifra propia de la herramienta de despliegue se queda corta para cada creación con Glamsterdam; el último paso de un lote del bridge en Robinhood Chain recibe una base más una parte por mercado, como máximo 17 mercados por lote, y el keeper no envía más y dice en qué punto está un lote atascado; la vigilancia de emergencias del keeper nombra sus contratos por grupos, sus textos de error conservan solo el host de una dirección RPC, y lee cada mercado mediante Multicall3; la app nunca muestra como hecha una transacción que la wallet canceló, y durante un minuto lee en un bloque no anterior al de su propia última transacción. El adaptador del bridge de la testnet se actualizó y llevó su siguiente lote. Pasan 662 tests de Foundry (655 fuera de los archivos de fork, y los siete del archivo en fork de Robinhood Chain sobre su RPC público; las tres suites en fork de Ethereum, omitidas a falta de RPC), con los 2 del proyecto de la ejecución de LayerZero en testnet; pasan los 400 tests del keeper, los 51 del paquete compartido, los 9 del back end y los 210 del worker. Consulta Tests y verificación. No desplegado en mainnet
• Los restos de un ciclo interrumpido, que se terminan en el siguiente ciclo, decidido el 2026-09-27: el keeper hace seguir adelante el efectivo que un vault aún tiene, sea cual sea el umbral, a más tardar en la ventana siguiente

Un orden de implementación, en etapas que mantienen el repositorio compilando, está recogido en projet/docs/FUNCTIONAL_AUDIT_2026-09-28.md.

Decidido el 2026-09-27, aún no implementado

Ya nada. El paso diario del airdrop en el keeper y la pantalla de reclamación de los holders en la dapp están en el código desde el 2026-10-05, y los restos de un ciclo interrumpido se terminan en el siguiente ciclo, ya que el keeper hace seguir adelante el efectivo que un vault aún tiene, sea cual sea el umbral: ver más arriba.

Los documentos de doc/ y la especificación de la landing se alinearon con esta decisión el 2026-09-27. En el código, se ha completado la eliminación del buyback del creador, desde el 2026-10-04 está el contrato del airdrop, con su cálculo de las partes y sus reclamaciones, y desde el 2026-10-05, el paso del keeper y la pantalla de reclamación.

Decidido el 2026-09-28, aún no implementado

• Los adaptadores de acciones que llevan las acciones wrapped a Ethereum, uno por acción: el adaptador de bloqueo en Robinhood Chain y su OFT en Ethereum. Necesitan el paquete oft-evm de LayerZero y no están en el repositorio para mainnet; los tests usan mocks, y la ejecución de LayerZero en testnet del 2026-10-06 usó adaptadores de prueba construidos con ese paquete. La reclamación en Ethereum está codificada desde el 2026-10-04, y su pantalla en la dapp desde el 2026-10-05
• La configuración de LayerZero de los adaptadores de acciones, en manos del owner, sin plazo y sin tope de retiros

Decidido el 2026-09-11, propagado parcialmente

El paso de Ondo a Robinhood Chain está zanjado y el código del rail existe. No todos los documentos fuente del proyecto se han actualizado: consulta Erratas de las fuentes.

Nunca verificado en condiciones reales

• No se ha realizado ningún despliegue en mainnet
• No se ha puesto a prueba ningún transporte por LayerZero en mainnet. El 2026-10-06, la ejecución de LayerZero en testnet llevó los lotes del bridge y las entregas del airdrop entre Sepolia y la testnet de Robinhood Chain sobre los endpoints, el DVN y el ejecutor reales de testnet de LayerZero, siete ventanas horarias y seis ciclos del airdrop, cada reclamación exactamente su parte calculada. Usó acciones de prueba, adaptadores de prueba, un USDG de prueba y feeds simulados: no demuestra ni el par USDG de Paxos, ni las acciones de Robinhood y sus adaptadores, ni feeds y liquidez reales, ni el gas, las comisiones y la finalidad de mainnet. Consulta El rail de Robinhood
• Las pruebas formales existentes no cubren el rail cross-chain actual
• Siete reglas de la especificación formal del LiquidityLock siguen sin decidirse en el prover para un método, lockProtocolLiquidity, incluso con un límite de tiempo más largo; se cumplen en todos los demás métodos. La nueva ejecución del 2026-10-01, sobre el código corregido, no encontró ninguna regla violada
• Las especificaciones formales se están actualizando para el rediseño del 2026-10-02: su última ejecución completa en el prover, el 2026-10-01, es anterior a él. Para el airdrop del 2026-10-04, las cinco especificaciones que tocan los contratos modificados pasan la comprobación de tipos, sin ejecución en el prover. El 2026-10-05, las especificaciones se actualizaron para los ajustes y luego para los bucles de auditoría de ese día, que añadieron reglas sobre las deudas y lo extraviado del hook, las partes que guarda el lock y cada rescue: pasan la comprobación de tipos, sin ejecución en el prover desde el 2026-10-01. Lo mismo ocurre con las nuevas reglas del oráculo para sus protecciones de los feeds de precios, escritas el 2026-10-06
• Los pagos de deudas del keeper, el cobro de las comisiones de LP, las alertas y el archivo de estado, escritos el 2026-10-05, están cubiertos por sus tests y, desde el 2026-10-06, por un ensayo en una cadena privada: conversiones una vez por ventana, el airdrop, un vault que rechaza ETH y sus deudas pagadas, interrupciones en plena operación con el archivo de estado y su bloqueo, las comisiones de LP. El rail del bridge no se ejecutó allí; funcionó de punta a punta durante la ejecución de LayerZero en testnet del 2026-10-06, con el keeper, nunca en condiciones reales
• No se ha llevado a cabo ninguna revisión externa

Pendiente antes de mainnet

• Un inventario actualizado de la cobertura de feeds en Robinhood Chain y, si Chainlink publicara un feed de disponibilidad del secuenciador para esa cadena, configurarlo en el oráculo (no existe ninguno a 2026-10-06)
• El límite de tamaño de la ruta de LayerZero que toma el USDG de Paxos hacia Robinhood Chain, leído antes del primer lote, y el tope de mercados de un lote del bridge ajustado en consecuencia si difiere de los 10 000 bytes por defecto (desde el décimo bucle de auditoría)
• FDV inicial y límite superior de la posición de $STOCKFUN
• El trabajo que queda en el airdrop, enumerado más arriba: los adaptadores de acciones. Sus parámetros están fijados desde el 2026-10-04: ningún envío por parte del keeper, ni tope, ni mínimo, ni vencimiento, una lista de exclusiones por token
• La métrica que sustituye al Treasury Ratio, y el eslogan y el tagline, que describen una tesorería que acumula
• Los hallazgos de la segunda ronda de la auditoría, el 2026-10-01, que aún esperan la decisión del owner: el margen de la última acción del lado de los contratos, que cambia la regla de asignación documentada (R2T-1); y, opcionalmente, que la factory despliegue ella misma el vault de $STOCKFUN (R2F-2). Desde el 2026-10-05, un vault que rechaza ETH ya no detiene su mercado, así que la detención que describía R2F-2 ya no se deriva de un vault así

Resueltos el 2026-10-05. De la auditoría del 2026-09-29: las atestaciones de Ondo que cualquiera que viera una podía gastar (M-7) y los routers que se aceptaban a sí mismos como destinatario (L-4) están corregidos, y la rotación del adaptador del bridge (M-2, y L-8, ligado a él) se queda como está, por decisión del owner. De la segunda ronda: cobrar el impuesto de compra como claims del PoolManager (R2F-1, option b) se descarta, y el impuesto se sigue cobrando como hasta ahora; una emergencia sobre el efectivo registrado del hub remoto, cuyos registros se pagaban entonces con el efectivo de otros mercados (R2H-1), queda cubierta por las herramientas de liquidación de los bucles de auditoría de ese día más un procedimiento, en el que el owner pone en pausa el hub remoto antes de la transferencia en el rail canónico; y un token de efectivo que rechaza un vault espejo (R2H-2) ya no bloquea nada desde el cuarto bucle de auditoría: la entrega a ese vault espera por separado, y los demás mercados cobran.