Modelo de confianza

Quién puede hacer qué. La respuesta honesta, no la de marketing.

Desde el 2026-10-02, casi todos los contratos del protocolo son upgradeables: el owner de StockFun puede sustituir su código, con efecto inmediato. Desde el 2026-10-05, las cifras del protocolo, desde el impuesto hasta el ciclo del airdrop, son además ajustes onchain del owner, también con efecto inmediato: las cifras que da este libro son sus valores por defecto, enumerados más abajo junto con lo que sigue fijo. Cada regla que este libro atribuye a un módulo es la regla de su implementación actual. Fuera del poder de upgrade: los tokens, el lock de liquidez y, en Robinhood Chain, el deployer de los vaults espejo.

Lo que nadie puede hacer

Estos puntos descansan en contratos que no son upgradeables. Se cumplen sean cuales sean los upgrades o los ajustes que haga el owner.

• Acuñar nuevos tokens. El supply se acuña una sola vez, en el constructor, y los tokens no son upgradeables
• Mover los tokens de un holder sin una autorización suya. El setter de los tokens, setRecorder, no mueve ningún saldo, y sus rescues, desde el 2026-10-05, solo mueven lo que se envió a la propia dirección del token
• Retirar la liquidez de un pool sin un aviso previo público de 30 días. El lock no es upgradeable, su única salida es el modo de cierre, más abajo, y sus 30 días son una constante, no un ajuste. Sus rescues, desde el 2026-10-05, no alcanzan ni las posiciones ni las partes de comisiones que guarda para sus destinatarios
• Cambiar la comisión de LP o el tick spacing de un pool en funcionamiento. Cada pool conserva los que tenía al crearse: forman parte de su clave, que guarda el lock

Lo que el código actual descarta

Nadie puede hacer esto con las implementaciones actuales, tampoco el owner. Cada punto descansa en un módulo upgradeable por el owner.

• Añadir liquidez a un pool de StockFun. Solo puede hacerlo el lock de liquidez, desde el 2026-10-01
• Bloquear el trading a través de una wallet de comisiones o de un vault. Solo la parte de la tesorería se paga durante un trade, y desde el 2026-10-05 a un vault que la rechaza se le debe el monto en su lugar; las demás se reclaman después
• Cambiar la composición de un basket tras su creación
• Cambiar los feeds de precios que lee un vault existente. Cada feed se escribe una sola vez, al inicializar el oráculo, y cada vault conserva su oráculo; los heartbeats de los feeds son ajustes y, desde el 2026-10-06, también las dos salvaguardas del oráculo en Robinhood Chain, que solo pueden retener un precio, nunca cambiarlo
• Enviar los tokens del buyback de $STOCKFUN a otro sitio que no sea el burn
• Elegir quién recibe un airdrop, o reclamar la parte de otro. El reparto se deriva de las tenencias registradas, a prorrata, y solo reclama el holder

Lo que puede hacer un creador

• Ganar la línea del creador de cada trade en su mercado, un 2 % por defecto, y reclamarla, desde el 2026-10-05 hacia otra dirección si lo desea (claimCreatorFeesTo)
• Fijar la whitelist anti-snipe de su mercado, cuyas direcciones pagan el impuesto normal durante los primeros bloques: 20 direcciones como máximo por defecto, fijadas en la transacción de creación, públicas e inalterables después
• Comprar y vender su propio token, como cualquiera

No recibe ninguna asignación, no controla la liquidez y no puede pausar su mercado. No tiene ningún poder sobre la tesorería: solo recibe acciones como cualquier holder.

Lo que puede hacer el keeper

Disparar las conversiones, en el momento que elija, por los montos que indique y por las rutas que proponga. Siempre dentro de los límites de oráculo del vault y de la reserva de cada acción, y sin elegir nunca quién recibe qué. Desde el 2026-10-01, omitir una acción ya no cambia los pesos del basket: esa acción conserva su parte para más adelante. Desde el 2026-10-05, el vault aplica el mínimo que indica el keeper a lo que realmente llega. Desde 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: es una regla propia del keeper, que el vault no impone; el vault solo registra cuándo se convirtió su ETH por última vez.

Desde el 2026-10-05, es además el único que envía un lote de bridge (bridgeReady) y, con el owner de StockFun, el único que despliega por adelantado el vault espejo de un mercado en Robinhood Chain (predeploy). Hasta entonces, ambas cosas estaban abiertas a cualquiera. El hub remoto se entera de quién es el keeper por un lote, así que antes del primer lote el owner de StockFun despliega por adelantado el vault del primer mercado, y un mercado cuyo vault el keeper no puede desplegar por adelantado queda fuera de su lote.

En el airdrop, desde el 2026-10-04: abrir el ciclo de un mercado (openCycle), enviar las acciones de un vault al contrato del airdrop (sendToAirdrop, pagando las comisiones de LayerZero desde Robinhood Chain) y colocar las acciones apartadas (assignUnassigned). Elige cuándo, nunca cuánto, qué, adónde ni para quién: el monto es el saldo del vault, el destino es el contrato que designa el protocolo, y el reparto se deriva de las tenencias. Cualquiera puede abrir un ciclo o colocar las acciones apartadas, con el mismo resultado llame quien llame. Un envío que llega después de la siguiente hora de cierre, las 13:00 UTC por defecto, se mide sobre la ventana del día siguiente. Su paso diario está escrito desde el 2026-10-05: consulta El keeper. Desde el séptimo bucle de auditoría, el 2026-10-06, solo envía una acción una vez que vale lo que cuesta enviarla, lo que solo decide cuándo sale esa acción: lo que espera se queda en el vault para una ventana posterior. Desde el noveno, ese mismo día, también indica el gas que recibe cada entrega en Ethereum, que el hub remoto mantiene entre el suelo y el techo que fija el owner de StockFun, y vuelve a ejecutar desde su propia clave una entrega atascada en el endpoint de LayerZero en Ethereum, algo que cualquiera puede hacer: ninguna de las dos cosas cambia lo que se entrega ni adónde.

Desde el 2026-10-05 también paga, en cada ciclo, lo que el hook y el lock guardan para un destinatario que lo rechazó (payTreasury, payOwed), y cobra las comisiones de LP de un pool creado con una (collectFees). Cualquiera puede hacer esas tres llamadas, que solo pagan a los destinatarios que designan los contratos.

Su clave es una clave caliente. Nunca elige adónde va un activo.

Lo que puede hacer el owner de StockFun

Aquí es donde está la confianza real. El owner de StockFun es el owner del protocolo: el owner de la factory en Ethereum, que el hub remoto refleja en Robinhood Chain.

• Hacer un upgrade de cualquier módulo salvo los tokens, el lock de liquidez y el deployer de los vaults espejo, con efecto inmediato y sin aviso previo. Los vaults reciben su upgrade uno por uno, mercado por mercado, en las dos cadenas
• Cambiar las cifras del protocolo, con efecto inmediato y sin aviso previo: el impuesto, su reparto y el anti-snipe, la comisión de creación, la forma de los nuevos mercados, el umbral de conversión y los límites de precio de los vaults, el ciclo del airdrop, y las demás que se enumeran más abajo
• Iniciar el modo de cierre del lock y, 30 días después, recuperar toda la liquidez de cada pool, la de $STOCKFUN incluida, hacia cualquier dirección
• Designar el registrador de tenencias al que cada token notifica sus transferencias. Si la notificación falla, la transferencia falla: es la única excepción deliberada a la regla según la cual un fallo nunca bloquea el resto (consulta Arquitectura), con dos palancas inmediatas, setRecorder(0), que detiene el registro del token, y un upgrade del registrador en el propio contrato. Desde el 2026-10-05, un token rechaza un registrador ligado a un PoolManager de Uniswap distinto del de su pool. El registrador recibe upgrades en el propio contrato, lo que conserva su historial, y no se sustituye en un token en circulación: desde el 2026-10-05, un sustituto parte del supply del token fuera del PoolManager de Uniswap, así que el trading continúa, y el airdrop no mide ninguna ventana que empezara antes de él; pero lee a los holders que no ha visto moverse como si no hubieran tenido nada hasta su siguiente movimiento, de modo que una ventana que abarquen les paga menos, y nadie cobra más. Hasta el 2026-10-05, un registrador nuevo hacía fallar cada venta y rompía las partes del airdrop de los ciclos abiertos después
• Registrar los baskets, antes de que queden congelados
• Fijar las direcciones de escritura única, una sola vez
• Fijar el keeper y las wallets de comisiones. Una reclamación paga a la wallet fijada en el momento de la reclamación, así que un cambio también redirige el saldo del equipo o del buyback aún no reclamado
• Cambiar el router de swap oficial registrado en la factory, aquel a través del cual el hook reconoce la whitelist anti-snipe
• Apuntar los vaults futuros a otro router de acciones u otro registro de oráculos; los vaults existentes conservan los suyos
• Asociar cada acción de un basket a su token de Robinhood Chain, solo añadiendo entradas
• Fijar la lista de exclusiones del airdrop de cada token, para las ventanas que se cierran después (setExclusions); registrar el OFT de cada acción en Ethereum (registerStockOft)
• Designar el contrato del airdrop al que envían los vaults (setAirdropDistributor); uno sustituido conserva cada ciclo reclamable allí donde está. En Robinhood Chain, designar la ruta del airdrop, el contrato y el gas de cada entrega (setAirdrop), y el adaptador de cada acción (setStockAdapter); desde el 2026-10-06, fijar el valor por defecto, el suelo y el techo del gas que recibe cada entrega en Ethereum (setAirdropReceiveGas, setAirdropComposeGas)
• Sustituir el adaptador del bridge para los envíos futuros, de inmediato (changeAdapter), por un adaptador que conserve exactamente las mismas direcciones fijadas: el mismo hub, la misma factory, los mismos tokens de efectivo, el mismo hub remoto y el mismo destino. La auditoría de seguridad del 2026-09-29 constató que el hub remoto rechazaría los lotes del nuevo adaptador (M-2); el 2026-10-05, el owner decidió dejarlo como está, así que un adaptador se cambia mediante un upgrade en el propio contrato, en la misma dirección
• Pausar las conversiones y el bridging, de inmediato. Un hub remoto en pausa sigue aplicando los cambios de rol que lleva cada lote. En el contrato del airdrop, la pausa detiene los envíos, las aperturas y la colocación de las acciones apartadas, nunca una reclamación
• Mover cualquier activo fuera de una tesorería, de un hub del bridge o del contrato del airdrop, hacia cualquier dirección, de inmediato y sin aviso previo (emergencyTransfer), en cualquiera de las dos cadenas, en cualquier momento; en el hub remoto, desde el 2026-10-05, también imputándolo a un solo mercado, cuyas cuentas se liquidan en la misma llamada (emergencyTransferFromPending, emergencyTransferRecord)
• Tras una transferencia así fuera del contrato del airdrop o del hub remoto, imputar la pérdida al ciclo o al mercado que la sufrió (writeDownCycle, writeDownUnassigned, writeOffPending, writeOffRecord, desde el 2026-10-05). Un ciclo solo admite una baja parcial mientras nadie haya reclamado de él la acción, y cada holder pierde entonces la misma proporción; una vez que algunos holders han cobrado, solo una baja de todo su resto, que pierden los holders que aún no han cobrado, y lo que llega después al ciclo se reparte de nuevo a prorrata entre todos sus holders. Ningún otro mercado paga por ello; hasta que la pérdida se impute o los activos vuelvan mediante restore, que cualquiera puede llamar, los pagos de lo que falta esperan, y los demás siguen: una reclamación paga las demás acciones. Los dos contratos contabilizan lo que respalda sus cuentas, nunca su saldo: los activos que van de camino a otro mercado nunca pagan por la pérdida, y una simple transferencia a ellos no respalda nada
• Sacar lo que un módulo guarda por error (rescue, desde el 2026-10-05): el ETH o los tokens enviados a un módulo que no guarda nada de nadie; lo extraviado del hook, nunca lo que debe; lo que el lock guarda por encima de las partes de comisiones que retiene, nunca sus posiciones; el ETH del BuybackBurner solo cuando ningún burn pueda ya gastarlo; lo que se envió a la propia dirección de un token. Consulta Modo de emergencia
• Cambiar la configuración de LayerZero de los adaptadores de acciones del airdrop, sin aviso previo y sin tope de retiros

El upgrade es el más amplio de estos poderes: alcanza de una vez todas las reglas de la segunda lista de arriba. Junto con los ajustes, el modo de cierre, la transferencia de emergencia y la configuración de los adaptadores de acciones, significa que StockFun no es trustless y no pretende serlo. La tesorería la guarda el protocolo, con una vía de recuperación controlada por el owner.

Los ajustes

Desde el 2026-10-05, las cifras del protocolo son ajustes onchain del owner de StockFun, en las dos cadenas. Cada uno surte efecto en la transacción que lo fija, sin aviso previo, emite un evento y rechaza los valores imposibles: una tasa superior al 100 %, un reparto mayor que el impuesto, una forma de lanzamiento que un pool no puede contener. Los valores de abajo son los valores por defecto, los que da este libro.

• Todos los pools, desde el siguiente swap. Un cambio del impuesto o del anti-snipe se aplica desde el siguiente swap en todos los pools, incluido un pool que siga en sus bloques anti-snipe: el decrecimiento se calcula con los ajustes vigentes, desde el bloque de lanzamiento del pool. El anti-snipe nunca cobra menos que el impuesto. El tope de la whitelist se aplica al crear un mercado
• Solo los nuevos mercados, para su forma. Un nuevo supply, nuevas bandas, un nuevo tick spacing o una nueva comisión de LP se aplican a los mercados creados después. Cada pool conserva la comisión de LP y el tick spacing con los que se creó, y la Lens los da, mercado por mercado; el pool de $STOCKFUN toma los vigentes cuando se lanza
• En directo, para los vaults. Cada vault lee el umbral de conversión y sus límites de precio en cada conversión, y el lock lee las partes de las comisiones de LP en cada cobro
• Los ciclos abiertos conservan su ventana. Un nuevo horario del airdrop se aplica a las ventanas aún no abiertas, y las vuelve a recortar, incluidas las que las acciones apartadas todavía tienen que revisar

Lo que sigue fijo:

• El aviso previo de 30 días del modo de cierre, END_DELAY, una constante del lock de liquidez, que no es upgradeable
• La inmediatez de la transferencia de emergencia: no tiene plazo, y ningún ajuste puede añadir uno
• Unidades y codificaciones: el punto básico, la hora como unidad del registro de tenencias y de las ventanas del airdrop, la dirección de burn, los formatos de mensaje
• La conexión: los feeds de precios, los pools en los que compra el router de acciones, en Ethereum, el OFT de USDG, los endpoints de LayerZero del bridge, el hub remoto, el pool de Curve. Se fijan en el despliegue o se escriben una sola vez; cambiar uno supone apuntar a otro contrato, lo que requiere un upgrade

Los upgrades

Desde el 2026-10-02, cada módulo es un proxy cuyos upgrades pasan por UUPS, salvo los contratos de más abajo. Cómo está construido: consulta Arquitectura.

• Inmediato. Un upgrade surte efecto en la transacción que lo realiza: sin timelock, sin aviso previo, como los ajustes y la transferencia de emergencia
• Verificado. Solo el owner del protocolo puede hacer upgrades. Una nueva implementación debe responder a la misma autoridad de upgrade, y las del hook y del registrador de tenencias deben conservar el mismo PoolManager
• Mercado por mercado. Cada vault es su propio proxy. Una nueva implementación de vault designada en la factory se aplica a los mercados creados después; los vaults existentes reciben su upgrade uno por uno
• Almacenamiento ampliado por el final, nunca reordenado. La disposición del almacenamiento de cada módulo está registrada, y un script la comprueba antes de cada upgrade, en cada nivel de cada struct desde el 2026-10-05

Estos no son upgradeables:

• Los tokens, los tokens de mercado y $STOCKFUN: ERC-20 simples cuyo supply se acuña una sola vez, sin mint, burn, pausa ni blacklist. Su único setter, setRecorder, y sus rescues pertenecen al owner del protocolo
• El lock de liquidez, cuyo código es lo que mantiene la liquidez en los pools. Su única salida para la liquidez es el modo de cierre; sus rescues no alcanzan ni las posiciones ni las partes que guarda
• El deployer de los vaults espejo, en Robinhood Chain: la dirección de cada vault espejo se deriva de la suya

Los dos deployers de Ethereum, que no tienen estado, se sustituyen a través de la factory en lugar de recibir un upgrade.

El modo de cierre

La única salida del lock de liquidez, añadida el 2026-10-02 para el caso de que el proyecto cierre. El owner de StockFun llama a end(). A partir de ese momento no se puede lanzar ningún mercado nuevo, mientras todos los pools siguen operando. Treinta días después, el owner puede recuperar toda la liquidez de cada pool, hacia cualquier dirección. El owner puede cancelar en cualquier momento mientras el cierre esté pendiente; los pools ya recuperados se quedan vacíos. Los 30 días son el aviso previo de los holders. Detalle en El lanzamiento en dos posiciones.

Dependencias externas

Ninguna de estas dependencias está oculta, y ninguna puede sacar un activo de un vault hacia una dirección.

Riesgos aceptados

• Un upgrade, un cambio de ajuste y una transferencia de emergencia surten efecto de inmediato: los holders no reciben ningún aviso previo, a diferencia del modo de cierre, anunciado con 30 días de antelación
• Cada transferencia de token depende del registrador de tenencias: una notificación que falla hace fallar la transferencia. Es la única excepción deliberada a la regla según la cual un fallo nunca bloquea el resto: una notificación a la que se permitiera fallar dejaría que un holder se saltara el registro y aumentara su parte del airdrop. Sus palancas son inmediatas: setRecorder(0) en el token, o un upgrade del registrador en el propio contrato
• Una parte cuyo destinatario la rechaza espera a ese destinatario, en el hook, el lock, el hub remoto o el contrato del airdrop, en lugar de detener el resto; y una transferencia de emergencia no imputada a ningún mercado hace esperar los pagos de ese activo hasta que se liquide
• Ninguna tesorería acumula: todo se distribuye, y un airdrop puede ser cero si nadie opera
• El airdrop se paga en acciones wrapped en Ethereum: solo valen lo que valgan las acciones bloqueadas en Robinhood Chain y la configuración de LayerZero, y una congelación de los Stock Tokens por parte de su emisor inmovilizaría las acciones bloqueadas
• Un mercado puede no agotar nunca su primera banda de liquidez
• Una ida y vuelta cuesta un 9,75 % antes de cualquier movimiento de precio, con el impuesto por defecto del 5 %
• El rail cross-chain no se había puesto a prueba en condiciones reales en el momento de escribir este libro