Modo de emergencia

Desde el 2026-08-29, el owner de StockFun puede mover los activos de una tesorería, o de cualquier contrato que guarde fondos del protocolo, a cualquier dirección. Desde el 2026-10-05, la transferencia es inmediata: sin aviso previo, sin plazo, y ningún ajuste puede añadir uno. Es el cambio de mayor alcance del proyecto, y alteró lo que el producto tiene permitido decir.

Lo que permite

emergencyTransfer(asset, amount, to), llamada en el contrato que contiene el activo, mueve esa cantidad de cualquier activo (ETH, USDC, USDG, acciones tokenizadas, tokens de mercado) hacia to, de inmediato. La incluyen cinco contratos: el TreasuryVault, el BridgeHub y, desde el 2026-10-04, el contrato del airdrop, AirdropDistributor, en Ethereum; el RemoteHub y los vaults espejo en Robinhood Chain. Solo su admin de emergencia puede llamarla: el owner de la factory en Ethereum y, en Robinhood Chain, la misma dirección tal como la llevó el último lote del bridge. El owner puede usarla en cualquiera de estos contratos, en cualquier momento.

Cada transferencia recibe un identificador secuencial y emite un evento público, EmergencyExecuted, con el activo, la cantidad y el destinatario. Nada la anuncia de antemano.

Hasta el 2026-10-05, el owner programaba el movimiento: un evento público lo anunciaba, el owner podía cancelarlo durante 48 horas, y cualquiera podía ejecutarlo después. Esa programación ha desaparecido, y el plazo no es un parámetro: una emergencia actúa en cuanto el owner la usa, nunca tras una espera. Con ella desaparece la excepción prevista para los fondos del airdrop atascados en un vault espejo, que nunca se codificó: la transferencia inmediata ya los cubre.

Junto a ello: una pausa de las conversiones y del bridging (inmediata y sin mover fondos) y la sustitución del adaptador del bridge para los envíos futuros, changeAdapter, también inmediata desde el 2026-10-05. En el contrato del airdrop, la pausa detiene los envíos, la apertura de ciclos (openCycle) y la colocación de las acciones apartadas (assignUnassigned); no mueve nada y nunca detiene una reclamación.

Desde el 2026-10-01, un hub remoto en pausa sigue aplicando los cambios de keeper y de admin de emergencia que lleva cada lote, así que un cambio de owner siempre llega a Robinhood Chain; el efectivo que recibe mientras tanto espera allí, registrado por mercado, hasta un sweep una vez levantada la pausa.

La auditoría de seguridad del 2026-09-29 constató que la sustitución del adaptador no puede funcionar de extremo a extremo: el hub remoto solo acepta lotes del adaptador original, así que todo lote enviado tras una sustitución esperaría en el hub remoto hasta que el modo de emergencia lo recuperara (M-2). El 2026-10-05, el owner decidió dejarlo como está: un adaptador se cambia mediante un upgrade en el propio contrato, en la misma dirección, y una dirección nueva exigiría primero un upgrade del hub remoto para aceptarla.

En un vault, desde el pipeline de seguridad del 2026-10-01, una transferencia de emergencia que deja el efectivo por debajo de las reservas de las acciones las pone todas a cero: lo que queda, y todo el efectivo que entra después, se reparte de nuevo según los pesos del basket. Una emergencia que solo se lleva efectivo no reservado, u otro activo, las conserva. El efectivo que se saca y se devuelve a un vault se reparte como cualquier entrada, sin volver a la acción para la que estaba reservado.

La segunda ronda de la auditoría, el 2026-10-01, constató que, en el hub remoto, una emergencia que se lleva efectivo ya registrado para un mercado deja el registro en su sitio, a pagar con el efectivo de otros mercados (R2H-1). Desde el 2026-10-05, a una transferencia le sigue una liquidación (ver más abajo), y ese caso queda cubierto por sus herramientas más un procedimiento: en el rail canónico, el owner de StockFun pone en pausa el hub remoto antes de la transferencia. Desde el cuarto bucle de auditoría de ese día, una transferencia también puede imputarse a un solo mercado, lo que liquida sus cuentas en la misma llamada.

Tras una transferencia: saldar las cuentas

Desde el 2026-10-05, tras los bucles de auditoría de ese día. La transferencia en sí no cambia: inmediata, sin ninguna condición. Pero dos contratos guardan activos que respaldan lo que se debe a varios mercados: el contrato del airdrop y el hub remoto. Tras una transferencia fuera de cualquiera de los dos, las cuentas se saldan, nunca con cargo a otro mercado. O los activos vuelven, o el owner de StockFun imputa la pérdida al mercado que la sufrió.

Los dos contratos contabilizan lo que respalda sus cuentas, nunca su saldo. El saldo también contiene tokens que han llegado pero aún no están abonados: una entrega de acciones cuyo último paso en Ethereum no se ha ejecutado o, en el rail de USDG, el efectivo de un lote cuyo último paso en Robinhood Chain no se ha ejecutado. Esos tokens aún no respaldan nada, y pueden pertenecer a otro mercado. Hasta el segundo bucle del 2026-10-05, los contratos leían el saldo, así que esos tokens podían reabrir las reclamaciones de un ciclo vaciado y pagarlas con las acciones de otro mercado.

• Una transferencia de emergencia toma primero de lo que respalda las cuentas. Los tokens no se pueden distinguir, y contar primero como salidos los abonados nunca hace que un mercado pague por otro. Lo que se lleva más allá de eso procedía de tokens aún no abonados: el contrato lo registra (taken, cashTaken), y las siguientes entregas de ese activo lo saldan antes de respaldar nada.
• Los activos vuelven mediante restore. Cualquiera puede llamarla; retira los tokens de quien la llama. Una simple transferencia al contrato no respalda nada. Desde el tercer bucle de auditoría del 2026-10-05, restore devuelve primero lo que una transferencia se llevó por encima de lo que respalda las cuentas (taken, cashTaken), y respalda las cuentas con el resto: los tokens de una entrega que aún espera nunca pagan a un mercado vaciado.

• Tokens extraviados. Los tokens que llegaron al contrato del airdrop, o al hub remoto en el rail de USDG, sin haber sido abonados nunca, enviados allí por error, también se descuentan de lo que respalda las cuentas si una transferencia de emergencia los saca. Una transferencia de emergencia solo los saca para restaurarlos; si no, su monto tiene que imputarse al ciclo o al mercado en el que recae, o eliminarse mediante un upgrade.

• El contrato del airdrop lleva la cuenta, acción por acción, de lo que debe y de lo que lo respalda, y solo paga una acción mientras lo que lo respalda cubra lo que debe. Tras una transferencia que se llevó parte de una acción, las reclamaciones de esa acción esperan, en todos los mercados que la tienen, hasta que la acción vuelva mediante restore o hasta que el owner impute la pérdida al ciclo que la sufrió (writeDownCycle), o a las acciones que un mercado tiene apartadas (writeDownUnassigned). Mientras nadie haya reclamado esa acción del ciclo, el owner puede dar de baja cualquier parte de ella, y cada holder del ciclo pierde la misma proporción; una vez que algunos holders han cobrado, el owner solo puede dar de baja todo el resto, que pierden los holders que aún no han cobrado, o devolver la acción. Lo que llegue después a ese ciclo se reparte a prorrata entre todos sus holders, como si el monto dado de baja nunca hubiera estado allí. Ningún otro ciclo paga por ello. Desde el cuarto bucle de auditoría, una reclamación solo difiere la acción que espera (ClaimDeferred) y paga las demás en la misma llamada; hasta entonces fallaba entera. El contrato del airdrop no tiene ninguna transferencia imputada a un solo ciclo: su límite de tamaño no dejaba sitio. El procedimiento que nunca deja que sus cuentas se queden cortas imputa primero la pérdida al ciclo, o a las acciones apartadas, y luego mueve la acción; una transferencia hecha primero mantiene la espera general descrita más arriba.

• El hub remoto, en el rail de USDG, contabiliza el efectivo que respalda lo que debe y se niega a pagar (sweep) mientras ese efectivo no alcance. Tras una transferencia que se llevó más de eso, los siguientes lotes se registran en lugar de entregarse hasta que lo hayan compensado. El owner devuelve el efectivo (restore), o da de baja un monto que se ha perdido, o que la transferencia entregó a mano al vault espejo del mercado (writeOffPending). Desde el cuarto bucle de auditoría, el owner también puede imputar una transferencia a un solo mercado: emergencyTransferFromPending(marketId, amount, to) mueve lo que el hub debe a ese mercado y lo da de baja en la misma llamada, de modo que las cuentas nunca se quedan cortas y ningún otro mercado espera.
• El hub remoto, en el rail canónico, debe los registros de su cola y no lleva esa cuenta: la protección es un procedimiento. El owner pone en pausa el hub antes de la transferencia, mueve el efectivo, da de baja el registro al que correspondía ese efectivo (writeOffRecord) y luego levanta la pausa, para que la cola nunca pague ese registro por segunda vez con el efectivo de otro mercado. Desde el cuarto bucle de auditoría, una sola llamada lo hace para un registro: emergencyTransferRecord(index, to) mueve el monto entero del registro y lo da de baja. Desde el quinto, esa llamada es para un registro cuyo depósito ha llegado: el efectivo de la cola es común, así que rechaza un monto que supere el efectivo no retenido para partes rechazadas (RecordNotCovered); un registro cuyo depósito se ha perdido se da de baja con writeOffRecord. Una parte que un vault espejo rechazó, retenida aparte para su mercado (undeliverable), se mueve y se da de baja con emergencyTransferFromPending.

Cada baja contable emite un evento público (WrittenDown, PendingWrittenOff), y también cada devolución (Restored) y cada reclamación diferida (ClaimDeferred).

Rescues: lo que un módulo guarda por error

Desde el 2026-10-05, según la regla del fundador de que todo lo que puede guardar fondos tiene una palanca (consulta Arquitectura), los contratos sin modo de emergencia tienen un rescue propio, para lo que se les envió por error o dejó allí una operación fallida. Solo lo llama el owner de StockFun: el owner de la factory en Ethereum, el admin del hub remoto en Robinhood Chain, la misma dirección que hace los upgrades de los módulos. Cada rescue emite un evento público.

• Los módulos que no guardan nada de nadie entre transacciones —la factory, la Lens, los oráculos, el registrador de tenencias, los routers de acciones, el router de swap oficial y los adaptadores del bridge— tienen rescue(asset, amount, to), para ETH (la dirección cero) o cualquier token
• El hook solo saca lo extraviado: como máximo el ETH que le envió cualquiera que no sea el PoolManager (strayEth), y cualquier token, ya que nunca guarda ninguno. Los saldos de los creadores, del equipo y del buyback y las deudas con los vaults nunca salen por esa vía. El ETH forzado sin llamada no se cuenta, y espera a un upgrade
• El lock de liquidez, que no es upgradeable, saca cualquier token, y el ETH por encima de las partes que guarda para vaults y creadores (totalOwed), que nunca salen por esa vía; desde el quinto bucle de auditoría, también los claims de v4 abonados a su favor en el PoolManager (rescueClaims) y un NFT que se le haya enviado con una simple transferencia (rescueNft). 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. Sus posiciones solo siguen siendo alcanzables mediante el modo de cierre
• El BuybackBurner saca un token 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. Mientras ese pool esté bloqueado, su ETH solo sale mediante burns
• Los tokens, que no son upgradeables, sacan lo que se envió a su propia dirección: sus propios tokens, notificados al registrador de tenencias como cualquier transferencia, cualquier otro token, el ETH forzado y, desde el quinto bucle de auditoría, claims de v4 y NFT (rescue, rescueClaims, rescueNft). Ningún saldo de un holder puede moverse por esa vía
• Los contratos de implementación detrás de los proxies nunca se usan directamente. En los de la factory y del hub remoto, que guardan su admin en el almacenamiento del proxy, la palanca para lo que se envía a su propia dirección es la dirección que los desplegó; todas las demás implementaciones leen su admin a través de su autoridad, el owner del protocolo

Los vaults, los dos hubs y el contrato del airdrop conservan en su lugar el modo de emergencia, ya que llevan sus propias cuentas. Los dos deployers de Ethereum y el deployer de los vaults espejo no guardan estado, no aceptan ETH y no tienen owner: no necesitan palanca.

Lo que no permite

El modo de emergencia no toca el registro de feeds. Mueve activos; no cambia los límites de ejecución, que son ajustes aparte del owner. No puede hacer que un vault compre cualquier cosa a cualquier precio; puede llevarse, de inmediato, lo que haya en un vault.

Tampoco puede tocar la liquidez bloqueada ni los tokens de los holders. Lo mismo vale para el airdrop: el modo de emergencia puede mover las acciones del contrato del airdrop, pero no puede cambiar cómo se reparte un ciclo entre sus holders. Las partes quedan como están; desde el 2026-10-05, una reclamación solo se paga mientras lo que respalda las cuentas del contrato cubra todo lo que este debe en esa acción, y una pérdida que no se va a recuperar se imputa al ciclo que la sufrió, nunca a otro (más arriba).

Sin embargo, no es la única vía del owner hacia un vault. Desde el 2026-10-02, el owner de StockFun también puede hacer un upgrade de un vault, o del oráculo que lee, con efecto inmediato. La liquidez bloqueada tiene su propia salida, el modo de cierre, anunciado con 30 días de antelación: el único plazo fijo del protocolo. Consulta Modelo de confianza.

Por qué existe

La revisión de los modos de fallo cross-chain planteó una pregunta sencilla: ¿qué pasa cuando una ruta falla, se pierde un mensaje del bridge o un contrato tiene un bug?

Sin vía de recuperación, la respuesta es «los fondos se pierden, de forma permanente». El protocolo eligió una vía de recuperación controlada, en manos de su owner y registrada onchain, antes que la elegancia de un sistema que no puede reparar nada. Desde el 2026-10-05, esa vía actúa en cuanto se usa.

Desde el 2026-10-01, es también la vía por la que el efectivo de un mercado cuyo basket rechazó Robinhood Chain sale del vault espejo de ese mercado, que queda sin inicializar: consulta El rail de Robinhood.

Lo que cuesta

El owner puede mover los activos de una tesorería a cualquier dirección, de inmediato y sin aviso previo. Así consta en el modelo de confianza del proyecto.

Sobre todo, la redacción validada sustituye a toda promesa anterior.

Los activos los mantiene el vault del mercado y se rigen por sus reglas. El equipo de StockFun puede mover los activos de una tesorería en caso de emergencia, tras un plazo público de 48 horas.

Desde el 2026-10-05, el plazo de esta frase ya no existe: la transferencia es inmediata. La frase debe revisarse, y su nueva redacción, validarse. Desde el 2026-10-02, tampoco cubre los upgrades de los vaults, que surten efecto de inmediato.

El producto ya no puede decir non-custodial, trustless, tesorería inmutable ni nadie puede tocar la tesorería. Esas expresiones están prohibidas por las reglas de marca; la auditoría automática de textos no las comprueba, lo hace la revisión.

El modo de emergencia nunca se describe como una protección ni como una garantía contra pérdidas. Es un poder en manos del equipo, que surte efecto de inmediato. Nada más.

Lo que ve el usuario

Hasta el 2026-10-05, un banner debía anunciar una recuperación programada en cada superficie afectada, con su fecha de ejecución. Una transferencia es ahora inmediata, así que no hay nada que anunciar de antemano: se hace visible a posteriori, en el evento EmergencyExecuted del contrato del que salió.