Modelo de confiança

Quem pode fazer o quê. A resposta honesta, não a de marketing.

Desde 2026-10-02, quase todos os contratos do protocolo são upgradáveis: o owner do StockFun pode substituir o seu código, com efeito imediato. Desde 2026-10-05, os números do protocolo, da taxa ao ciclo do airdrop, também são parâmetros onchain do owner, igualmente com efeito imediato: os valores que este livro dá são os seus padrões, listados abaixo com o que continua fixo. Toda regra que este livro atribui a um módulo é a regra da sua implementação atual. Fora do poder de upgrade: os tokens, o lock de liquidez e, na Robinhood Chain, o deployer dos vaults espelho.

O que ninguém pode fazer

Estes pontos se apoiam em contratos que não são upgradáveis. Eles valem quaisquer que sejam os upgrades ou os parâmetros do owner.

• Cunhar novos tokens. O supply é cunhado uma única vez, no construtor, e os tokens não são upgradáveis
• Movimentar os tokens de um holder sem uma autorização dele. O setter dos tokens, setRecorder, não movimenta nenhum saldo, e os seus rescues, desde 2026-10-05, só movimentam o que foi enviado ao próprio endereço do token
• Remover a liquidez de um pool sem um aviso prévio público de 30 dias. O lock não é upgradável, a sua única saída é o modo de encerramento, abaixo, e os seus 30 dias são uma constante, não um parâmetro. Os seus rescues, desde 2026-10-05, não alcançam nem as posições nem as partes de taxas que ele guarda para os seus destinatários
• Mudar a taxa de LP ou o tick spacing de um pool em funcionamento. Cada pool mantém os que recebeu na criação: eles fazem parte da sua chave, que o lock guarda

O que o código atual exclui

Ninguém pode fazer isto com as implementações atuais, inclusive o owner. Cada ponto se apoia num módulo upgradável pelo owner.

• Adicionar liquidez a um pool do StockFun. Só o lock de liquidez pode, desde 2026-10-01
• Bloquear a negociação por meio de uma carteira de taxas ou de um vault. Só a parte da tesouraria é paga durante um trade e, desde 2026-10-05, um vault que a recusa passa a ter o valor devido a ele; as outras são reivindicadas depois
• Mudar a composição de um basket depois da criação
• Mudar os feeds de preço que um vault existente lê. Cada feed é gravado uma única vez, na inicialização do oráculo, e cada vault mantém o seu oráculo; os heartbeats dos feeds são parâmetros e, desde 2026-10-06, também as duas salvaguardas do oráculo na Robinhood Chain, que só podem reter um preço, nunca mudá-lo
• Enviar os tokens do buyback de $STOCKFUN para qualquer lugar que não seja o burn
• Escolher quem recebe um airdrop, ou reivindicar a parte de outra pessoa. A divisão decorre das posições registradas, pro rata, e só o holder reivindica

O que um criador pode fazer

• Ganhar a linha do criador de cada trade do seu mercado, 2 % por padrão, e reivindicá-la, desde 2026-10-05 para outro endereço se quiser (claimCreatorFeesTo)
• Definir a whitelist anti-snipe do seu mercado, cujos endereços pagam a taxa normal durante os primeiros blocos: no máximo 20 endereços por padrão, fixados na transação de criação, públicos e inalteráveis depois disso
• Comprar e vender o próprio token, como qualquer pessoa

Ele não recebe nenhuma alocação, não controla a liquidez e não pode pausar o seu mercado. Não tem nenhum poder sobre a tesouraria: só recebe ações como qualquer holder.

O que o keeper pode fazer

Acionar as conversões, no momento que escolher, nos valores que indica, pelas rotas que propõe. Sempre dentro dos limites de oráculo do vault e da reserva de cada ação, e nunca escolhendo quem recebe o quê. Desde 2026-10-01, pular uma ação não muda mais os pesos do basket: essa ação guarda a sua parte para depois. Desde 2026-10-05, o vault aplica o mínimo que o keeper indica ao que realmente chega. Desde 2026-10-06, o keeper converte o ETH de um vault uma vez por janela do airdrop, como decidido em 2026-09-27: essa é uma regra do próprio keeper, que o vault não impõe; o vault só registra quando o seu ETH foi convertido pela última vez.

Desde 2026-10-05, ele também é o único que envia um lote da bridge (bridgeReady) e, com o owner do StockFun, o único que pré-implanta o vault espelho de um mercado na Robinhood Chain (predeploy). Até então, as duas coisas estavam abertas a qualquer pessoa. O hub remoto passa a conhecer o keeper por meio de um lote, então, antes do primeiro lote, o owner do StockFun pré-implanta o vault do primeiro mercado, e um mercado cujo vault o keeper não consegue pré-implantar fica de fora do seu lote.

No airdrop, desde 2026-10-04: abrir o ciclo de um mercado (openCycle), enviar as ações de um vault ao contrato do airdrop (sendToAirdrop, pagando as taxas da LayerZero a partir da Robinhood Chain) e alocar as ações guardadas à parte (assignUnassigned). Ele escolhe quando, nunca quanto, o quê, para onde ou para quem: o valor é o saldo do vault, o destino é o contrato que o protocolo designa, e a divisão decorre das posições. Qualquer pessoa pode abrir um ciclo ou alocar ações guardadas à parte, com o mesmo resultado seja quem for que chame. Um envio que chega depois do horário de fechamento seguinte, 13:00 UTC por padrão, é medido na janela do dia seguinte. A sua etapa diária está escrita desde 2026-10-05: veja O keeper. Desde o sétimo loop de auditoria, em 2026-10-06, ele só envia uma ação quando ela vale o que custa enviá-la, o que só decide quando essa ação sai: o que espera fica no vault para uma janela posterior. Desde o nono, no mesmo dia, ele também indica o gas que cada entrega recebe no Ethereum, que o hub remoto mantém entre o piso e o teto que o owner do StockFun define, e executa de novo a partir da sua própria chave uma entrega presa no endpoint da LayerZero no Ethereum, o que qualquer pessoa pode fazer: nenhuma das duas coisas muda o que é entregue, nem onde.

Desde 2026-10-05, ele também paga, a cada ciclo, o que o hook e o lock guardam para um destinatário que o recusou (payTreasury, payOwed), e coleta as taxas de LP de um pool criado com uma (collectFees). Qualquer pessoa pode fazer essas três chamadas, que só pagam os destinatários que os contratos designam.

A sua chave é uma chave quente. Ele nunca escolhe para onde vai um ativo.

O que o owner do StockFun pode fazer

É aqui que está a confiança real. O owner do StockFun é o owner do protocolo: o owner da factory no Ethereum, que o hub remoto espelha na Robinhood Chain.

• Fazer o upgrade de todos os módulos, exceto os tokens, o lock de liquidez e o deployer dos vaults espelho, com efeito imediato e sem aviso prévio. Os vaults recebem upgrade um a um, mercado a mercado, nas duas chains
• Mudar os números do protocolo, com efeito imediato e sem aviso prévio: a taxa, a sua divisão e o anti-snipe, a taxa de criação, o formato dos novos mercados, o limiar de conversão e os limites de preço dos vaults, o ciclo do airdrop, e os outros listados abaixo
• Iniciar o modo de encerramento do lock e, 30 dias depois, recuperar toda a liquidez de cada pool, inclusive a do $STOCKFUN, para qualquer endereço
• Designar o registrador de posições ao qual cada token notifica as suas transferências. Se a notificação falhar, a transferência falha: a única exceção deliberada à regra de que uma falha nunca bloqueia o resto (veja Arquitetura), com duas alavancas imediatas, setRecorder(0), que interrompe o registro do token, e um upgrade do registrador no lugar. Desde 2026-10-05, um token recusa um registrador vinculado a outro PoolManager do Uniswap que não o do seu pool. O registrador recebe upgrade no lugar, o que preserva o seu histórico, e não é substituído num token em uso: desde 2026-10-05, um registrador substituto parte do supply do token fora do PoolManager do Uniswap, então a negociação continua, e o airdrop não mede nenhuma janela que começou antes dele; mas ele lê os holders que não viu se mover como não tendo detido nada até o seu próximo movimento, de modo que uma janela que eles atravessam lhes paga menos, e ninguém recebe a mais. Até 2026-10-05, um registrador novo fazia toda venda falhar e quebrava as partes de airdrop dos ciclos abertos depois
• Registrar baskets, antes de serem congelados
• Definir os endereços write-once, uma única vez
• Definir o keeper e as carteiras de taxas. Uma reivindicação paga a carteira definida no momento da reivindicação, então uma mudança também redireciona o saldo da equipe ou do buyback ainda não reivindicado
• Mudar o swap router oficial registrado na factory, aquele pelo qual o hook reconhece a whitelist anti-snipe
• Apontar os vaults futuros para outro router de ações ou outro registro de oráculos; os vaults existentes mantêm os seus
• Mapear cada ação de um basket para o seu token da Robinhood Chain, apenas por acréscimo
• Definir a lista de exclusão do airdrop de cada token, para as janelas que fecham depois (setExclusions); registrar o OFT de cada ação no Ethereum (registerStockOft)
• Designar o contrato do airdrop para o qual os vaults enviam (setAirdropDistributor); um contrato substituído mantém cada ciclo reivindicável onde está. Na Robinhood Chain, designar a rota do airdrop, o contrato e o gas de cada entrega (setAirdrop), e o adaptador de cada ação (setStockAdapter); desde 2026-10-06, definir o padrão, o piso e o teto do gas que cada entrega recebe no Ethereum (setAirdropReceiveGas, setAirdropComposeGas)
• Substituir o adaptador da bridge para envios futuros, de imediato (changeAdapter), por um adaptador que mantenha exatamente as mesmas fixações: o mesmo hub, a mesma factory, os mesmos tokens de caixa, o mesmo hub remoto e o mesmo destino. A auditoria de segurança de 2026-09-29 constatou que o hub remoto recusaria os lotes do novo adaptador (M-2); em 2026-10-05, o owner decidiu manter como está, então um adaptador é trocado fazendo o seu upgrade no lugar, no mesmo endereço
• Pausar as conversões e o bridging, imediatamente. Um hub remoto pausado continua aplicando as mudanças de papéis que cada lote leva. No contrato do airdrop, a pausa interrompe os envios, as aberturas e a alocação das ações guardadas à parte, nunca uma reivindicação
• Movimentar qualquer ativo de uma tesouraria, de um hub da bridge ou do contrato do airdrop, para qualquer endereço, de imediato e sem aviso prévio (emergencyTransfer), nas duas chains, a qualquer momento; no hub remoto, desde 2026-10-05, também imputando-o a um único mercado, cujas contas são acertadas na mesma chamada (emergencyTransferFromPending, emergencyTransferRecord)
• Depois de uma transferência dessas para fora do contrato do airdrop ou do hub remoto, dar baixa da perda no ciclo ou no mercado que a sofreu (writeDownCycle, writeDownUnassigned, writeOffPending, writeOffRecord, desde 2026-10-05). Um ciclo só pode sofrer uma baixa parcial enquanto ninguém tiver reivindicado dele a ação, com todo holder perdendo então a mesma proporção; depois que alguns holders tiverem sido pagos, só pode sofrer uma baixa de todo o seu restante, que os holders ainda não pagos perdem, e o que chega ao ciclo depois disso volta a ser dividido pro rata entre todos os seus holders. Nenhum outro mercado paga por ela; até que se dê baixa da perda ou que os ativos voltem via restore, que qualquer pessoa pode chamar, os pagamentos do que falta esperam, e os outros continuam: uma reivindicação paga as outras ações. Os dois contratos contabilizam o que lastreia as suas contas, nunca o seu saldo: ativos a caminho de outro mercado nunca pagam pela perda, e uma transferência simples para eles não lastreia nada
• Retirar o que um módulo detém por engano (rescue, desde 2026-10-05): ETH ou tokens enviados a um módulo que não guarda nada de ninguém; o que está extraviado no hook, nunca o que ele deve; o que o lock detém além das partes de taxas que ele guarda, nunca as suas posições; o ETH do BuybackBurner só quando nenhum burn puder mais gastá-lo; o que foi enviado ao próprio endereço de um token. Veja Modo de emergência
• Mudar a configuração da LayerZero dos adaptadores de ações do airdrop, sem aviso prévio e sem teto de saques

O upgrade é o mais amplo desses poderes: ele alcança de uma só vez todas as regras da segunda lista acima. Com os parâmetros, o modo de encerramento, a transferência de emergência e a configuração dos adaptadores de ações, ele significa que o StockFun não é trustless e não afirma ser. A tesouraria é guardada pelo protocolo, com um caminho de recuperação controlado pelo owner.

Os parâmetros

Desde 2026-10-05, os números do protocolo são parâmetros onchain do owner do StockFun, nas duas chains. Cada um entra em vigor na transação que o define, sem aviso prévio, emite um evento e recusa valores impossíveis: uma taxa acima de 100 %, uma divisão maior do que a taxa, um formato de lançamento que um pool não consegue comportar. Os valores abaixo são os padrões, os que este livro dá.

• Todos os pools, a partir do próximo swap. Uma mudança da taxa ou do anti-snipe vale a partir do próximo swap em todos os pools, inclusive num pool ainda dentro dos seus blocos anti-snipe: o decaimento é calculado com os parâmetros em vigor, a partir do bloco de lançamento do pool. O anti-snipe nunca cobra menos do que a taxa. O teto da whitelist vale na criação de um mercado
• Só os novos mercados, para o seu formato. Um novo supply, novas faixas, um novo tick spacing ou uma nova taxa de LP valem para os mercados criados depois. Cada pool mantém a taxa de LP e o tick spacing que recebeu na criação, e a Lens os informa, mercado a mercado; o pool do $STOCKFUN recebe os que estiverem em vigor quando for lançado
• Ao vivo, para os vaults. Todo vault lê o limiar de conversão e os seus limites de preço a cada conversão, e o lock lê as partes das taxas de LP a cada coleta
• Os ciclos abertos mantêm a sua janela. Um novo cronograma do airdrop vale para as janelas ainda não abertas, e as recorta, inclusive aquelas que as ações guardadas à parte ainda vão examinar

O que continua fixo:

• O aviso prévio de 30 dias do modo de encerramento, END_DELAY, uma constante do lock de liquidez, que não é upgradável
• O caráter imediato da transferência de emergência: ela não tem prazo, e nenhum parâmetro pode acrescentar um
• Unidades e codificações: o ponto-base, a hora como unidade do registro de posições e das janelas do airdrop, o endereço de burn, os formatos de mensagem
• A conexão: os feeds de preço, os pools em que o router de ações compra, no Ethereum, o OFT do USDG, os endpoints LayerZero da bridge, o hub remoto, o pool da Curve. Eles são fixados na implantação ou gravados uma única vez; mudar um deles significa apontar para outro contrato, o que exige um upgrade

Upgrades

Desde 2026-10-02, todo módulo é um proxy que recebe upgrade via UUPS, exceto os contratos abaixo. Como isso é construído: veja Arquitetura.

• Imediato. Um upgrade entra em vigor na transação que o realiza: sem timelock, sem aviso prévio, como os parâmetros e a transferência de emergência
• Verificado. Só o owner do protocolo pode fazer upgrade. Uma nova implementação precisa responder à mesma autoridade de upgrade, e as do hook e do registrador de posições precisam manter o mesmo PoolManager
• Mercado a mercado. Cada vault é o seu próprio proxy. Uma nova implementação de vault designada na factory vale para os mercados criados depois; os vaults existentes recebem upgrade um a um
• Storage acrescentado, nunca reordenado. O layout de storage de cada módulo é registrado, e um script o verifica antes de cada upgrade, em cada nível de cada struct desde 2026-10-05

Estes não são upgradáveis:

• Os tokens, tokens de mercado e $STOCKFUN: ERC-20 simples cujo supply é cunhado uma única vez, sem mint, burn, pausa nem blacklist. O seu único setter, setRecorder, e os seus rescues pertencem ao owner do protocolo
• O lock de liquidez, cujo código é o que mantém a liquidez nos pools. A sua única saída para a liquidez é o modo de encerramento; os seus rescues não alcançam nem as posições nem as partes que ele guarda
• O deployer dos vaults espelho, na Robinhood Chain: o endereço de cada vault espelho é derivado do seu

Os dois deployers no Ethereum, que não guardam nenhum estado, são substituídos pela factory em vez de receberem upgrade.

O modo de encerramento

A única saída do lock de liquidez, adicionada em 2026-10-02 para o caso de o projeto encerrar as suas atividades. O owner do StockFun chama end(). A partir daí, nenhum novo mercado pode ser lançado, enquanto todo pool continua em negociação. Trinta dias depois, o owner pode recuperar toda a liquidez de cada pool, para qualquer endereço. O owner pode cancelar a qualquer momento enquanto o encerramento estiver pendente; os pools já recuperados continuam vazios. Os 30 dias são o aviso prévio dos holders. Detalhes em O lançamento em duas posições.

Dependências externas

Nenhuma dessas dependências está escondida, e nenhuma pode tirar um ativo de um vault para um endereço.

Riscos aceitos

• Um upgrade, uma mudança de parâmetro e uma transferência de emergência têm efeito imediato: os holders não recebem nenhum aviso prévio deles, ao contrário do modo de encerramento, anunciado com 30 dias de antecedência
• Toda transferência de token depende do registrador de posições: uma notificação que falha faz a transferência falhar. É a única exceção deliberada à regra de que uma falha nunca bloqueia o resto: uma notificação que pudesse falhar deixaria um holder pular o registro e aumentar a sua parte do airdrop. As suas alavancas são imediatas: setRecorder(0) no token, ou um upgrade do registrador no lugar
• Uma parte cujo destinatário a recusa espera por esse destinatário, no hook, no lock, no hub remoto ou no contrato do airdrop, em vez de parar o resto; e uma transferência de emergência não imputada a nenhum mercado faz os pagamentos desse ativo esperarem até que ela seja acertada
• Nenhuma tesouraria acumula: tudo é distribuído, e um airdrop pode ser zero se ninguém negociar
• O airdrop é pago em ações wrapped no Ethereum: elas só valem o que valerem as ações travadas na Robinhood Chain e a configuração da LayerZero, e um congelamento dos Stock Tokens pelo seu emissor bloquearia as ações travadas
• Um mercado pode nunca esgotar a sua primeira faixa de liquidez
• Uma ida e volta custa 9,75 % antes de qualquer movimento de preço, com a taxa padrão de 5 %
• O trilho cross-chain não tinha sido exercitado em condições reais quando este livro foi escrito