O airdrop

Desde 2026-09-27, a tesouraria de um mercado tem um único uso: 100 % das ações tokenizadas que ela compra são distribuídas via airdrop aos holders do seu token, pro rata à posição de cada um, a cada 24 horas. O buyback do criador, que vinha antes, foi removido.

O que é distribuído

Tudo o que a tesouraria compra: os 2 % de cada trade, compras e vendas, mais o excedente do anti-snipe dos dez primeiros blocos do mercado, depois de convertido nas ações do basket do mercado.

A distribuição é in natura: os holders recebem as ações tokenizadas, em forma wrapped no Ethereum (veja abaixo), nunca dinheiro. ETH, USDC ou USDG ainda à espera de conversão não é distribuído como tal; é distribuído depois de convertido em ações.

Para quem, e onde

Aos holders do token do mercado, pro rata à posição de cada um. Os endereços do próprio protocolo não recebem nada.

As posições são contadas como o saldo médio de cada carteira nas 24 horas anteriores ao ciclo, inclusive às segundas-feiras: deter o token por uma hora conta como 1/24 de um dia inteiro. Quem compra logo antes do fechamento da janela recebe quase nada. Desde 2026-09-28, as posições de cada carteira são registradas onchain ao longo do tempo, então um contrato calcula cada parte no Ethereum; o keeper nunca as fornece. Desde 2026-10-02, o registro é mantido fora dos tokens, por um módulo, o registrador de posições: todo token lhe notifica cada mudança de saldo, e se a notificação falhar, a transferência falha. Isso é deliberado, a única exceção à regra do protocolo de que uma falha nunca bloqueia o resto: uma notificação que pudesse falhar deixaria um holder privá-la de gas na sua própria transferência, para que o registro pulasse o movimento e a sua parte crescesse. Veja Arquitetura e a regra de operação abaixo.

Desde 2026-10-01, o registro também guarda o supply registrado de cada token ao longo do tempo: todos os saldos fora do PoolManager do Uniswap. É ele que dá à parte o seu denominador:

parte = saldo médio na janela
        ÷ (supply registrado médio − médias dos endereços excluídos)

Os endereços excluídos são os que não recebem nada: o endereço de burn, sempre, e os endereços da lista de exclusão do token; veja as exclusões abaixo. O registrador só fornece o supply registrado em horas cheias, então as janelas do airdrop começam e terminam numa hora cheia. Isso custa a cada swap uma escrita de storage a mais. O primeiro swap de cada hora de um token, compra ou venda, custa cerca de 28.000 a 30.000 de gas a mais, medido como transação à parte em 2026-10-01, antes de o registro sair dos tokens; os 23.000 que esta página indicava até o pipeline de segurança de 2026-10-01 foram medidos dentro de uma única transação. Uma estimativa de gas feita por uma carteira no fim de uma hora pode, portanto, ser insuficiente, se a transação acabar sendo o primeiro swap da hora seguinte. Desde a atualização Glamsterdam do Ethereum (ativa na Sepolia desde 2026-10-06, na mainnet quando ocorrer o seu fork), essa escrita cria o seu slot de storage ao novo preço: na Sepolia, o primeiro swap de uma hora custou 123.216 de gas a mais. O app dá 150.000 de gas a mais a um trade que pode acabar sendo o primeiro swap de uma hora: só um limite mais alto, já que uma transação paga o gas que usa.

As posições são medidas no Ethereum, onde o token é negociado, e desde 2026-09-28 as ações também são distribuídas lá. Elas são compradas na Robinhood Chain, travadas lá em adaptadores LayerZero implantados pelo StockFun, um por ação, e enviadas para o Ethereum como ações wrapped, uma ação wrapped para cada ação travada. Cada holder reivindica a sua parte no Ethereum e paga o gas da reivindicação. Para deter a ação real, um holder envia a ação wrapped de volta pela bridge para a Robinhood Chain, às suas custas. A configuração da LayerZero dos adaptadores fica nas mãos do owner do StockFun, sem prazo e sem teto de saques: veja Modelo de confiança.

A regra vale para toda tesouraria, inclusive a do $STOCKFUN, que é distribuída via airdrop aos holders de $STOCKFUN.

A cada 24 horas

O airdrop funciona como um ciclo diário, mercado a mercado. O seu horário, 13:00 UTC por padrão, fecha a janela em que as posições são medidas, antes da abertura da bolsa americana, o ano inteiro: a abertura é às 13:30 UTC no verão americano e às 14:30 UTC no inverno americano. As compras do ciclo acontecem então durante o pregão seguinte, e os seus envios, por padrão, depois que esse pregão termina:

1. Se a tesouraria do mercado tiver acumulado pelo menos 0,1 ETH, o keeper converte esse ETH, o envia pela bridge e compra as ações do basket.
2. Depois que o pregão do dia termina, por padrão, o keeper envia as ações compradas ao contrato do airdrop no Ethereum, wrapped, onde 100 % delas passam a poder ser reivindicadas pelos holders do token. Desde o sétimo loop de auditoria, em 2026-10-06, ele as envia quando elas valem o que custa enviá-las, incluída a abertura da janela; caso contrário, elas esperam no vault por uma janela posterior, com o que se acumular (veja O keeper). Desde o décimo loop de auditoria, o keeper só volta a ler um vault que não tinha nada a enviar depois do fechamento no pregão seguinte, então uma ação dada a um vault depois do fechamento, fora das suas compras, segue com o envio do pregão seguinte, para uma janela posterior; o que as compras do dia trazem continua indo para a janela que terminou naquele dia.

Abaixo de 0,1 ETH, nada acontece para esse mercado naquele dia: o ETH espera o próximo ciclo. Com 2 %, atingir o limiar exige cerca de 5 ETH de volume no mercado, somando compras e vendas. Ultrapassá-lo durante o dia não dispara nada: a conversão só acontece no ciclo diário. O keeper verifica cada vault na sua primeira passagem depois que a janela fecha e converte o seu ETH uma única vez nessa janela; ele segue essa regra desde 2026-10-06, e até então convertia o ETH de um vault em qualquer uma das suas passagens durante o pregão, assim que o vault detinha o limiar. O caixa que já espera num vault segue adiante, atingido ou não o limiar: desde o sexto loop de auditoria, em 2026-10-06, o USDC de um vault uma vez depois de cada uma das suas conversões de ETH e no máximo uma vez por janela nos outros casos, e o USDG de um vault espelho a cada passagem.

As ações só podem ser compradas enquanto a bolsa americana está aberta. Por isso, não há ciclo nos fins de semana nem nos feriados da NYSE: as taxas de sexta-feira são distribuídas na segunda-feira.

O limiar e o calendário são regras do keeper: o contrato do airdrop não conhece nenhum dos dois. Ele conhece as janelas, e credita cada envio à última janela fechada no momento em que ele chega.

A duração e o horário de fechamento do ciclo, o limiar, 0,1 ETH, e os limites do contrato do airdrop abaixo são parâmetros do owner do StockFun desde 2026-10-05; os valores desta página são os padrões. Um novo cronograma vale para as janelas ainda não abertas: um ciclo já aberto mantém a sua janela.

Um ciclo que falha no caminho — uma bridge atrasada, um feed desatualizado, uma recusa do limite — só interrompe o que a falha atinge. Desde 2026-10-05, a compra de cada ação vai isoladamente: uma ação cuja perna falha guarda o seu caixa para um ciclo posterior enquanto as outras ações do basket são compradas, e um mercado deixado fora de um lote da bridge espera enquanto os outros atravessam. O que não seguiu adiante espera nos vaults do mercado, no Ethereum ou na Robinhood Chain, e é levado até o fim no próximo ciclo, mesmo que a tesouraria não tenha voltado a atingir 0,1 ETH. O owner do StockFun também pode movimentá-lo, a qualquer momento, com a transferência de emergência, que é imediata: veja Modo de emergência.

Como funciona um ciclo

No contrato do airdrop, desde 2026-10-04:

• A janela. A janela de um ciclo é o período anterior ao seu fim: 24 horas que terminam às 13:00 UTC por padrão. O owner do StockFun define a duração e o horário de fechamento, em horas inteiras (setCycleSchedule). Um envio pertence à janela que termina no último horário de fechamento igual ou anterior à sua chegada, nunca a uma janela anterior ao ciclo aberto mais recente do mercado.
• A abertura congela os números. O primeiro envio de uma janela abre o seu ciclo. O keeper pode abri-lo antes, com openCycle, que qualquer pessoa pode chamar: ele faz isso depois que a janela fecha, antes de as ações chegarem, de modo que cada entrega só acrescenta ao ciclo. A abertura congela, de vez: o registrador de posições do token, a lista de exclusão em vigor quando a janela fechou, seja quando for que o ciclo se abra, e o denominador, o supply registrado na janela menos as posições do endereço de burn e dos endereços listados. Todo holder de um ciclo é medido contra os mesmos números, mude o que mudar depois.
• Um ciclo por janela. Os envios seguintes na mesma janela se somam ao mesmo ciclo.
• O keeper decide quando. Ele aciona os envios; nunca indica uma janela, um holder ou um valor. Um envio que chega depois do horário de fechamento seguinte é, portanto, medido na janela do dia seguinte. Isso é aceito e documentado.

Como as ações chegam lá

Dois caminhos, e nada mais credita um ciclo.

• A partir da Robinhood Chain. O keeper chama o vault espelho do mercado, sendToAirdrop(stocks), e paga as taxas da LayerZero; o que ele paga a mais lhe é devolvido. Desde 2026-10-06, a chamada também indica o gas que cada entrega recebe no Ethereum, sendToAirdrop(stocks, receiveGas, composeGas), que o hub remoto mantém entre um piso e um teto definidos pelo owner do StockFun (veja O trilho Robinhood e O keeper). Para cada ação listada, o vault envia o seu saldo inteiro pelo adaptador que o hub remoto designa para essa ação, para o contrato do airdrop que o hub remoto designa, com o id do mercado como payload. A LayerZero transporta seis casas decimais: menos de 10^12 unidades de uma ação de 18 decimais, um milionésimo de token, fica no vault para um envio posterior. No Ethereum, o OFT da ação cunha a ação wrapped para o contrato do airdrop, e então o endpoint da LayerZero o chama. O contrato só credita a entrega se ela vier do seu endpoint, de um OFT de ação que o owner do StockFun registrou, da Robinhood Chain, enviada pelo vault espelho do mercado que o payload indica, e se esse mercado existir.
• A partir do Ethereum. Num vault que compra as suas ações no Ethereum, o trilho local, o keeper chama sendToAirdrop(stocks) no TreasuryVault do mercado. O vault aprova os valores exatos, o contrato do airdrop os puxa e credita o que realmente recebeu, e as aprovações são fechadas de novo. Só o próprio vault do mercado pode enviar por ele. Um vault ligado ao hub da bridge recusa esse caminho: as suas ações estão na Robinhood Chain.

Nos dois casos, o keeper decide quando, nunca quanto, o quê ou para onde: o valor é o saldo do vault, o destino é o contrato que o protocolo designa, e uma ação listada duas vezes ou fora do basket faz a chamada falhar.

Desde 2026-10-05, cada ação listada vai isoladamente. Uma ação que o seu emissor congelou, cujo saldo não pode ser lido ou, a partir da Robinhood Chain, que não tem adaptador ou cuja taxa o pagamento do keeper não cobre fica no vault, com um evento (AirdropSendFailed), e as outras vão; ela irá num envio posterior. Quando nenhuma ação vai, a chamada falha e diz por quê.

Partes e reivindicações

• O holder reivindica. Cada holder reivindica a sua própria parte, no Ethereum, e paga o gas: um ciclo com claim, vários com claimMany. Ninguém pode reivindicar por outra pessoa, e o keeper não envia nada. Desde 2026-10-05, a tela de reivindicação do dapp lista todas as janelas que a carteira pode reivindicar e envia as reivindicações, cinco ciclos por transação (dez até 2026-10-06): veja O dapp.

• O valor. Para cada ação de um ciclo:

  devido = piso(valor × posição na janela ÷ posições elegíveis)
           − o que já foi pago ao holder
  

  nunca mais do que o ciclo ainda tem nessa ação. Um envio depois de uma reivindicação aumenta o valor, e o holder reivindica a diferença. O que o arredondamento deixa fica no contrato.

• Sem prazo de validade, sem teto, sem mínimo. Uma parte pode ser reivindicada a qualquer momento, sem data-limite. Não há teto por carteira nem valor mínimo.
• Endereços excluídos não reivindicam nada.
• Nunca pago por outro ciclo. Desde 2026-10-05, 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. O que o lastreia é contado a partir das ações creditadas aos ciclos, nunca lido no saldo do contrato, que também inclui entregas ainda não creditadas: ações a caminho de outro mercado nunca pagam uma reivindicação. Depois de uma transferência de emergê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, que qualquer pessoa pode chamar (uma transferência simples não conta), ou que o owner do StockFun dê baixa da perda no ciclo que a sofreu. Enquanto ninguém tiver reivindicado essa ação do ciclo, é possível dar baixa de qualquer parte dela, com todo holder perdendo a mesma proporção; depois que alguns holders tiverem sido pagos, só é possível dar baixa de todo o restante, que os holders ainda não pagos perdem. O que chega ao ciclo depois de uma baixa dessas é dividido pro rata entre todos os seus holders, como se o valor baixado nunca tivesse estado lá. Veja Modo de emergência.
• Uma reivindicação paga o que pode. Desde 2026-10-05, claim e claimMany pagam todas as ações que podem. Uma ação para a qual as contas ficam aquém, como acima, ou cuja transferência é recusada, por exemplo porque o seu emissor a congelou, é adiada (ClaimDeferred): ela continua devida, e uma reivindicação posterior a paga. claimMany pula um ciclo cuja lista de exclusão contém quem chama; claim o recusa (Excluded). Uma reivindicação que não paga nada falha e diz por quê: contas aquém para uma ação (Underfunded), uma transferência recusada (TransferRefused) ou nada a reivindicar (NothingToClaim). Até então, uma única ação assim fazia a reivindicação inteira falhar, e um ciclo excluído, o claimMany inteiro.
• O custo. Reivindicar um ciclo de duas ou três ações custa aproximadamente 120.000 a 210.000 de gas, conforme medido nos testes, que rodam com storage quente. Medido a frio em 2026-10-05, com cinco ações por ciclo, um primeiro ciclo custa cerca de 508.000 a 528.000 de gas como transação inteira, e cada ciclo adicional do mesmo claimMany, cerca de 321.000 a 332.000: cerca de 3,4 a 3,5 milhões de gas para dez ciclos, à época o tamanho dos lotes da tela de reivindicação, e até cerca de 5,3 milhões quando as ações de cada ciclo também estão frias. Esses são os preços de gas anteriores à atualização Glamsterdam do Ethereum. Com ela, ativa na Sepolia desde 2026-10-06, um novo slot de storage custa cerca de cinco vezes mais, e cada ação que uma reivindicação paga pode gravar três: na Sepolia, uma reivindicação de um ciclo de três ações custou 1.177.679 de gas para o primeiro a reivindicar no ciclo e 878.713 a 888.051 para os seguintes. Dez ciclos de cinco ações levariam cerca de 8 a 14 milhões de gas, dentro dos 16.777.216 que o EIP-7825 fixa por transação (sob a Glamsterdam, sobre o seu gas de execução), e os lotes da tela de reivindicação são de cinco ciclos.

claimable informa o que um endereço pode reivindicar de um ciclo, ação por ação.

Exclusões

Cada token tem a sua própria lista, definida pelo owner do StockFun: no máximo 16 endereços por padrão (setMaxExcluded), nenhum repetido, nenhum zero. O endereço de burn, 0x…dEaD, é sempre excluído e fica fora da lista. Cada mudança cria uma nova versão da lista, datada: uma janela é medida contra a lista em vigor quando ela fechou, seja quando for que o seu ciclo se abra, e uma mudança vale para as janelas que fecham depois.

Por padrão, só o endereço de burn é excluído no token de um mercado. O PoolManager do Uniswap nunca é registrado, então não precisa de entrada. O único provedor de liquidez dos pools do StockFun é o lock de liquidez, que não detém nada fora de um lançamento. Um pool em outra exchange que detivesse o token seria um holder registrado comum, que o owner pode listar.

No $STOCKFUN, a lista traz também o operador do lançamento, que detém todo o supply durante os poucos blocos entre a cunhagem e o lock. Desde 2026-10-05, o script de lançamento lista esse endereço antes de o token existir, no endereço que o token vai ocupar, e só então faz a cunhagem, de modo que nenhuma janela pode fechar entre a cunhagem e a lista: o operador não recebe nada. Se o owner mudar essa lista antes que a primeira janela depois do lançamento tenha fechado, a nova lista deve manter esse endereço.

Ações guardadas à parte

Um envio para uma janela sem posições elegíveis é guardado à parte para o mercado: por exemplo, ações enviadas no dia em que um mercado foi lançado, para uma janela que terminou antes de ele existir.

As ações guardadas à parte vão para a primeira janela com posições elegíveis depois da última encontrada sem elas, seja quem for que olhe e seja quando for. openCycle, ou um envio, para a janela imediatamente seguinte as leva junto. Caso contrário, assignUnassigned, que qualquer pessoa pode chamar, verifica as janelas encerradas em ordem, no máximo 30 por chamada por padrão (setMaxWindowsPerAssign), e abre a primeira com posições elegíveis, mesmo que ciclos posteriores já estejam abertos. Os ciclos podem, portanto, se abrir fora de ordem.

Isso vale enquanto, nesse meio-tempo, o cronograma do ciclo não mudar e o registrador de posições do token não for substituído. Um novo cronograma recorta as janelas ainda não abertas, inclusive aquelas que as ações guardadas à parte ainda vão examinar; um registrador substituído nesse meio-tempo não mede nenhuma janela que começou antes dele, e as ações esperam a primeira janela que ele cobre por inteiro (veja a regra de operação abaixo).

Um envio que não encontra ele mesmo nenhuma posição elegível, enquanto janelas anteriores ainda não foram verificadas, falha: primeiro assignUnassigned, depois o envio de novo. Uma entrega vinda da Robinhood Chain fica armazenada no Ethereum e pode ser executada de novo: desde 2026-10-06, o próprio keeper executa de novo uma entrega armazenada, assim que a sua simulação passa, e alerta com o comando para executá-la à mão quando não consegue (veja O keeper). Desde 2026-10-05, um envio para uma janela que termina junto com a última verificada, ou antes dela, o que uma mudança para janelas mais longas pode provocar, se junta em vez disso às ações guardadas à parte: um mercado que guarda ações à parte continua recebendo os seus envios.

Os princípios

• Um airdrop de ativos, nunca um buyback de cotas. Ninguém devolve um token ao vault. O que conta é deter o token.
• Recompensa quem detém, não quem negocia.
• Nenhum valor prometido. Um airdrop depende do volume passado, não de uma taxa. Pode ser zero, e nada promete que haverá volume amanhã.
• Nenhum resgate. Um holder recebe a sua parte de cada airdrop e nada mais: continua não havendo nenhum direito de saque sobre o vault.
• O keeper aciona, nunca escolhe. A divisão é calculada por um contrato a partir das posições que o registrador de posições mantém. O keeper escolhe quando envia, nunca quanto, o quê, para onde ou para quem, e não consegue atribuir uma parte a si mesmo nem a ninguém fora desse cálculo.
• Nunca mais do que um ciclo detém. Cada ciclo paga no máximo o que detém, ação por ação, e nenhum holder recebe mais do que a sua parte pro rata, arredondada para baixo.
• Uma falha só interrompe a si mesma. Desde 2026-10-05, uma ação que não pode ser enviada ou paga, ou um mercado que não pode atravessar, espera isoladamente, e os outros vão. Veja Arquitetura.

O modo de emergência se aplica ao contrato do airdrop como a qualquer contrato que detém ativos do protocolo: a transferência do owner, imediata, movimenta ações e deixa as partes como estão. Desde 2026-10-05, os outros ciclos nunca pagam por ela: as reivindicações de uma ação que a transferência levou adiam essa ação, e pagam as outras, até que a ação volte via restore ou que o owner dê baixa da perda no ciclo que a sofreu (veja acima e Modo de emergência). O procedimento do owner nunca deixa as contas ficarem aquém: primeiro dar baixa no ciclo (writeDownCycle, ou writeDownUnassigned para as ações guardadas à parte), depois movimentar a ação. A pausa do contrato do airdrop interrompe os envios, a abertura de ciclos e a alocação das ações guardadas à parte; ela não movimenta nada e nunca interrompe uma reivindicação. O contrato do airdrop e o registrador de posições são upgradáveis pelo owner do StockFun, com efeito imediato, como todo módulo, exceto os tokens e o lock de liquidez.

Daí decorre uma regra de operação: o registrador de posições de um token recebe upgrade no lugar, o que preserva todo o seu histórico; ele não é substituído num token em uso. Desde 2026-10-05, uma substituição não quebra mais a negociação: o novo registrador parte do supply do token fora do PoolManager do Uniswap naquele momento, um registrador que já registrou esse token o recusa e, desde o segundo loop de auditoria daquele dia, um token recusa um registrador vinculado a outro PoolManager que não aquele em que o seu pool está, o que contaria o pool como um holder. Desde o terceiro loop, o novo registrador começa um novo registro na troca: o contrato do airdrop não mede nenhuma janela que começou antes dela, cujas ações esperam, guardadas à parte, a primeira janela que o novo registrador cobre por inteiro, e o token notifica o saldo do endereço de burn no momento da troca, de modo que os tokens queimados continuam excluídos. Mas o novo registrador não conhece os saldos dos holders: um holder que ele não viu se mover é lido como não tendo detido nada até o seu próximo movimento, então uma janela que esse holder atravessa lhe paga menos, e ninguém recebe a mais. Os ciclos já abertos mantêm o registrador que congelaram. Um registrador que precise ser substituído é trocado logo depois do fim de uma janela, uma vez abertos os ciclos das janelas já fechadas. Até 2026-10-05, um registrador novo partia de um supply nulo: toda venda falhava, e as partes dos ciclos abertos depois ficavam quebradas de vez.

Como uma notificação que falha faz a transferência falhar, o owner do StockFun mantém duas alavancas imediatas, de uma transação cada: um upgrade do registrador no lugar, ou setRecorder(0) no token, que interrompe o seu registro. Enquanto um token não tem registrador, o contrato do airdrop não abre nenhum ciclo dele, e as ações enviadas para ele ficam guardadas à parte até que um registrador seja designado.

O que estava em aberto, e como foi decidido

O registro do projeto, doc/DECISIONS.md, acompanhava três pontos em aberto como TBD 5, 7 e 8. Os três foram decididos em 2026-10-04:

• Um envio pelo keeper (TBD 5). Não: só o holder reivindica, para si mesmo, às suas custas.
• Os limites (TBD 7). Nenhum teto por carteira, nenhum valor mínimo, e as partes nunca expiram.
• As exclusões (TBD 8). Uma lista por token, definida pelo owner do StockFun, no máximo 16 endereços por padrão, com o endereço de burn sempre excluído; por padrão, só o endereço de burn. Veja acima.

O que falta

• Os adaptadores de ações. Os adaptadores LayerZero que levam cada ação ao Ethereum, um por ação: o adaptador de travamento na Robinhood Chain e o seu OFT no Ethereum. Eles não estão no repositório; os testes usam mocks
• Uma implantação. Nada está implantado

A etapa do airdrop no keeper e a tela de reivindicação do dapp, listadas aqui até então, foram escritas em 2026-10-05: veja O keeper e O dapp.

E o Treasury Ratio?

O Treasury Ratio — valor da tesouraria dividido pelo market cap circulante — era a métrica emblemática do produto. Ele não significa mais nada: a tesouraria é esvaziada a cada distribuição. Está obsoleto desde 2026-09-27.

A métrica que o substitui ainda está por decidir. A proposta atual: o valor acumulado das ações distribuídas aos holders de um mercado, em dólares. Entre duas distribuições, o dapp continua mostrando o que a tesouraria detém, à espera do próximo airdrop.

E o buyback do criador?

Removido. De 2026-08-27 a 2026-09-27, o criador de um mercado podia mandar vender ações da tesouraria para recomprar e queimar o seu token. O criador agora não tem nenhum poder sobre a tesouraria: só recebe ações como qualquer holder, se detiver o token.

Com ele vai embora o caminho de volta da bridge, da Robinhood Chain para o Ethereum, que só servia ao buyback do criador. A bridge agora funciona em um único sentido. As ações fazem o caminho inverso para o airdrop, wrapped, pelos adaptadores de ações: um caminho diferente, que só transporta ações.

O buyback e burn de $STOCKFUN não é afetado: a parcela de 0,5 % de cada trade que compra $STOCKFUN e o envia para o burn não toca em nenhuma tesouraria, e permanece. Veja $STOCKFUN.

A formulação

Formulação proposta para o dapp, a validar:

As ações que a tesouraria compra são distribuídas via airdrop aos holders do token, pro rata, a cada distribuição. Isto não é nem um rendimento nem uma garantia.

O vocabulário proibido se aplica integralmente ao airdrop. O projeto nunca escreve passive income, earn stocks, returns ou your stocks are safe in the vault, e nunca apresenta um valor futuro de airdrop como certo.

Ações tokenizadas emitidas pela Robinhood, não disponíveis para US persons.