Status

Este livro descreve o protocolo tal como foi decidido. Parte do que ele descreve ainda não está no código. Esta página diz exatamente qual parte.

Decidido e implementado

• A taxa, 5 % por padrão, e as suas duas tabelas
• O TreasuryVault, os seus limites de oráculo e a sua ausência de saque
• O BuybackBurner e o flywheel do $STOCKFUN
• O modo de emergência, imediato desde 2026-10-05
• O trilho cross-chain até a Robinhood Chain, preparado e testado em simulação, em um único sentido desde a remoção do caminho de volta em 2026-09-28, e executado de ponta a ponta em duas testnets via LayerZero em 2026-10-06 (abaixo)
• O lançamento single-sided do token do protocolo $STOCKFUN
• A remoção do buyback do criador, em 2026-09-28
• A reformulação do lançamento, em 2026-09-28: não há mais bonding curve nem graduação; cada mercado é criado com as suas duas posições travadas, 700M e 300M por padrão, e a compra opcional do criador na mesma transação
• A taxa de criação, 0,001 ETH por padrão, um parâmetro do owner desde 2026-10-05
• O anti-snipe decrescente e a whitelist do criador, no máximo 20 endereços por padrão, isentos quando negociam pelo router oficial; o router oficial continua alterável pelo owner
• As taxas do criador mantidas no hook, mercado a mercado, e reivindicadas pelo criador; desde 2026-10-01, também as partes da equipe e do buyback, pagas por reivindicações que qualquer pessoa pode acionar
• Posições registradas onchain para cada token de mercado e para o $STOCKFUN, desde 2026-10-02 pelo registrador de posições, que cada token chama a cada transferência. Em 2026-10-01, com o registro ainda nos tokens, isso custava cerca de 52.000 a 61.000 de gas a mais por transferência entre duas carteiras, acima dos 20.000 a 40.000 estimados quando foi decidido. O PoolManager do Uniswap não é registrado, então um swap paga pelo lado do trader e, desde 2026-10-01, por uma escrita do supply registrado: 113.529 de gas por uma compra pelo router e 137.250 por uma venda, para uma carteira que já detém o token (125.862 e 150.416 antes das correções de 2026-10-01, que também removeram dois envios de cada trade)
• Sem taxa de LP do Uniswap nos pools do StockFun por padrão, desde 2026-09-29: a taxa do hook é todo o custo de um trade
• As correções da auditoria de segurança de 2026-09-29, aplicadas em 2026-09-30 e 2026-10-01: liquidez somente do lock de liquidez; partes da equipe e do buyback reivindicadas fora de qualquer trade; conversões em valores que o keeper indica, com o caixa reservado ação por ação; o supply registrado, o denominador do airdrop, em cada token; um trilho da Robinhood Chain em que um mercado não bloqueia mais um lote e um hub remoto pausado continua aplicando as mudanças de papéis. Cada achado corrigido tem testes de regressão
• O pipeline de segurança de 2026-10-01, uma segunda rodada de auditoria que completou várias dessas correções: na Robinhood Chain, uma rota v3 é executada um pool de cada vez e um ticket de contabilidade canônico não paga mais registros do que colocou na fila; uma emergência que deixa o caixa de um vault abaixo das suas reservas as anula; o keeper retém n−1 unidades na última ação de um basket. Cada correção tem testes de regressão
• A reformulação upgradável de 2026-10-02: todo módulo, exceto os tokens, o lock de liquidez e o deployer dos vaults espelho, por trás de um proxy, upgradável pelo owner do StockFun com efeito imediato; os vaults, um proxy por mercado, nas duas chains; os tokens reduzidos a um ERC-20 simples com um único setter, setRecorder, e, desde 2026-10-05, os seus rescues; o registro de posições no seu próprio módulo; o proxy do hook minerado com todas as 14 permissões v4; o modo de encerramento do lock de liquidez, com o seu aviso prévio de 30 dias; os layouts de storage registrados e verificados por um script. Um swap custa cerca de 27.000 de gas a mais, medido isoladamente: uma compra 237.190 de gas em vez de 210.105, uma venda 285.031 em vez de 258.278
• O contrato do airdrop, em 2026-10-04: o AirdropDistributor no Ethereum, upgradável e vinculado à factory, alimentado por sendToAirdrop nos dois vaults, e a rota do airdrop no hub remoto. Ciclos diários cuja janela fecha às 13:00 UTC, partes calculadas a partir das posições registradas, uma reivindicação por cada holder às suas custas, sem prazo de validade, teto nem mínimo, uma lista de exclusão por token, ações guardadas à parte para uma janela sem posições elegíveis, o modo de emergência. Os 514 testes fora das suítes de fork passam, incluindo um invariante com estado; a LayerZero é simulada por mocks nos testes. O Codex revisou o design, o código e as correções duas vezes, e a sua verificação final não encontrou nenhum bug. Não implantado
• As decisões de 2026-10-05: nenhuma alocação para a equipe, todo o supply do $STOCKFUN na sua posição travada; uma transferência de emergência imediata e uma substituição de adaptador imediata; todo número do protocolo como um parâmetro onchain do owner, nas duas chains, sendo os valores de hoje os padrões, com cada pool mantendo a taxa de LP e o tick spacing com que foi criado. Codificadas e testadas, não implantadas
• A regra de design do fundador, de 2026-10-05: uma falha nunca bloqueia o resto, e todo contrato que pode deter fundos tem uma alavanca para retirar o que ficou preso, com uma única exceção deliberada, a notificação do token ao seu registrador de posições; veja Arquitetura. O quarto loop de auditoria daquele dia a levou ao código: entregas da bridge que nunca bloqueiam outro mercado, reivindicações que pagam o que podem, cada perna da compra, cada ação do airdrop e cada mercado de um lote isoladamente, dívidas guardadas para um destinatário que recusa ETH em vez de um mercado paralisado, uma Lens que lê um vault de cada vez, e rescues nos módulos sem modo de emergência. Codificado e testado, não implantado
• Os cinco loops de auditoria de 2026-10-05 e as suas correções, entre elas: contas acertadas depois de uma transferência de emergência, nunca pagas com o caixa de outro mercado; o lote da bridge reservado ao keeper, e a pré-implantação dos vaults espelho, ao keeper e ao owner; um registrador designado num token em uso que não quebra mais a negociação nem mede uma janela anterior a ele; o operador do lançamento do $STOCKFUN excluído do airdrop antes da cunhagem; os tickets do trilho canônico precificados à taxa base; a verificação do storage em cada nível; a regra acima. Cada correção tem um teste de regressão; no fim do dia, 614 testes Foundry passam, com três suítes de fork puladas por falta de RPC. Não implantado
• A etapa do airdrop no keeper e a tela de reivindicação do dapp, em 2026-10-05, com as novas tarefas do keeper: pagar o que o hook e o lock guardam para um destinatário, alertar sobre o que continua falhando, planejar cada perna de ação isoladamente, um arquivo de estado que sobrevive a reinícios e a coleta diária das taxas de LP. Não implantado
• A passada offchain do quinto loop de auditoria, em 2026-10-06: o keeper converte o ETH de um vault uma vez por janela do airdrop, como decidido em 2026-09-27, registra cada transação antes de o seu recibo ser aguardado e mantém uma trava na sua pasta de estado, e não paga mais uma atestação da Ondo por uma compra que só pode falhar; um basket contém no máximo cinco ações; a Lens traz o estado e as dívidas de cada vault; o script de lançamento do $STOCKFUN retoma uma execução interrompida; o app conta o ETH devido a um vault, deixa nas reivindicações espaço para uma ação ainda a caminho, lembra uma ação que o seu token recusou e nunca mostra um número não lido como nada. 619 testes Foundry passam, com três suítes de fork puladas por falta de RPC. Um ensaio numa chain privada no mesmo dia rodou o keeper de ponta a ponta por duas janelas e passou nos seus seis cenários. Veja O keeper e O dapp. Não implantado
• As constatações do ensaio, corrigidas em 2026-10-06: o keeper aloca as ações que o contrato do airdrop guarda à parte para um mercado mesmo quando o seu vault não tem nada novo a enviar, de modo que um mercado que teve um trade e depois ficou parado não mantém mais o seu primeiro airdrop fora do alcance dos seus holders; ele registra um vault encontrado abaixo do limiar pela sua janela, nunca pelo seu próprio relógio; e o arquivo de implantação local é verificado contra a chain antes que o keeper, o app ou o worker o usem. 620 testes Foundry passam, com três suítes de fork puladas por falta de RPC. Veja O keeper. Não implantado
• O sexto loop de auditoria, corrigido em 2026-10-06: na bridge canônica, o keeper acompanha cada ticket até saber que ele foi executado, qualquer que seja o crédito da sua transferência, e credita uma transferência só pelos eventos do hub remoto; o USDC de um vault sai uma vez depois de cada conversão do seu ETH e no máximo uma vez por janela nos outros casos, como decidido para o ETH em 2026-09-27, com as compras na Robinhood Chain ainda rodando a cada passagem; uma busca de ações guardadas à parte que não pode alocar nada, para um vault sem nada a enviar, não é mais enviada todo dia; um vault abaixo do limiar é verificado com um saldo lido depois que a janela fecha; cada vault é cotado no seu próprio router; o app marca o preço do $STOCKFUN como "(last read)" enquanto a Lens não consegue lê-lo. Veja O keeper. Não implantado
• O sétimo loop de auditoria, corrigido em 2026-10-06: o keeper só envia ao airdrop o que vale o que custa enviá-lo, e a poeira que a bridge não consegue transportar não conta mais como algo a enviar; ele lê cada ticket canônico a partir do recibo da sua criação primeiro, então um depósito vivo nunca é tomado por executado; toda busca de logs para alguns blocos abaixo do bloco mais recente; ele se recusa a iniciar com um RPC que serve outra chain que não a configurada; o seu webhook de alertas guarda e envia de novo o que não aceitou; um parâmetro vazio assume o seu padrão. O Worker de dados do app lê cada contrato upgradável isoladamente, mostra o volume de 24 horas como desconhecido enquanto as suas leituras de trades falham, e verifica a chain de cada endpoint; o gráfico de preços coloca cada ponto no seu horário. 620 testes Foundry passam (615 fora dos arquivos de fork, e os cinco da suíte de fork da Robinhood Chain no seu RPC público; as três suítes de fork do Ethereum puladas por falta de RPC); os 277 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 137 do worker passam. Veja O keeper e O dapp. Não implantado
• As proteções dos feeds de preço na Robinhood Chain, codificadas em 2026-10-06: o oráculo retém o preço de uma ação enquanto o seu token diz que o seu oráculo está pausado por um evento corporativo, ligada para toda ação, e todos os preços enquanto o feed de disponibilidade do sequenciador da Chainlink diz que o sequenciador está fora do ar ou acabou de voltar. Não existe nenhum feed assim para a Robinhood Chain, então essa segunda verificação fica desligada na implantação, por uma escolha explícita, até que um seja publicado. As duas são parâmetros do owner, desligadas no Ethereum. Veja O trilho Robinhood. Não implantado
• O oitavo loop de auditoria, corrigido em 2026-10-06: o formulário de lançamento do app só oferece os baskets lidos da chain e verifica de novo o escolhido antes do envio; o keeper acompanha um lote da bridge depois que o seu bloco está a alguns blocos de profundidade, distingue a poeira da bridge de uma ação cuja taxa não pode ser cotada, guarda um único alerta em espera por alerta distinto, segura um arquivo de estado de outra chain até ter lido a chain do seu RPC, exige os dois identificadores de chain, lê um ticket alguns blocos abaixo do mais recente e conta a abertura do trilho local uma vez; o keeper, o seu preflight e o seu inspetor, o Worker e o app passaram a conhecer as proteções dos feeds de preço; a janela de trades do Worker nunca anda para trás, e o painel de trade cobra de uma carteira da whitelist a taxa normal. 640 testes Foundry passam (633 fora dos arquivos de fork, e os sete do arquivo de fork da Robinhood Chain no seu RPC público; as três suítes de fork do Ethereum puladas por falta de RPC); os 306 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 155 do worker passam. Veja O keeper e O dapp. Não implantado
• O gas da entrega do airdrop sob a atualização Glamsterdam do Ethereum, que a Sepolia ativou em 2026-10-06: a decisão do fundador daquele dia, com o keeper simulando cada entrega e escolhendo o seu gas dentro de limites que o owner do StockFun define no hub remoto, e executando de novo uma entrega ainda presa, com um alerta numa segunda falha. Codificado e testado, aplicado por upgrade na execução em testnet, não implantado na mainnet. Veja O keeper
• O nono loop de auditoria, corrigido em 2026-10-06, com os achados da execução em testnet com a LayerZero: o keeper lê no bloco da sua própria última transação durante um minuto e estima ali o gas do que envia em seguida, dá a cada transação a sua estimativa mais 25 %, entrega os seus alertas em espera na ordem em que foram emitidos pela última vez, não alerta mais um ticket que a sua própria reexecução apagou, e o seu preflight roda sobre a implantação de testnet; o Worker mantém o que aprendeu dos seus RPCs quando o seu objeto na Cloudflare dorme, e registra o bloco próprio da Robinhood Chain; o app dá a cada escrita o seu próprio limite de gas, marca um pote que é uma estimativa, e nunca toma por nenhuma uma aprovação que não conseguiu ler. Desde este loop, um segundo agente revisa cada correção antes que ela seja enviada ao repositório, e os seus achados são corrigidos da mesma forma. 653 testes Foundry passam (646 fora dos arquivos de fork, e os sete do arquivo de fork da Robinhood Chain no seu RPC público; as três suítes de fork do Ethereum puladas por falta de RPC); os 370 testes do keeper (372 depois da última correção do gate), os 51 do pacote compartilhado, os 9 do back end e os 189 do worker passam. Veja Testes e verificação. Não implantado na mainnet
• O décimo loop de auditoria, corrigido em 2026-10-06: toda transmissão da implantação usa a estimativa de gas do nó, já que o número próprio da ferramenta de implantação fica aquém para toda criação sob a Glamsterdam; o último passo de um lote da bridge na Robinhood Chain recebe uma base mais uma parte por mercado, no máximo 17 mercados por lote, com o keeper não enviando mais do que isso e dizendo onde está um lote parado; a vigilância de emergência do keeper nomeia os seus contratos em grupos, os seus textos de erro mantêm só o host de um endereço de RPC, e ele lê cada mercado pelo Multicall3; o app nunca mostra como feita uma transação que a carteira cancelou, e lê durante um minuto num bloco não anterior ao da sua própria última transação. O adaptador da bridge da testnet recebeu upgrade e levou o seu lote seguinte. 662 testes Foundry passam (655 fora dos arquivos de fork, e os sete do arquivo de fork da Robinhood Chain no seu RPC público; as três suítes de fork do Ethereum puladas por falta de RPC), com os 2 do projeto da execução em testnet com a LayerZero; os 400 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 210 do worker passam. Veja Testes e verificação. Não implantado na mainnet
• Sobras de um ciclo interrompido levadas até o fim no próximo ciclo, decidido em 2026-09-27: o keeper faz seguir adiante o caixa que um vault ainda detém, qualquer que seja o limiar, no mais tardar na janela seguinte

Uma ordem de implementação, em etapas que mantêm o repositório compilando, está registrada em projet/docs/FUNCTIONAL_AUDIT_2026-09-28.md.

Decidido em 2026-09-27, ainda não implementado

Nada mais. A etapa diária do airdrop no keeper e a tela de reivindicação dos holders no dapp estão no código desde 2026-10-05, e as sobras de um ciclo interrompido são levadas até o fim no próximo ciclo, com o keeper fazendo seguir adiante o caixa que um vault ainda detém, qualquer que seja o limiar: veja acima.

Os documentos de doc/ e a especificação da landing foram alinhados a esta decisão em 2026-09-27. No código, a remoção do buyback do criador foi concluída, desde 2026-10-04 está o contrato do airdrop, com o seu cálculo das partes e as suas reivindicações, e desde 2026-10-05, a etapa do keeper e a tela de reivindicação.

Decidido em 2026-09-28, ainda não implementado

• Os adaptadores de ações que levam as ações wrapped ao Ethereum, um por ação: o adaptador de travamento na Robinhood Chain e o seu OFT no Ethereum. Eles precisam do pacote oft-evm da LayerZero e não estão no repositório para a mainnet; os testes usam mocks, e a execução em testnet com a LayerZero de 2026-10-06 usou adaptadores de teste construídos com esse pacote. A reivindicação no Ethereum está codificada desde 2026-10-04, e a sua tela no dapp desde 2026-10-05
• A configuração da LayerZero dos adaptadores de ações nas mãos do owner, sem prazo e sem teto de saques

Decidido em 2026-09-11, parcialmente propagado

A migração da Ondo para a Robinhood Chain está decidida e o código do trilho existe. Nem todos os documentos-fonte do projeto foram atualizados — veja Errata das fontes.

Nunca verificado em condições reais

• Nenhuma implantação em mainnet foi feita
• Nenhum transporte via LayerZero foi exercitado na mainnet. Em 2026-10-06, a execução em testnet com a LayerZero levou os lotes da bridge e as entregas do airdrop entre a Sepolia e a testnet da Robinhood Chain sobre os endpoints, o DVN e o executor reais de testnet da LayerZero, sete janelas horárias e seis ciclos do airdrop, cada reivindicação exatamente a sua parte calculada. Ela usou ações de teste, adaptadores de teste, um USDG de teste e feeds simulados: ela não prova nem o par USDG da Paxos, nem as ações da Robinhood e os seus adaptadores, nem feeds e liquidez reais, nem o gas, as taxas e a finalidade da mainnet. Veja O trilho Robinhood
• As provas formais existentes não cobrem o trilho cross-chain atual
• Sete regras da especificação formal do LiquidityLock continuam sem decisão no prover para um método, lockProtocolLiquidity, mesmo com um limite de tempo maior; elas valem em todos os outros métodos. A nova execução de 2026-10-01, sobre o código corrigido, não encontrou nenhuma regra violada
• As especificações formais estão sendo atualizadas para a reformulação de 2026-10-02: a sua última execução completa no prover, em 2026-10-01, é anterior a ela. Para o airdrop de 2026-10-04, as cinco especificações que tocam os contratos alterados passam na verificação de tipos, sem execução no prover. Em 2026-10-05, as especificações foram atualizadas para os parâmetros, depois para os loops de auditoria daquele dia, que acrescentaram regras sobre as dívidas e o que está extraviado no hook, as partes guardadas pelo lock e cada rescue: elas passam na verificação de tipos, sem execução no prover desde 2026-10-01. O mesmo vale para as novas regras do oráculo para as suas proteções dos feeds de preço, escritas em 2026-10-06
• Os pagamentos de dívidas do keeper, a coleta das taxas de LP, os alertas e o arquivo de estado, escritos em 2026-10-05, são cobertos pelos seus testes e, desde 2026-10-06, por um ensaio numa chain privada: conversões uma vez por janela, o airdrop, um vault que recusa ETH e as suas dívidas pagas, interrupções no meio da operação com o arquivo de estado e a sua trava, as taxas de LP. O trilho da bridge não rodou ali; ele rodou de ponta a ponta na execução em testnet com a LayerZero de 2026-10-06, pelo keeper, nunca em condições reais
• Nenhuma revisão externa foi conduzida

Ainda a decidir antes da mainnet

• Um levantamento atualizado da cobertura de feeds na Robinhood Chain e, caso a Chainlink publique um feed de disponibilidade do sequenciador para essa chain, defini-lo no oráculo (não existe nenhum em 2026-10-06)
• O limite de tamanho da rota da LayerZero que o USDG da Paxos usa até a Robinhood Chain, lido antes do primeiro lote, e o teto de mercados de um lote da bridge ajustado de acordo se ele diferir dos 10.000 bytes padrão (desde o décimo loop de auditoria)
• FDV inicial e limite superior da posição do $STOCKFUN
• O trabalho que falta no airdrop, listado acima: os adaptadores de ações. Os seus parâmetros estão definidos desde 2026-10-04: nenhum envio pelo keeper, nenhum teto, nenhum mínimo, nenhum prazo de validade, uma lista de exclusão por token
• A métrica que substitui o Treasury Ratio, e o slogan e a tagline, que descrevem uma tesouraria que acumula
• Os achados da segunda rodada da auditoria, em 2026-10-01, que ainda aguardam a decisão do owner: a margem da última ação do lado dos contratos, que muda a regra de alocação documentada (R2T-1); e, opcionalmente, fazer a factory implantar ela mesma o vault do $STOCKFUN (R2F-2). Desde 2026-10-05, um vault que recusa ETH não paralisa mais o seu mercado, então a paralisação que R2F-2 descrevia não decorre mais de um vault assim

Resolvidos em 2026-10-05. Da auditoria de 2026-09-29: as atestações da Ondo que qualquer pessoa que visse uma delas podia gastar (M-7) e os routers que aceitavam a si mesmos como destinatário (L-4) estão corrigidos, e a rotação do adaptador da bridge (M-2, e L-8, ligado a ela) fica como está, por decisão do owner. Da segunda rodada: cobrar a taxa de compra em claims do PoolManager (R2F-1, option b) foi recusado, e a taxa continua sendo cobrada como hoje; uma emergência sobre o caixa registrado do hub remoto, cujos registros eram então pagos com o caixa de outros mercados (R2H-1), está coberta pelas ferramentas de acerto das contas dos loops de auditoria daquele dia e por um procedimento, com o owner pausando o hub remoto antes da transferência no trilho canônico; e um token da perna de caixa que recusa um vault espelho (R2H-2) não bloqueia mais nada desde o quarto loop de auditoria: a entrega a esse vault espera isoladamente, e os outros mercados são pagos.