$STOCKFUN

Le token du protocole. Il capte de la valeur sur l'ensemble du launchpad, et il applique à lui-même la règle qu'il impose aux autres.

Le flywheel

flowchart LR A[Trade sur n'importe quel marché] -->|0,5 % de chaque trade| B[BuybackBurner] B -->|achète sur le pool| C[$STOCKFUN] C -->|envoi à 0xdEaD| D[Supply en circulation réduite] D -.->|le protocole grandit| A

Chaque trade, sur chaque marché, crédite la ligne buyback, 0,5 % par défaut, au solde buyback du hook, dû au BuybackBurner. Le burner prélève ce solde au début de chaque burn, et n'importe qui peut le lui envoyer avec claimBuybackFees() ; depuis le 2026-10-01, le hook ne l'envoie plus pendant le trade. Le burner n'a ni owner à lui, ni fonction de retrait : tant que le pool $STOCKFUN est verrouillé, la seule chose que son code actuel puisse faire de l'ETH qu'il reçoit est acheter du $STOCKFUN et l'envoyer à l'adresse de burn, qui est codée en dur.

Depuis le 2026-10-05, l'owner de StockFun y a un levier, rescue, borné : un token envoyé là par erreur, à tout moment ; l'ETH seulement quand aucun burn ne peut plus le dépenser, le marché du protocole pas encore désigné ou son pool récupéré par le mode fin du lock.

« Racheté puis brûlé » est donc une propriété du code plutôt qu'une promesse, tant que le burner n'est pas upgradé : depuis le 2026-10-02, l'owner de StockFun peut l'upgrader, avec effet immédiat, comme tous les modules sauf les tokens et le lock de liquidité.

Son propre marché

$STOCKFUN a un TreasuryVault, sur le basket Index, alimenté par les mêmes 2 % que n'importe quel marché et airdroppé aux holders de $STOCKFUN comme toute trésorerie. Le protocole s'applique sa propre règle. Aucun $STOCKFUN n'est réservé à l'équipe. Ses cycles d'airdrop laissent de côté l'adresse de burn, comme sur n'importe quel marché, et l'opérateur du lancement, qui détient toute la supply pendant les quelques blocs entre la frappe et le lock.

Le rachat qui alimente ce vault n'est pas un bug du modèle, c'est le flywheel : un achat de $STOCKFUN par le burner paie lui-même 5 %, dont 2 % reviennent au vault protocole et 0,5 % au burner suivant. La série converge.

Ce qui le distingue

Marché lancé $STOCKFUN
Barème 2 / 2 / 0,5 / 0,5 2 / 2,5 / 0,5
Créateur Un utilisateur, 2 % Aucun, la ligne revient à l'équipe
Airdrop de la trésorerie Aux holders du marché Aux holders de $STOCKFUN
Supply 100 % en liquidité verrouillée 100 % en liquidité verrouillée, rien de réservé à l'équipe
Lancement Deux positions Une position single-sided

Les barèmes sont les réglages par défaut de la taxe, que l'owner de StockFun peut changer : voir Les frais.

Le contrat

$STOCKFUN est un ERC-20 simple et ne peut pas être upgradé. Toute sa supply, 1 000 000 000 de tokens par défaut, est frappée une fois, dans le constructeur, vers l'opérateur du lancement, qui la dépose entièrement dans la position verrouillée : rien n'est réservé à l'équipe. Il n'a ni mint, ni fonction de burn, ni pause, ni blacklist. Son seul setter, setRecorder, appartient à l'owner de StockFun : il désigne l'enregistreur de détention auquel chaque changement de solde est déclaré, puisque sa trésorerie est airdroppée à ses holders aussi. Si la déclaration échoue, le transfert échoue : c'est la seule exception voulue à la règle qui veut qu'une panne ne bloque jamais le reste, et son levier est immédiat, setRecorder(0) ou un upgrade en place de l'enregistreur.

Depuis le 2026-10-05, il a aussi des rescues, de l'owner de StockFun, comme chaque token de marché : rescue sort ce qui a été envoyé par erreur à l'adresse du token lui-même, ses propres tokens compris, déclarés à l'enregistreur comme tout transfert, tout autre token et l'ETH forcé ; rescueClaims et rescueNft, des claims v4 ou un NFT envoyés là. Aucun ne touche au solde d'un holder.

Le lancement

Le script LaunchProtocol lance $STOCKFUN dans un ordre fixe, signé par l'owner de StockFun :

  1. Il exige que le contrat de l'airdrop soit désigné, ce que fait DeployProtocol
  2. Il inscrit l'opérateur du lancement sur la liste d'exclusion de $STOCKFUN, sur l'adresse que prendra le token : aucune fenêtre de l'airdrop ne peut se fermer entre la frappe et la liste
  3. Il frappe $STOCKFUN, toute la supply à l'opérateur, et vérifie que le token est à cette adresse
  4. Il crée le vault du protocole, sur le basket Index par défaut, puis désigne le marché du protocole sur la factory
  5. Il dépose toute la supply dans la position single-sided verrouillée
  6. Il déploie le BuybackBurner et le désigne comme wallet du buyback

Jusqu'aux boucles d'audit du 2026-10-05, l'opérateur n'était pas exclu, puis il l'a été après la frappe : une fenêtre qui se fermait entre-temps pouvait lui verser tout le premier cycle de $STOCKFUN.

Depuis le 2026-10-06, un passage arrêté avant la désignation du marché du protocole (étape 4) reprend avec le token et le vault qu'il a laissés, que le script vérifie d'abord, au lieu de frapper un second $STOCKFUN. Voir Le déploiement.

Le burn

« Brûler » signifie envoyer à 0x000000000000000000000000000000000000dEaD. La supply totale ne bouge jamais — c'est la supply en circulation qui diminue, et la différence est vérifiable par n'importe qui avec un appel balanceOf.

C'est plus honnête qu'un vrai burn : rien n'est caché derrière un changement de totalSupply, tout est un solde public.