L'airdrop

Depuis le 2026-09-27, la trésorerie d'un marché n'a qu'un usage : 100 % des actions tokenisées qu'elle achète sont airdroppées aux holders de son token, au prorata de leur détention, toutes les 24 heures. Le buyback du créateur, qui la précédait, est supprimé.

Ce qui est distribué

Tout ce que la trésorerie achète : les 2 % de chaque trade, à l'achat comme à la vente, plus l'excédent de l'anti-snipe des dix premiers blocs du marché, une fois convertis en actions du basket du marché.

La distribution se fait en nature : les holders reçoivent les actions tokenisées, sous forme wrappée sur Ethereum (voir plus bas), jamais du cash. L'ETH, l'USDC ou l'USDG encore en attente de conversion n'est pas distribué tel quel ; il l'est une fois converti en actions.

À qui, et où

Aux holders du token du marché, au prorata de leur détention. Les adresses du protocole ne reçoivent rien.

La détention se compte comme le solde moyen de chaque wallet sur les 24 heures qui précèdent le cycle, le lundi compris : détenir le token une heure compte pour 1/24 d'une journée entière. Un achat juste avant la fermeture de la fenêtre ne rapporte presque rien. Depuis le 2026-09-28, la détention de chaque wallet est enregistrée onchain dans le temps : un contrat calcule chaque part sur Ethereum, et le keeper ne la fournit jamais. Depuis le 2026-10-02, cet enregistrement est tenu hors des tokens, par un module, l'enregistreur de détention : chaque token lui déclare chaque changement de solde, et si la déclaration échoue, le transfert échoue.

C'est, depuis le 2026-10-05, la seule exception voulue à la règle du protocole qui veut qu'une panne ne bloque jamais le reste. Une déclaration qui ne bloquerait pas laisserait un holder priver l'appel de gas, sur son propre transfert, pour que l'enregistrement le saute et que sa part de l'airdrop grossisse. Le levier est immédiat, une transaction de l'owner de StockFun : retirer l'enregistreur du token (setRecorder(0)), ou upgrader l'enregistreur en place. Sans enregistreur, le token n'enregistre plus rien, et le contrat de l'airdrop n'ouvre aucun cycle de ce token : ses envois sont mis de côté, plus bas.

Depuis le 2026-10-01, l'enregistrement tient aussi la supply enregistrée de chaque token dans le temps : tous les soldes hors du PoolManager d'Uniswap. Elle donne à la part son dénominateur :

part = solde moyen sur la fenêtre
       ÷ (supply enregistrée moyenne − moyennes des adresses exclues)

Les adresses exclues sont celles qui ne reçoivent rien : l'adresse de burn, toujours, et les adresses de la liste d'exclusion du token ; voir les exclusions plus bas. L'enregistreur ne donne la supply enregistrée qu'aux heures pleines : les fenêtres de l'airdrop commencent et finissent donc sur une heure pleine. Cela coûte à chaque swap une écriture de plus en stockage. Le premier swap de chaque heure sur un token, achat ou vente, coûte environ 28 000 à 30 000 gas de plus, mesuré comme transaction à part le 2026-10-01, avant que l'enregistrement quitte les tokens ; les 23 000 qu'indiquait cette page jusqu'au pipeline de sécurité du 2026-10-01 étaient mesurés à l'intérieur d'une seule transaction. Une estimation de gas faite par un wallet tard dans une heure peut donc être trop courte, si la transaction arrive comme premier swap de l'heure suivante. Depuis la mise à niveau Glamsterdam d'Ethereum (active sur Sepolia depuis le 2026-10-06, sur le mainnet à sa date), cette écriture crée son slot de stockage au nouveau prix : sur Sepolia, le premier swap d'une heure a coûté 123 216 gas de plus. L'app donne 150 000 gas de plus à un trade qui peut arriver comme premier swap d'une heure : une limite plus haute seulement, puisqu'une transaction paie le gas qu'elle utilise.

La détention se mesure sur Ethereum, où le token se trade, et depuis le 2026-09-28 les actions y sont distribuées aussi. Elles sont achetées sur Robinhood Chain, verrouillées là-bas dans des adaptateurs LayerZero déployés par StockFun, un par action, et envoyées sur Ethereum sous forme d'actions wrappées, une action wrappée pour chaque action verrouillée. Chaque holder réclame sa part sur Ethereum et paie le gas de sa réclamation. Pour détenir la vraie action, un holder renvoie l'action wrappée par le pont vers Robinhood Chain, à ses frais. L'owner de StockFun tient la configuration LayerZero des adaptateurs, sans délai et sans plafond de sortie : voir Modèle de confiance.

La règle vaut pour toute trésorerie, y compris celle de $STOCKFUN, airdroppée aux holders de $STOCKFUN.

Toutes les 24 heures

L'airdrop tourne en cycle quotidien, marché par marché. Son heure, 13:00 UTC par défaut, ferme la fenêtre sur laquelle se mesure la détention, avant l'ouverture de la bourse US, toute l'année : l'ouverture est à 13:30 UTC l'été et à 14:30 UTC l'hiver. Les achats et les envois du cycle se font ensuite, pendant la séance qui suit et juste après :

1. Pendant la séance, si la trésorerie du marché détient au moins 0,1 ETH au premier passage du keeper après la fermeture de la fenêtre, le keeper la convertit, la fait passer par le pont et achète les actions du basket. Il passe toutes les cinq minutes par défaut, mais ne convertit l'ETH d'un vault qu'une fois par fenêtre : il s'y tient depuis le 2026-10-06, et convertissait jusque-là dès que la trésorerie atteignait le seuil, à n'importe lequel de ses passages.
2. Une fois la séance du jour terminée, le keeper envoie les actions achetées au contrat de l'airdrop sur Ethereum, wrappées, une fois par fenêtre, où 100 % d'entre elles deviennent réclamables par les holders du token. Depuis la septième boucle d'audit, le 2026-10-06, il ne les envoie qu'une fois qu'elles valent ce que leur envoi coûte, ouverture du cycle comprise ; sinon elles attendent au vault une fenêtre suivante, avec ce qui s'accumule (voir Le keeper). Depuis la dixième boucle d'audit, le keeper ne relit un vault qui n'avait rien à envoyer après la clôture qu'à la séance suivante : une action donnée à un vault après la clôture, hors de ses achats, part donc avec l'envoi de la séance suivante, dans une fenêtre plus tardive ; ce qu'apportent les achats du jour part toujours dans la fenêtre fermée ce jour-là.

En dessous de 0,1 ETH à ce passage, rien ne se passe pour ce marché ce jour-là : l'ETH attend la fenêtre suivante dans le vault, même si des trades lui font franchir le seuil plus tard dans la journée. À 2 %, atteindre le seuil demande environ 5 ETH de volume sur le marché, achats et ventes confondus. Le seuil ne vaut que pour l'ETH : l'USDC, l'USDG ou les actions qui attendent déjà dans un vault passent à l'étape suivante, seuil atteint ou non.

Les actions ne s'achètent que bourse US ouverte. Il n'y a donc pas de cycle le week-end ni les jours fériés NYSE : les frais du vendredi sont distribués le lundi.

Le contrat de l'airdrop ne connaît ni le seuil ni le calendrier de la bourse : le seuil est un réglage de la factory, que chaque vault vérifie, et le calendrier une règle du keeper. Le contrat connaît les fenêtres, et crédite chaque envoi à la dernière fenêtre fermée à son arrivée.

La durée du cycle et son heure de fermeture, le seuil, 0,1 ETH, et les limites du contrat de l'airdrop plus bas sont des réglages de l'owner de StockFun depuis le 2026-10-05 ; les valeurs de cette page sont celles par défaut. Un nouveau calendrier vaut pour les fenêtres pas encore ouvertes : un cycle déjà ouvert garde sa fenêtre.

Un cycle qui échoue en route — pont en retard, feed périmé, borne refusée — n'arrête que ce que l'échec touche. Depuis le 2026-10-05, l'achat de chaque action part seul : une action dont la jambe échoue garde son cash pour un cycle suivant pendant que les autres actions du basket sont achetées, et un marché laissé hors d'un batch de pont attend pendant que les autres traversent. Ce qui n'est pas parti attend dans les vaults du marché, sur Ethereum ou sur Robinhood Chain, et est terminé au cycle suivant, même si la trésorerie n'a pas de nouveau atteint 0,1 ETH. L'owner de StockFun peut aussi le déplacer, à tout moment, par le transfert d'urgence, qui est immédiat : voir Le mode urgence.

Depuis le 2026-10-05, ce qui échoue n'arrête que ce qu'il touche. Une jambe d'achat qui échoue garde le cash de son action, et les autres jambes passent ; une action qui ne peut pas partir à l'airdrop reste au vault, et les autres partent ; un marché qui ne peut pas passer le pont attend le batch suivant, et les autres passent.

Comment se déroule un cycle

Dans le contrat de l'airdrop, depuis le 2026-10-04 :

• La fenêtre. La fenêtre d'un cycle, c'est la période qui précède sa fin : 24 heures qui finissent à 13:00 UTC par défaut. L'owner de StockFun fixe la durée et l'heure de fermeture, en heures pleines (setCycleSchedule). Un envoi appartient à la fenêtre qui finit à la dernière heure de fermeture à ou avant son arrivée, jamais à une fenêtre antérieure au dernier cycle ouvert du marché.
• L'ouverture fige les chiffres. Le premier envoi d'une fenêtre ouvre son cycle. Le keeper peut l'ouvrir avant, avec openCycle, que n'importe qui peut appeler : il le fait une fois la fenêtre fermée, avant l'arrivée des actions, si bien que chaque livraison ne fait qu'ajouter au cycle. L'ouverture fige, pour de bon : l'enregistreur de détention du token, la liste d'exclusion en vigueur à la fermeture de la fenêtre, quel que soit le moment où le cycle s'ouvre, et le dénominateur, la supply enregistrée sur la fenêtre moins la détention de l'adresse de burn et des adresses listées. Chaque holder d'un cycle est mesuré contre les mêmes chiffres, quoi qu'il change ensuite.
• Un cycle par fenêtre. Les envois suivants de la même fenêtre s'ajoutent au même cycle.
• Le keeper décide du moment. Il déclenche les envois ; il ne désigne jamais une fenêtre, un holder ni un montant. Un envoi arrivé après l'heure de fermeture suivante est donc mesuré sur la fenêtre du lendemain. C'est assumé et documenté.

Comment les actions y arrivent

Deux chemins, et rien d'autre ne crédite un cycle.

• Depuis Robinhood Chain. Le keeper appelle le vault miroir du marché, sendToAirdrop(stocks), et paie les frais LayerZero ; ce qu'il paie en trop lui est rendu. Depuis le 2026-10-06, l'appel nomme aussi le gas que chaque livraison reçoit sur Ethereum, sendToAirdrop(stocks, receiveGas, composeGas), que le hub distant tient entre un plancher et un plafond fixés par l'owner de StockFun (voir Le rail Robinhood et Le keeper). Pour chaque action listée, le vault envoie tout son solde par l'adaptateur que le hub distant désigne pour cette action, vers le contrat de l'airdrop que le hub distant désigne, avec l'identifiant du marché en charge utile. LayerZero transporte six décimales : moins de 10^12 unités d'une action à 18 décimales, un millionième de token, restent au vault pour un envoi suivant. Sur Ethereum, l'OFT de l'action frappe l'action wrappée au contrat de l'airdrop, puis l'endpoint de LayerZero l'appelle. Le contrat ne crédite la livraison que si elle vient de son endpoint, d'un OFT d'action que l'owner de StockFun a enregistré, de Robinhood Chain, envoyée par le vault miroir du marché que désigne la charge utile, et si ce marché existe.
• Depuis Ethereum. Sur un vault qui achète ses actions sur Ethereum, le rail local, le keeper appelle sendToAirdrop(stocks) sur le TreasuryVault du marché. Le vault approuve les montants exacts, le contrat de l'airdrop les tire et crédite ce qu'il a réellement reçu, puis les approbations sont refermées. Seul le vault du marché peut envoyer pour lui. Un vault câblé au hub de pont refuse ce chemin : ses actions sont sur Robinhood Chain.

Dans les deux cas, le keeper décide du moment, jamais du montant, de l'actif ni de la destination : le montant est le solde du vault, la destination est le contrat que désigne le protocole, et une action listée deux fois ou hors du basket fait échouer l'appel.

Depuis le 2026-10-05, chaque action part à part. Une action dont le solde ne se lit pas, gelée par son émetteur par exemple (BalanceUnreadable), une action sans adaptateur, ou dont l'envoi échoue — un émetteur qui refuse, un pair LayerZero manquant, des frais que l'envoi n'apporte pas — reste au vault, avec l'événement AirdropSendFailed, et les autres partent ; elle partira avec un envoi suivant. Si rien ne part, l'appel échoue et dit pourquoi. Le devis des frais du vault miroir, quoteSendToAirdrop, saute ce qu'il ne sait pas chiffrer — une action sans adaptateur, dont le solde ne se lit pas, ou dont l'adaptateur ne répond pas — au lieu d'échouer.

Parts et réclamations

• Le holder réclame. Chaque holder réclame lui-même sa part, sur Ethereum, et paie le gas : un cycle avec claim, plusieurs avec claimMany. Personne ne peut réclamer pour quelqu'un d'autre, et le keeper n'envoie rien. L'écran de réclamation de l'app, écrit le 2026-10-05, liste les fenêtres que le wallet peut réclamer et les envoie par lots de cinq cycles (dix jusqu'au 2026-10-06) : voir La dapp.
• Une réclamation paie ce qu'elle peut. Depuis le 2026-10-05, claim et claimMany paient chaque action qu'ils peuvent. Une action dont les comptes sont à court après un transfert d'urgence, ou dont le transfert est refusé, un gel de son émetteur par exemple, est différée : événement ClaimDeferred, elle reste due et se paie par une réclamation suivante, et les autres actions sont payées. claimMany saute un cycle dont la liste d'exclusion nomme l'appelant ; claim le refuse (Excluded). Une réclamation qui ne paie rien échoue et dit pourquoi : Underfunded, les comptes à court ; TransferRefused, le transfert refusé ; ou NothingToClaim.

• Le montant. Pour chaque action d'un cycle :

  dû = plancher(montant × détention sur la fenêtre ÷ détention éligible)
       − ce qui a déjà été payé au holder
  

  jamais plus que ce qu'il reste au cycle dans cette action. Un envoi arrivé après une réclamation augmente le montant, et le holder réclame la différence. Ce que l'arrondi laisse reste dans le contrat.

• Ni échéance, ni plafond, ni minimum. Une part se réclame à tout moment, sans date limite. Il n'y a aucun plafond par wallet et aucun montant minimum.
• Les adresses exclues ne réclament rien.
• Jamais payée par un autre cycle. Depuis le 2026-10-05, le contrat de l'airdrop tient, action par action, ce qu'il doit et ce qui le couvre, et ne paie une réclamation que si ce qui le couvre suffit à ce qu'il doit. Ce qui le couvre se compte sur les actions créditées aux cycles, jamais sur le solde du contrat, qui contient aussi des livraisons pas encore créditées : des actions en route vers un autre marché ne paient jamais une réclamation. Après un transfert d'urgence qui a pris une partie d'une action, les réclamations de cette action sont différées, dans tous les marchés qui la détiennent, jusqu'au retour de l'action par restore, que n'importe qui peut appeler (un transfert simple ne compte pas), ou jusqu'à ce que l'owner de StockFun passe la perte sur le cycle qui l'a subie. Tant que personne n'a réclamé cette action dans le cycle, la perte peut en prendre n'importe quelle part, chaque holder perdant la même part ; une fois des holders payés, elle ne peut plus en prendre que tout le reste, que perdent les holders pas encore payés. Ce qui arrive au cycle après une telle passation en perte se partage au prorata entre tous ses holders, comme si le montant passé en perte n'y avait jamais été. Les autres actions du cycle sont payées pendant ce temps. Voir Le mode urgence.
• Le coût. Réclamer un cycle de deux ou trois actions coûte environ 120 000 à 210 000 gas dans les tests, qui tournent sur un stockage chaud. Mesuré à froid le 2026-10-05, chaque slot froid, sur des cycles de cinq actions, transaction entière : environ 508 000 gas pour le premier cycle d'un holder tranquille et 528 000 pour celui d'un trader actif, puis environ 321 000 à 332 000 par cycle de plus, et 3,4 à 3,5 millions pour dix cycles, jusqu'à environ 5,3 millions si les actifs de chaque cycle sont froids. Ce sont les prix du gas d'avant la mise à niveau Glamsterdam d'Ethereum. Sous Glamsterdam, active sur Sepolia depuis le 2026-10-06, un slot de stockage neuf coûte environ cinq fois plus, et chaque action qu'une réclamation paie peut en écrire trois : sur Sepolia, la réclamation d'un cycle de trois actions a coûté 1 177 679 gas au premier à réclamer le cycle, et 878 713 à 888 051 aux suivants. Dix cycles de cinq actions prendraient environ 8 à 14 millions de gas, sous les 16 777 216 qu'EIP-7825 fixe par transaction (sous Glamsterdam, sur son gas d'exécution), et l'écran de réclamation envoie désormais cinq cycles par transaction au plus.

claimable indique ce qu'une adresse peut réclamer d'un cycle, action par action.

Les exclusions

Chaque token a sa propre liste, fixée par l'owner de StockFun : 16 adresses au plus par défaut (setMaxExcluded), aucune en double, aucune nulle. L'adresse de burn, 0x…dEaD, est toujours exclue et reste hors de la liste. Chaque modification crée une nouvelle version de la liste, datée : une fenêtre est mesurée contre la liste en vigueur à sa fermeture, quel que soit le moment où son cycle s'ouvre, et une modification ne vaut que pour les fenêtres qui se ferment ensuite.

Par défaut, seule l'adresse de burn est exclue, sur chaque token de marché. Le PoolManager d'Uniswap n'est jamais enregistré : il n'a pas besoin d'entrée. Le seul fournisseur de liquidité des pools StockFun est le lock de liquidité, qui ne détient rien hors d'un lancement. Un pool d'une autre plateforme qui détiendrait le token serait un holder enregistré ordinaire, que l'owner peut inscrire.

L'opérateur du lancement de $STOCKFUN détient toute la supply pendant les quelques blocs entre la frappe et le lock. Le script de lancement, LaunchProtocol, l'inscrit sur la liste de $STOCKFUN avant la frappe, sur l'adresse que prendra le token, puis vérifie que le token est bien là : aucune fenêtre ne peut se fermer entre la frappe et la liste. Jusqu'aux boucles d'audit du 2026-10-05, une fenêtre qui se fermait pendant ces blocs pouvait lui verser tout le premier cycle. Une liste de $STOCKFUN posée avant que la première fenêtre après le lancement soit fermée doit le garder.

Les actions mises de côté

Un envoi pour une fenêtre sans détention éligible est mis de côté pour le marché : par exemple des actions envoyées le jour du lancement d'un marché, pour une fenêtre finie avant qu'il existe.

Les actions mises de côté vont à la première fenêtre qui a des détentions éligibles après la dernière trouvée sans, quel que soit celui qui regarde et quand. openCycle, ou un envoi, pour la fenêtre immédiatement suivante les emmène. Sinon assignUnassigned, que n'importe qui peut appeler, examine les fenêtres finies dans l'ordre, 30 au plus par appel par défaut (setMaxWindowsPerAssign), et ouvre la première qui a des détentions éligibles, même si des cycles plus récents sont déjà ouverts. Les cycles peuvent donc s'ouvrir dans le désordre.

Cela vaut tant que, entre-temps, le calendrier des cycles ne change pas et que l'enregistreur de détention du token n'est pas remplacé. Un nouveau calendrier redécoupe les fenêtres pas encore ouvertes, y compris celles que les actions mises de côté doivent encore examiner ; un enregistreur remplacé entre-temps ne mesure aucune fenêtre commencée avant lui (voir la règle d'exploitation plus bas).

Un envoi qui ne trouve lui-même aucune détention éligible, alors que des fenêtres antérieures restent à examiner, échoue : assignUnassigned d'abord, puis l'envoi de nouveau. Une livraison venue de Robinhood Chain reste stockée sur Ethereum et peut être rejouée : depuis le 2026-10-06, le keeper relance lui-même une livraison stockée, une fois que sa simulation passe, et alerte avec la commande pour la lancer à la main quand il ne le peut pas (voir Le keeper). Depuis le 2026-10-05, un envoi pour une fenêtre qui finit à ou avant la dernière examinée, ce qu'un passage à des fenêtres plus longues peut produire, rejoint plutôt les actions mises de côté : un marché qui a des actions mises de côté continue de recevoir ses envois.

Les principes

• Un airdrop d'actifs, jamais un rachat de parts. Personne ne rend son token au vault. C'est la détention du token qui compte.
• Il récompense la détention, pas le trading.
• Aucun montant promis. Un airdrop dépend du volume passé, pas d'un taux. Il peut être nul, et rien ne promet qu'il y aura du volume demain.
• Aucune redemption. Un holder reçoit sa part de chaque airdrop, rien d'autre : il n'existe toujours aucun droit de retrait sur le vault.
• Le keeper déclenche, il ne choisit jamais. La répartition est calculée par un contrat à partir de la détention que tient l'enregistreur de détention. Le keeper choisit le moment de ses envois, jamais le montant, l'actif, la destination ni le destinataire, et il ne peut ni s'attribuer une part, ni en attribuer une à quiconque hors de ce calcul.
• Jamais plus que ce que détient un cycle. Chaque cycle paie au plus ce qu'il détient, action par action, et aucun holder ne reçoit plus que sa part au prorata, arrondie à l'inférieur.
• Une action, un cycle, un marché à la fois. Depuis le 2026-10-05, ce qui échoue sur une action, un cycle ou un marché ne bloque pas les autres : un envoi part action par action, une réclamation paie ce qu'elle peut et diffère le reste, et claimMany saute un cycle exclu.

Le mode urgence s'applique au contrat de l'airdrop comme à tout contrat qui détient des actifs du protocole : le transfert de l'owner, immédiat, déplace des actions et laisse les parts telles quelles. Depuis le 2026-10-05, les autres cycles ne paient jamais pour lui : les réclamations d'une action que le transfert a prise sont différées jusqu'au retour de l'action par restore, ou jusqu'à ce que l'owner passe la perte sur le cycle qui l'a subie (voir plus haut et Le mode urgence). Le contrat n'a pas d'urgence attribuée à un cycle, retirée pour tenir sous la limite de taille des contrats : la procédure qui ne laisse jamais ses comptes à court passe d'abord la perte (writeDownCycle, ou writeDownUnassigned pour les actions mises de côté), puis déplace l'action (emergencyTransfer). restore rembourse d'abord ce qu'un transfert a pris au-delà de ce qui couvrait les comptes (taken), et ne couvre les comptes qu'avec le reste. Sa pause arrête les envois, l'ouverture des cycles et le placement des actions mises de côté ; elle ne déplace rien et n'arrête jamais une réclamation. Le contrat de l'airdrop et l'enregistreur de détention sont upgradables par l'owner de StockFun, avec effet immédiat, comme tous les modules sauf les tokens et le lock de liquidité.

Une règle d'exploitation en découle : l'enregistreur de détention d'un token s'upgrade en place, ce qui garde tout son historique ; il n'est pas remplacé sur un token vivant. Depuis le 2026-10-05, un remplacement ne bloque plus le trading : le nouvel enregistreur part de la supply du token hors du PoolManager d'Uniswap à ce moment, un enregistreur qui a déjà enregistré ce token le refuse, et, depuis la seconde boucle d'audit de ce jour-là, un token refuse un enregistreur lié à un autre PoolManager que celui où vit son pool, qui compterait le pool comme un holder. Mais il ne connaît pas les soldes des holders : un holder qu'il n'a pas vu bouger se lit comme n'ayant rien détenu jusqu'à son prochain mouvement, si bien qu'une fenêtre qu'il couvre lui verse moins, sans verser davantage à personne. Les cycles déjà ouverts gardent l'enregistreur qu'ils ont figé. Jusqu'au 2026-10-05, un enregistreur neuf partait d'une supply nulle : chaque vente échouait, et les parts des cycles ouverts ensuite étaient cassées pour de bon.

Depuis la troisième boucle d'audit du 2026-10-05, un enregistreur désigné sur un token vivant part de la bascule : il note l'instant où le token l'a désigné (seededAt), et le contrat de l'airdrop ne mesure aucune fenêtre commencée avant. Les actions de ces fenêtres attendent, mises de côté, la première fenêtre que l'enregistreur couvre en entier. À la bascule, le token lui déclare aussi le solde de l'adresse de burn, si bien que la seule exclusion permanente tient dès le départ. Jusque-là, une fenêtre à cheval sur la bascule, mesurée depuis la bascule seule, versait trop à qui bougeait après. Procédure : ouvrir d'abord les cycles des fenêtres déjà fermées, puis basculer juste après la fin d'une fenêtre ; upgrader l'enregistreur en place reste la règle.

Ce qui était ouvert, et comment c'est tranché

Le registre du projet, doc/DECISIONS.md, suivait trois points ouverts comme TBD 5, 7 et 8. Les trois ont été tranchés le 2026-10-04 :

• Un envoi par le keeper (TBD 5). Non : seul le holder réclame, pour lui-même, à ses frais.
• Les limites (TBD 7). Aucun plafond par wallet, aucun montant minimum, et une part n'expire jamais.
• Les exclusions (TBD 8). Une liste par token, fixée par l'owner de StockFun, 16 adresses au plus par défaut, l'adresse de burn toujours exclue ; par défaut l'adresse de burn seule. Voir plus haut.

Ce qui reste

• Les adaptateurs d'actions. Les adaptateurs LayerZero qui portent chaque action vers Ethereum, un par action : l'adaptateur de verrouillage sur Robinhood Chain et son OFT sur Ethereum. Ils ne sont pas dans le dépôt ; les tests utilisent des mocks
• Un déploiement. Rien n'est déployé

L'étape de l'airdrop du keeper et l'écran de réclamation de l'app sont écrits depuis le 2026-10-05 : voir Le keeper et La dapp.

Et le Treasury Ratio ?

Le Treasury Ratio — valeur de la trésorerie divisée par la market cap en circulation — était la métrique signature du produit. Il n'a plus de sens : la trésorerie est vidée à chaque distribution. Il est caduc depuis le 2026-09-27.

La métrique qui le remplace reste à trancher. La proposition en cours : le cumul des actions distribuées aux holders d'un marché, en dollars. Entre deux distributions, la dapp continue d'afficher ce que contient la trésorerie, en attente du prochain airdrop.

Et le buyback du créateur ?

Supprimé. Du 2026-08-27 au 2026-09-27, le créateur d'un marché pouvait faire vendre des actions de la trésorerie pour racheter et brûler son token. Le créateur n'a désormais aucun pouvoir sur la trésorerie : il ne reçoit des actions que comme n'importe quel holder, s'il détient le token.

Avec lui disparaît le trajet retour du pont, de Robinhood Chain vers Ethereum, qui ne servait qu'au buyback du créateur. Le pont ne fonctionne plus que dans un sens. Les actions repassent dans l'autre sens pour l'airdrop, wrappées, par les adaptateurs d'actions : un autre chemin, qui ne transporte que des actions.

Le rachat-burn de $STOCKFUN n'est pas concerné : les 0,5 % de chaque trade qui achètent du $STOCKFUN et l'envoient au burn ne touchent à aucune trésorerie, et ils restent. Voir $STOCKFUN.

La formulation

Proposition de formulation pour la dapp, à valider :

Les actions achetées par le treasury sont distribuées aux holders du token, au prorata, à chaque airdrop. Ce n'est ni un rendement ni une garantie.

Le vocabulaire interdit s'applique intégralement à l'airdrop. Le projet n'écrit jamais passive income, earn stocks, returns ni your stocks are safe in the vault, et ne présente jamais un montant d'airdrop futur comme acquis.

Actions tokenisées émises par Robinhood, non disponibles aux US persons.