O TreasuryVault

Um vault por mercado. Ele recebe 2 % de cada trade e os transforma em ações tokenizadas, distribuídas via airdrop aos holders do token. É o contrato mais pesado do protocolo, e o que tem menos poderes.

O que ele não tem

Nenhum withdraw. Nenhum transfer. Nenhum sweep. Nenhum owner. Essas funções não existem na implementação atual, o que qualquer pessoa pode verificar: uma chamada falha porque não há nada a chamar. Desde 2026-10-02, o próprio vault é upgradável: veja abaixo.

O ciclo de conversão

1. Acumulação. O ETH chega com os trades. Uma vez a cada 24 horas, o ciclo começa se o vault detiver pelo menos 0,1 ETH quando o keeper o verifica, na sua primeira passagem depois que a janela do airdrop fecha; abaixo disso, nada dispara naquele dia, mesmo que o ETH cruze o limiar mais tarde — o gas e o slippage comeriam a operação. O keeper segue essa regra desde 2026-10-06; até então, convertia assim que o vault detinha o limiar.
2. ETH → USDC no Uniswap v4 no Ethereum, limitado a 50 pontos-base em relação ao feed ETH/USD. Par profundo, então o limite pode ser apertado. O keeper indica o valor, no mínimo o limiar e no máximo o saldo, e o limite é calculado sobre esse valor.
3. USDC → USDG via Curve, depois pelo OFT da Paxos na LayerZero.
4. Compra das ações nos pools secundários da Robinhood Chain, pelo vault espelho, limitada a 200 pontos-base em relação a um feed Chainlink independente, cada ação comprada com o caixa reservado para ela.
5. Airdrop. No mesmo ciclo diário, o keeper envia as ações compradas ao contrato do airdrop no Ethereum, onde os holders do token as reivindicam, pro rata. Desde o sétimo loop de auditoria, em 2026-10-06, ele as envia quando elas valem o que custa enviá-las; caso contrário, elas esperam no vault por uma janela posterior.

O vault mede o que realmente recebe e recusa se o resultado ficar aquém do mínimo do keeper, que nunca é mais frouxo do que o limite (desde 2026-10-05; até então, o resultado era verificado só contra o limite). Não confia nem no keeper, nem no trilho, nem no preço cotado.

Desde 2026-10-05, cada perna da compra roda isoladamente, nos dois vaults que compram ações. Uma perna que falha — uma rota que reverte, uma ação congelada, um feed desatualizado, um resultado abaixo do mínimo, uma cotação recusada e, desde 2026-10-06 na Robinhood Chain, uma ação cujo token pausa o seu oráculo por um evento corporativo — mantém o seu caixa reservado para a sua ação e emite LegFailed, e as outras pernas rodam. Só quando nenhuma perna roda é que a chamada falha, com o motivo da primeira perna, como faria uma perna única. Até então, uma perna que falhava fazia a compra inteira falhar. Na Robinhood Chain, com a verificação do sequenciador do oráculo definida, um sequenciador fora do ar ou que acabou de voltar segura todas as pernas (veja O trilho Robinhood); essa verificação fica desligada até que a Chainlink publique um feed de disponibilidade para a chain.

O limiar e os dois limites são os padrões de parâmetros do owner do StockFun, desde 2026-10-05, lidos em tempo real por todo vault: os da factory para os vaults do Ethereum, o do hub remoto para as compras dos vaults espelho. Uma mudança vale para a próxima conversão de todo vault.

Valores e reservas

Desde 2026-10-01, depois da auditoria de segurança de 2026-09-29:

• Cada etapa gasta um valor que o keeper indica. Um vault maior do que o seu local de negociação consegue absorver dentro do limite converte em fatias, ao longo de vários ciclos. Antes, cada etapa gastava o saldo inteiro, e um vault que crescia além do seu local de negociação nunca mais conseguia converter.
• O limite da etapa do ETH é calculado sobre esse valor, não sobre o saldo corrente. O ETH que os trades acrescentam enquanto a transação espera não invalida mais o mínimo do keeper.
• O caixa é reservado ação por ação. À medida que chega, ele é separado para cada ação do basket segundo os pesos do basket. Cada ação gasta apenas a sua própria reserva, e uma ação que o keeper pula mantém essa reserva para depois. Antes, a parte de uma ação pulada era dividida de novo por todo o basket: pulando ações, um keeper podia mover quase toda uma tesouraria para uma única ação.

Os dois vaults que compram ações funcionam assim: o vault espelho na Robinhood Chain, em USDG, e o vault do Ethereum no trilho local, em USDC.

Nos dois, desde o pipeline de segurança de 2026-10-01, uma transferência de emergência que deixa o caixa abaixo das reservas zera todas elas: o que resta, e toda entrada de caixa posterior, é dividido de novo segundo os pesos do basket. Uma emergência que leva só caixa não reservado, ou outro ativo, as mantém. Antes, a zeragem só existia na leitura que o vault fazia das suas reservas: as reservas antigas voltavam com a entrada seguinte, e a ordem das chamadas do keeper decidia a composição do basket.

O papel do keeper

Acionar, nada mais. Ele escolhe o momento, indica o valor de cada etapa, propõe rotas de swap e fornece valores mínimos — que o vault recusa se forem mais frouxos que o seu próprio limite de oráculo, ou se um valor ultrapassar o que está reservado para aquela ação. O keeper pode pedir mais do que o limite, nunca menos. Desde 2026-10-05, o vault aplica o mínimo do keeper ao que realmente chega.

O keeper gasta a reserva de cada ação por inteiro, exceto na última ação do basket, em que retém n−1 unidades, sendo n o número de ações: veja O keeper.

No trilho opcional da Ondo, o keeper entrega ao vault uma cotação assinada pelo emissor para cada perna. Uma cotação assim vale para quem a apresentar; por isso, desde 2026-10-05, o router da Ondo só atende os vaults da factory, o vault do protocolo e o de cada mercado registrado, e recusa qualquer outro (NotAVault): ninguém mais pode gastar a cotação do keeper e fazer essa conversão falhar. E cada router do protocolo recusa a si mesmo como destinatário de um swap, de modo que não detém nada entre transações.

O que quer que indique, o keeper não pode desviar um ativo, escolher outro basket, mover o caixa de uma ação para outra nem afrouxar um limite.

O airdrop

As ações do vault têm um único destino: os holders do token, a cada airdrop, pro rata à posição de cada um. A divisão decorre dos saldos, segundo uma regra que ninguém escolhe — nem o criador nem o keeper. O mecanismo está codificado desde 2026-10-04, não implantado: veja O airdrop.

No trilho local, o próprio vault entrega as suas ações. sendToAirdrop(stocks), só para o keeper, envia o saldo inteiro de cada ação listada do basket ao contrato do airdrop que a factory designa, lido em tempo real. O vault aprova os valores exatos, o contrato os puxa e os credita ao ciclo atual do mercado, e as aprovações são fechadas de novo antes de a chamada terminar. Uma ação listada duas vezes ou fora do basket faz a chamada falhar; uma ação sem saldo é ignorada. Desde 2026-10-05, cada ação vai isoladamente: uma cujo saldo não pode ser lido ou cuja transferência é recusada, por um congelamento do emissor, por exemplo, fica no vault com um evento (AirdropSendFailed), e as outras vão; quando nenhuma ação vai, a chamada falha e diz por quê. Um vault ligado ao hub da bridge recusa essa chamada: as suas ações são compradas e mantidas na Robinhood Chain, onde o vault espelho as envia da mesma forma, pelo adaptador LayerZero de cada ação.

O buyback do criador, buybackAndBurn(...), que permitia a um criador vender ações da tesouraria para recomprar e queimar o seu token, foi abandonado em 2026-09-27 e removido do código em 2026-09-28.

O que um vault pode deter

ETH, USDC, USDG e as ações do seu basket e, no trilho opcional da Ondo, o USDon que um mint do emissor pode reembolsar. Um vault não compra mais nada. Isso decorre do código; nenhum teste o verifica como invariante, e nada impede um terceiro de enviar um token alheio para o endereço de um vault. O modo de emergência retira um token assim como qualquer outro ativo.

Um vault cheio de USDC não está quebrado: está em trânsito. Os três estados são exibidos como a tesouraria à espera do próximo airdrop; só as ações são distribuídas, depois de compradas.

Um proxy por mercado

Desde 2026-10-02, o vault de cada mercado é o seu próprio proxy. Ele é criado com o mercado, na frente da implementação de vault que a factory designa naquele momento, e inicializado na mesma transação com o seu basket, o seu mercado, e o router, o oráculo e o hub da bridge que a factory designa então. O owner do StockFun faz o upgrade dos vaults um a um, mercado a mercado, com efeito imediato. Uma nova implementação designada na factory só alcança os mercados criados depois.

Os vaults espelho na Robinhood Chain seguem a mesma regra: veja O trilho Robinhood.

Modo de emergência

Desde 2026-08-29, o owner do StockFun pode movimentar qualquer ativo para fora de um vault, para qualquer endereço; desde 2026-10-05, a transferência é imediata, sem aviso prévio. Junto com o airdrop, é a única forma pela qual a implementação atual deixa os ativos saírem de um vault, e é tratado em Modo de emergência.