El TreasuryVault
Un vault por mercado. Recibe el 2 % de cada trade y lo convierte en acciones tokenizadas, distribuidas por airdrop a los holders del token. Es el contrato más pesado del protocolo, y el que menos poderes tiene.
Lo que no tiene
Sin withdraw. Sin transfer. Sin sweep. Sin owner. Esas funciones no existen en la
implementación actual, algo que cualquiera puede verificar: una llamada falla porque no
hay nada a lo que llamar. Desde el 2026-10-02, el propio vault es upgradeable: ver más
abajo.
El ciclo de conversión
- Acumulación. El ETH llega con los trades. Una vez cada 24 horas, el ciclo arranca si el vault contiene al menos 0,1 ETH cuando el keeper lo comprueba, en su primera pasada después de que se cierre la ventana del airdrop; por debajo de eso, ese día no se dispara nada, aunque el ETH supere el umbral más tarde: el gas y el slippage se comerían la operación. El keeper se atiene a ello desde el 2026-10-06; hasta entonces convertía en cuanto el vault contenía el umbral.
- ETH → USDC en Uniswap v4 en Ethereum, limitado a 50 puntos básicos frente al feed ETH/USD. Par profundo, así que el límite puede ser estrecho. El keeper indica el monto, al menos el umbral y como máximo el saldo, y el límite se calcula sobre ese monto.
- USDC → USDG a través de Curve, y luego a través del OFT de Paxos sobre LayerZero.
- Compra de las acciones en los pools secundarios de Robinhood Chain, por parte del vault espejo, limitada a 200 puntos básicos frente a un feed Chainlink independiente, cada acción con el efectivo reservado para ella.
- Airdrop. En el mismo ciclo diario, el keeper envía las acciones compradas al contrato del airdrop en Ethereum, donde los holders del token las reclaman, a prorrata. Desde el séptimo bucle de auditoría, el 2026-10-06, las envía una vez que valen lo que cuesta enviarlas; si no, esperan en el vault a una ventana posterior.
El vault mide lo que realmente recibe y rechaza la operación si el resultado queda por debajo del mínimo del keeper, que nunca es menos estricto que el límite (desde el 2026-10-05; hasta entonces, el resultado solo se comprobaba frente al límite). No confía ni en el keeper, ni en el rail, ni en el precio cotizado.
Desde el 2026-10-05, cada tramo de compra se ejecuta por separado, en los dos vaults que
compran acciones. Un tramo que falla —una ruta que revierte, una acción congelada, un feed
desactualizado, un resultado por debajo del mínimo, una cotización rechazada y, desde el
2026-10-06 en Robinhood Chain, una acción cuyo token pone en pausa su oráculo por una
operación corporativa— conserva su efectivo reservado para su acción y emite LegFailed,
y los demás tramos se ejecutan. Solo cuando no se ejecuta ningún tramo falla la llamada,
con el motivo del primer tramo, como lo haría un tramo único. Hasta entonces, un tramo que
fallaba hacía fallar toda la compra. En Robinhood Chain, con la comprobación del
secuenciador del oráculo configurada, un secuenciador caído o que acaba de volver retiene
todos los tramos (ver El rail de Robinhood); esa comprobación está
desactivada hasta que Chainlink publique un feed de disponibilidad para la cadena.
El umbral y los dos límites son los valores por defecto de ajustes del owner de StockFun, desde el 2026-10-05, que cada vault lee en directo: los de la factory para los vaults de Ethereum, los del hub remoto para las compras de los vaults espejo. Un cambio se aplica a la siguiente conversión de cada vault.
Montos y reservas
Desde el 2026-10-01, tras la auditoría de seguridad del 2026-09-29:
- Cada etapa gasta un monto que indica el keeper. Un vault más grande de lo que su plataforma de negociación puede absorber dentro del límite convierte por fracciones, a lo largo de varios ciclos. Antes, cada etapa gastaba el saldo completo, y un vault que superaba la capacidad de su plataforma de negociación no podía volver a convertir nunca.
- El límite de la etapa del ETH se calcula sobre ese monto, no sobre el saldo actual. El ETH que añaden los trades mientras la transacción espera ya no invalida el mínimo del keeper.
- El efectivo se reserva acción por acción. A medida que llega, se aparta para cada acción del basket según los pesos del basket. Cada acción gasta solo su propia reserva, y una acción que el keeper omite la conserva para más adelante. Antes, la parte de una acción omitida se volvía a repartir entre todo el basket: omitiendo acciones, un keeper podía trasladar casi toda una tesorería a una sola acción.
Los dos vaults que compran acciones funcionan así: el vault espejo en Robinhood Chain, en USDG, y el vault de Ethereum en el rail local, en USDC.
En ambos, desde el pipeline de seguridad del 2026-10-01, una transferencia de emergencia que deja el efectivo por debajo de las reservas 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. Antes, la puesta a cero solo existía en la lectura que el vault hacía de sus reservas: las antiguas reservas volvían con la siguiente entrada de efectivo, y el orden de las llamadas del keeper decidía la mezcla del basket.
El papel del keeper
Disparar, nada más. Elige el momento, indica el monto de cada etapa, propone rutas de swap y aporta montos mínimos, que el vault rechaza si son menos estrictos que su propio límite de oráculo, o si un monto supera lo reservado para esa acción. El keeper puede pedir más que el límite, nunca menos. Desde el 2026-10-05, el vault aplica el mínimo del keeper a lo que realmente llega.
El keeper gasta por completo la reserva de cada acción, salvo en la última acción del basket, donde retiene n−1 unidades, siendo n el número de acciones: consulta El keeper.
En el rail opcional de Ondo, el keeper entrega al vault una cotización firmada por el
emisor para cada tramo. Una cotización así es válida para quien la presente, por lo que
desde el 2026-10-05 el router de Ondo solo sirve a los vaults de la factory, el vault del
protocolo y el de cada mercado registrado, y rechaza a cualquier otro (NotAVault): nadie
más puede gastar la cotización del keeper y hacer fallar esa conversión. Además, cada
router del protocolo se rechaza a sí mismo como destinatario de un swap, de modo que no
guarda nada entre transacciones.
Indique lo que indique, el keeper no puede desviar un activo, elegir otro basket, pasar el efectivo de una acción a otra ni relajar un límite.
El airdrop
Las acciones del vault tienen un único destino: los holders del token, en cada airdrop, a prorrata de sus tenencias. El reparto se deriva de los saldos según una regla que nadie elige, ni el creador ni el keeper. El mecanismo está codificado desde el 2026-10-04, no desplegado: consulta El airdrop.
En el rail local, el vault entrega él mismo sus acciones. sendToAirdrop(stocks), solo
para el keeper, envía todo el saldo de cada acción del basket de la lista al contrato del
airdrop que designa la factory, leído en directo. El vault aprueba los montos exactos, el
contrato los retira y los abona al ciclo en curso del mercado, y las aprobaciones se
vuelven a cerrar antes de que la llamada termine. Una acción listada dos veces o fuera del
basket hace fallar la llamada; una acción sin saldo se omite. Desde el 2026-10-05, cada
acción va por separado: una cuyo saldo no se puede leer o cuya transferencia se rechaza,
por ejemplo por una congelación del emisor, se queda en el vault con un evento
(AirdropSendFailed), y las demás se envían; cuando no sale ninguna acción, la llamada
falla e indica el motivo. Un vault conectado al hub del bridge rechaza esta llamada: sus
acciones se compran y se guardan en Robinhood Chain, donde el vault espejo las envía de la
misma manera, a través del adaptador LayerZero de cada acción.
El buyback del creador, buybackAndBurn(...), que permitía a un creador vender acciones de
la tesorería para recomprar y quemar su token, se abandonó el 2026-09-27 y se eliminó del
código el 2026-09-28.
Lo que puede contener un vault
ETH, USDC, USDG y las acciones de su basket, más, en el rail opcional de Ondo, el USDon que puede reembolsar un mint del emisor. Un vault no compra nada más. Eso se deriva del código; ningún test lo comprueba como invariante, y nada impide que un tercero envíe un token ajeno a la dirección de un vault. El modo de emergencia saca un token así como cualquier otro activo.
Un vault lleno de USDC no está averiado: está en tránsito. Los tres estados se muestran como la tesorería a la espera del próximo airdrop; solo se distribuyen las acciones, una vez compradas.
Un proxy por mercado
Desde el 2026-10-02, el vault de cada mercado es su propio proxy. Se crea con el mercado, delante de la implementación de vault que la factory designa en ese momento, y se inicializa en la misma transacción con su basket, su mercado, y el router, el oráculo y el hub del bridge que la factory designa entonces. El owner de StockFun hace los upgrades de los vaults uno por uno, mercado por mercado, con efecto inmediato. Una nueva implementación designada en la factory solo llega a los mercados creados después.
Los vaults espejo de Robinhood Chain siguen la misma regla: consulta El rail de Robinhood.
Modo de emergencia
Desde el 2026-08-29, el owner de StockFun puede mover cualquier activo fuera de un vault, hacia cualquier dirección; desde el 2026-10-05, la transferencia es inmediata, sin aviso previo. Junto con el airdrop, es la única vía por la que la implementación actual deja salir activos de un vault, y se trata en Modo de emergencia.