Modo de emergência

Desde 2026-08-29, o owner do StockFun pode movimentar os ativos de uma tesouraria, ou de qualquer contrato que detenha fundos do protocolo, para qualquer endereço. Desde 2026-10-05 a transferência é imediata: sem aviso prévio, sem prazo, e nenhum parâmetro pode acrescentar um. É a mudança de maiores consequências do projeto, e ela alterou o que o produto pode dizer.

O que ele permite

emergencyTransfer(asset, amount, to), chamada no contrato que detém o ativo, movimenta esse valor de qualquer ativo — ETH, USDC, USDG, ações tokenizadas, tokens de mercado — para to, de imediato. Cinco contratos a possuem: o TreasuryVault, o BridgeHub e, desde 2026-10-04, o contrato do airdrop, AirdropDistributor, no Ethereum; o RemoteHub e os vaults espelho na Robinhood Chain. Só o admin de emergência deles pode chamá-la: o owner da factory no Ethereum e, na Robinhood Chain, o mesmo endereço, tal como o último lote da bridge o levou. O owner pode usá-la em qualquer um desses contratos, a qualquer momento.

Cada transferência recebe um id sequencial e emite um evento público, EmergencyExecuted, com o ativo, o valor e o destinatário. Nada a anuncia de antemão.

Até 2026-10-05, o owner agendava a movimentação: um evento público a anunciava, o owner podia cancelá-la durante 48 horas, e qualquer pessoa podia executá-la depois. Esse agendamento acabou, e o prazo não é um parâmetro: uma emergência age assim que o owner a usa, nunca depois de uma espera. Com ele vai embora a exceção prevista para os fundos de airdrop presos num vault espelho, que nunca foi codificada: a transferência imediata já os cobre.

Junto com ele: uma pausa nas conversões e no bridging — imediata, sem movimentar fundos — e a substituição do adaptador da bridge para envios futuros, changeAdapter, também imediata desde 2026-10-05. No contrato do airdrop, a pausa interrompe os envios, a abertura de ciclos (openCycle) e a alocação das ações guardadas à parte (assignUnassigned); ela não movimenta nada e nunca interrompe uma reivindicação.

Desde 2026-10-01, um hub remoto pausado continua aplicando as mudanças de keeper e de admin de emergência que cada lote leva, então uma mudança de owner sempre chega à Robinhood Chain; o caixa que ele recebe nesse meio-tempo espera lá, registrado por mercado, até um sweep depois do fim da pausa.

A auditoria de segurança de 2026-09-29 constatou que a substituição do adaptador não pode funcionar de ponta a ponta: o hub remoto só aceita lotes do adaptador original, então todo lote enviado depois de uma substituição esperaria no hub remoto até que o modo de emergência o recuperasse (M-2). Em 2026-10-05, o owner decidiu manter como está: um adaptador é trocado por um upgrade no lugar, no mesmo endereço, e um novo endereço exigiria primeiro um upgrade do hub remoto para aceitá-lo.

Num vault, desde o pipeline de segurança de 2026-10-01, uma transferência de emergência que deixa o caixa abaixo das reservas das ações 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. O caixa retirado e enviado de volta a um vault é dividido como qualquer entrada de caixa, e não devolvido à ação para a qual estava reservado.

A segunda rodada da auditoria, em 2026-10-01, constatou que, no hub remoto, uma emergência que leva caixa já registrado para um mercado deixa o registro no lugar, a ser pago com o caixa de outros mercados (R2H-1). Desde 2026-10-05, uma transferência é seguida de um acerto das contas, descrito abaixo, e esse caso é coberto pelas ferramentas desse acerto e por um procedimento: no trilho canônico, o owner do StockFun pausa o hub remoto antes da transferência. Desde o quarto loop de auditoria daquele dia, uma transferência também pode ser imputada a um único mercado, o que acerta as suas contas na mesma chamada.

Depois de uma transferência: acertar as contas

Desde 2026-10-05, depois dos loops de auditoria daquele dia. A transferência em si não muda: imediata, sem nenhuma condição. Mas dois contratos detêm ativos que lastreiam o que é devido a vários mercados: o contrato do airdrop e o hub remoto. Depois de uma transferência para fora de qualquer um deles, as contas são acertadas, nunca pagas por outro mercado. Ou os ativos voltam, ou o owner do StockFun dá baixa da perda no mercado que a sofreu.

Os dois contratos contabilizam o que lastreia as suas contas, nunca o seu saldo. O saldo também inclui tokens que chegaram mas ainda não foram creditados: uma entrega de ações cuja última etapa no Ethereum ainda não foi executada ou, no trilho do USDG, o caixa de um lote cuja última etapa na Robinhood Chain ainda não foi executada. Esses tokens ainda não lastreiam nada, e podem pertencer a outro mercado. Até o segundo loop de 2026-10-05, os contratos liam o saldo, então esses tokens podiam reabrir as reivindicações de um ciclo esvaziado e pagá-las com as ações de outro mercado.

Uma transferência de emergência leva primeiro do que lastreia as contas. Não há como distinguir os tokens uns dos outros, e contar primeiro como retirados os já creditados nunca faz um mercado pagar por outro. O que ela leva além disso veio de tokens ainda não creditados: o contrato o registra (taken, cashTaken), e as próximas entregas desse ativo o quitam antes de lastrear qualquer coisa.
Os ativos voltam via restore. Qualquer pessoa pode chamá-lo; ele puxa os tokens do chamador. Uma transferência simples para o contrato não lastreia nada. Desde o terceiro loop de auditoria de 2026-10-05, restore primeiro devolve o que uma transferência levou além do que lastreia as contas (taken, cashTaken), e lastreia as contas com o resto: os tokens de uma entrega que ainda espera nunca pagam um mercado esvaziado.
Tokens extraviados. Tokens que chegaram ao contrato do airdrop, ou ao hub remoto no trilho do USDG, sem nunca terem sido creditados, enviados para lá por engano, também são descontados do que lastreia as contas se uma transferência de emergência os retirar. Uma transferência de emergência só os retira para repô-los; caso contrário, é preciso dar baixa do seu valor no ciclo ou no mercado sobre o qual ele recai, ou eliminá-lo com um upgrade.
O contrato do airdrop contabiliza, ação por ação, o que deve e o que o lastreia, e só paga uma ação enquanto o que o lastreia cobrir o que ele deve. Depois de uma transferência que levou parte de uma ação, as reivindicações dessa ação esperam, em todo mercado que a detém, até que a ação volte via restore ou até que o owner dê baixa da perda no ciclo que a sofreu (writeDownCycle), ou nas ações que um mercado guarda à parte (writeDownUnassigned). Enquanto ninguém tiver reivindicado essa ação do ciclo, o owner pode dar baixa de qualquer parte dela, e todo holder do ciclo perde a mesma proporção; depois que alguns holders tiverem sido pagos, o owner só pode dar baixa de todo o restante, que os holders ainda não pagos perdem, ou trazer a ação de volta. Tudo o que chega a esse ciclo depois é dividido pro rata entre todos os seus holders, como se o valor baixado nunca tivesse estado lá. Nenhum outro ciclo paga pela perda. Desde o quarto loop de auditoria, uma reivindicação só adia a ação que espera (ClaimDeferred) e paga as outras na mesma chamada; até então, ela falhava inteira. O contrato do airdrop não tem transferência imputada a um único ciclo: o seu limite de tamanho não deixou espaço. O procedimento que nunca deixa as suas contas ficarem aquém dá baixa primeiro no ciclo, ou nas ações guardadas à parte, e depois movimenta a ação; uma transferência feita primeiro mantém a espera geral descrita acima.
O hub remoto, no trilho do USDG, contabiliza o caixa que lastreia o que ele deve e se recusa a pagar (sweep) enquanto esse caixa ficar aquém. Depois de uma transferência que levou mais do que isso, os próximos lotes são registrados em vez de entregues até que tenham compensado o que ela levou a mais. O owner traz o caixa de volta (restore), ou dá baixa de um valor que está perdido, ou que a transferência entregou manualmente ao vault espelho do mercado (writeOffPending). Desde o quarto loop de auditoria, o owner também pode imputar uma transferência a um único mercado: emergencyTransferFromPending(marketId, amount, to) movimenta o que o hub deve a esse mercado e dá baixa disso na mesma chamada, de modo que as contas nunca ficam aquém e nenhum outro mercado espera.
O hub remoto, no trilho canônico, deve os registros da sua fila e não mantém essa contagem: a proteção é um procedimento. O owner pausa o hub antes da transferência, movimenta o caixa, remove o registro ao qual esse caixa pertencia (writeOffRecord) e então encerra a pausa, para que a fila nunca pague esse registro uma segunda vez com o caixa de outro mercado. Desde o quarto loop de auditoria, uma única chamada faz isso para um registro: emergencyTransferRecord(index, to) movimenta o valor inteiro do registro e o remove. Desde o quinto, essa chamada serve para um registro cujo depósito já chegou: o caixa da fila é comum, então ela recusa um valor além do caixa não retido para partes recusadas (RecordNotCovered); um registro cujo depósito se perdeu é removido com writeOffRecord. Uma parte que um vault espelho recusou, retida à parte para o seu mercado (undeliverable), é movimentada e baixada com emergencyTransferFromPending.

Cada baixa emite um evento público (WrittenDown, PendingWrittenOff), assim como cada devolução (Restored) e cada reivindicação adiada (ClaimDeferred).

Rescues: o que um módulo detém por engano

Desde 2026-10-05, pela regra do fundador de que tudo o que pode deter fundos tem uma alavanca (veja Arquitetura), os contratos sem modo de emergência têm um rescue próprio, para o que lhes foi enviado por engano ou deixado por uma operação que falhou. Só o owner do StockFun o chama: o owner da factory no Ethereum, o admin do hub remoto na Robinhood Chain, o mesmo endereço que faz o upgrade dos módulos. Cada rescue emite um evento público.

Os módulos que não guardam nada de ninguém entre transações — a factory, a Lens, os oráculos, o registrador de posições, os routers de ações, o router de swap oficial e os adaptadores da bridge — têm rescue(asset, amount, to), para ETH (o endereço zero) ou qualquer token
O hook só retira o que está extraviado: no máximo o ETH enviado a ele por qualquer um que não seja o PoolManager (strayEth), e qualquer token, já que ele nunca detém nenhum. Os saldos dos criadores, da equipe e do buyback e as dívidas com os vaults nunca saem por esse caminho. O ETH forçado sem chamada não é contado, e espera um upgrade
O lock de liquidez, que não pode receber upgrade, retira qualquer token, e o ETH além das partes que guarda para vaults e criadores (totalOwed), que nunca saem por esse caminho; desde o quinto loop de auditoria, também claims da v4 creditados a ele no PoolManager (rescueClaims) e um NFT enviado a ele por uma transferência simples (rescueNft). Ele não tem nenhuma chamada genérica: através do PoolManager, seria possível chegar à recuperação do modo de encerramento sem os seus 30 dias. As suas posições continuam alcançáveis só pelo modo de encerramento
O BuybackBurner retira um token a qualquer momento, e o seu ETH só quando nenhum burn puder mais gastá-lo: antes de o mercado do protocolo ser designado, ou depois que o modo de encerramento tiver recuperado o pool do $STOCKFUN. Enquanto esse pool estiver travado, o seu ETH só sai por burns
Os tokens, que não podem receber upgrade, retiram o que foi enviado ao seu próprio endereço: os seus próprios tokens, notificados ao registrador de posições como qualquer transferência, qualquer outro token, o ETH forçado e, desde o quinto loop de auditoria, claims da v4 e NFTs (rescue, rescueClaims, rescueNft). Nenhum saldo de holder pode se mover por esse caminho
Os contratos de implementação por trás dos proxies nunca são usados diretamente. Nos da factory e do hub remoto, que guardam o seu admin no storage do proxy, a alavanca para o que é enviado ao seu próprio endereço é o endereço que os implantou; todas as outras implementações leem o seu admin pela sua autoridade, o owner do protocolo

Os vaults, os dois hubs e o contrato do airdrop mantêm o modo de emergência em vez disso, já que mantêm contas próprias. Os dois deployers no Ethereum e o deployer dos vaults espelho não guardam estado, não aceitam ETH e não têm owner: não precisam de alavanca.

O que ele não permite

O modo de emergência não toca no registro de feeds. Ele movimenta ativos; não muda os limites de execução, que são parâmetros separados do owner. Ele não consegue fazer um vault comprar qualquer coisa a qualquer preço; ele pode levar, de imediato, o que estiver num vault.

Também não pode tocar na liquidez travada nem nos tokens dos holders. O mesmo vale para o airdrop: o modo de emergência pode movimentar as ações do contrato do airdrop, mas não pode mudar como um ciclo é dividido entre os seus holders. As partes ficam como estão; desde 2026-10-05, uma reivindicação só é paga enquanto o que lastreia as contas do contrato cobrir tudo o que ele deve nessa ação, e uma perda que não vai voltar é descontada do ciclo que a sofreu, nunca de outro (acima).

Mas ele não é o único caminho do owner até um vault. Desde 2026-10-02, o owner do StockFun também pode fazer o upgrade de um vault, ou do oráculo que ele lê, com efeito imediato. A liquidez travada tem a sua própria saída, o modo de encerramento, anunciado com 30 dias de antecedência: o único prazo fixo do protocolo. Veja Modelo de confiança.

Por que ele existe

A revisão dos modos de falha cross-chain fez uma pergunta simples: o que acontece quando uma rota falha, uma mensagem da bridge se perde ou um contrato tem um bug?

Sem um caminho de recuperação, a resposta é "os fundos estão perdidos, permanentemente". O protocolo escolheu um caminho de recuperação controlado, nas mãos do seu owner e registrado onchain, em vez da elegância de um sistema que não consegue reparar nada. Desde 2026-10-05, esse caminho age assim que é usado.

Desde 2026-10-01, é também por ele que o caixa de um mercado cujo basket a Robinhood Chain recusou sai do vault espelho desse mercado, que continua não inicializado: veja O trilho Robinhood.

O que ele custa

O owner pode movimentar os ativos de uma tesouraria para qualquer endereço, de imediato e sem aviso prévio. Isso está registrado no modelo de confiança do projeto.

Acima de tudo, a formulação validada substitui todas as promessas anteriores.

Os ativos são mantidos pelo vault do mercado e regidos pelas suas regras. A equipe do StockFun pode movimentar os ativos de uma tesouraria em caso de emergência, após um prazo público de 48 horas.

Desde 2026-10-05, o prazo desta frase não existe mais: a transferência é imediata. A frase precisa ser revista, e a sua nova formulação, validada. Desde 2026-10-02, ela também não cobre os upgrades dos vaults, que têm efeito imediato.

O produto não pode mais dizer non-custodial, trustless, tesouraria imutável ou ninguém pode tocar na tesouraria. Essas expressões são banidas pelas regras de marca; a auditoria de copy automatizada não as verifica, a revisão sim.

O modo de emergência nunca é descrito como uma proteção nem como uma garantia contra perdas. É um poder da equipe, com efeito imediato. Nada mais.

O que o usuário vê

Até 2026-10-05, um banner devia anunciar uma recuperação agendada em cada superfície afetada, com a data de execução. Uma transferência agora é imediata, então não há nada a anunciar de antemão: ela se torna visível depois do fato, no evento EmergencyExecuted do contrato de onde saiu.