Modèle de confiance

Qui peut faire quoi. La réponse honnête, pas la réponse marketing.

Depuis le 2026-10-02, presque tous les contrats du protocole sont upgradables : l'owner de StockFun peut en remplacer le code, avec effet immédiat. Depuis le 2026-10-05, les chiffres du protocole, de la taxe au cycle de l'airdrop, sont aussi des réglages onchain de l'owner, avec effet immédiat eux aussi : les valeurs que donne ce livre sont leurs valeurs par défaut, listées plus bas avec ce qui reste fixe. Chaque règle que ce livre prête à un module est la règle de son implémentation actuelle. Hors du pouvoir d'upgrade : les tokens, le lock de liquidité et, sur Robinhood Chain, le déployeur des vaults miroirs.

Une panne ne bloque jamais le reste

Depuis le 2026-10-05, une règle de conception du fondateur vaut pour tout le code : « Quand il y a un truc qui fait buguer une fonction, il ne faut pas que ça pénalise les autres fonctions ; tout doit pouvoir continuer à marcher, et tout doit avoir des setters pour récupérer les fonds perdus et brancher la correction. » Les boucles d'audit comptent toute entorse comme un défaut.

• L'isolation. Une panne dans une fonction, un marché, une action, un cycle, un enregistrement ou un destinataire ne bloque jamais les autres : l'élément est sauté, gardé comme dû ou différé, avec un événement, et le reste passe
• Les leviers. Chaque contrat qui peut détenir de l'ETH ou des tokens a un levier pour en sortir ce qui est coincé, réservé à l'owner du protocole : le mode urgence sur les contrats qui tiennent des comptes, rescue sur les autres. Chaque module peut recevoir une correction : un upgrade, ou un réglage qui remplace le module. Voir Le mode urgence
• Une seule exception, voulue. La déclaration de chaque transfert de token à l'enregistreur de détention reste bloquante : si elle échoue, le transfert échoue. Une déclaration non bloquante 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 chacun : setRecorder(0) sur le token, qui arrête son enregistrement, ou un upgrade en place de l'enregistreur. Sans enregistreur, le contrat de l'airdrop n'ouvre aucun cycle de ce token, et ses envois sont mis de côté

Ce que personne ne peut faire

Ces points reposent sur des contrats qui ne peuvent pas être upgradés. Ils tiennent quels que soient les upgrades et les réglages de l'owner.

• Émettre de nouveaux tokens. La supply est frappée une fois, dans le constructeur, et les tokens ne peuvent pas être upgradés
• Déplacer les tokens d'un holder sans une autorisation de sa part. Les fonctions d'administration des tokens, setRecorder et, depuis le 2026-10-05, leurs rescues, ne touchent au solde d'aucun holder : un rescue ne sort que ce qui a été envoyé à l'adresse du token lui-même
• Retirer la liquidité d'un pool sans un préavis public de 30 jours. Le lock ne peut pas être upgradé, sa seule sortie est le mode fin, plus bas, et ses 30 jours sont une constante, pas un réglage. Ses rescues ne touchent à aucune position, et il n'a aucun appel générique
• Changer la commission de LP ou le tick spacing d'un pool vivant. Chaque pool garde ceux avec lesquels il a été créé : ils font partie de sa clé, que garde le lock

Ce que le code actuel exclut

Personne ne peut faire ceci avec les implémentations actuelles, l'owner compris. Chaque point repose sur un module que l'owner peut upgrader.

• Ajouter de la liquidité dans un pool StockFun. Seul le lock de liquidité le peut, depuis le 2026-10-01
• Bloquer le trading par un wallet de frais. Seule la part trésorerie est payée pendant un trade ; les autres sont réclamées ensuite. Depuis le 2026-10-05, un vault qui refuse sa part ne bloque pas non plus son marché : le hook la lui doit
• Laisser un marché, une action ou un destinataire en panne bloquer les autres, hors de l'exception voulue de l'enregistreur de détention : la règle plus haut
• Changer la composition d'un basket après création
• Changer les feeds de prix que lit un vault existant. Chaque feed est inscrit une fois, à l'initialisation de l'oracle, et chaque vault garde son oracle ; les heartbeats des feeds sont des réglages, et depuis le 2026-10-06 les deux gardes de l'oracle sur Robinhood Chain, qui ne peuvent que retenir un prix, jamais en changer un
• Envoyer les tokens du buyback de $STOCKFUN ailleurs que vers le burn
• Se servir du routeur Ondo hors d'un vault de la factory, depuis le 2026-10-05 : une attestation vaut pour qui la présente, et celle du keeper ne peut plus être dépensée par un tiers (M-7)
• Choisir qui reçoit un airdrop, ou réclamer la part de quelqu'un d'autre. La répartition découle de la détention enregistrée, au prorata, et seul le holder réclame

Ce que le créateur peut faire

• Percevoir la ligne créateur de chaque trade de son marché, 2 % par défaut
• Fixer la whitelist anti-snipe de son marché, dont les adresses paient la taxe normale pendant les premiers blocs : au plus 20 adresses par défaut, fixées dans la transaction de création, publiques, et non modifiables ensuite
• Acheter et vendre son propre token, comme n'importe qui

Il ne reçoit aucune allocation, ne contrôle pas la liquidité, et ne peut pas mettre son marché en pause. Il n'a aucun pouvoir sur la trésorerie : il ne reçoit des actions que comme n'importe quel holder.

Ce que le keeper peut faire

Déclencher les conversions, au moment qu'il choisit, pour les montants qu'il fixe, sur les routes qu'il propose. Toujours à l'intérieur des bornes oracle du vault et de la réservation de chaque action, et sans jamais choisir qui reçoit quoi. Depuis le 2026-10-01, sauter une action ne change plus les poids du basket : cette action garde sa part pour plus tard. Depuis le 2026-10-05, le vault tient le minimum que fixe le keeper sur ce qui arrive réellement. Depuis le 2026-10-06, le keeper convertit l'ETH d'un vault une fois par fenêtre de l'airdrop, comme décidé le 2026-09-27 : c'est une règle du keeper, que le vault n'impose pas ; le vault note seulement quand son ETH a été converti pour la dernière fois.

Depuis le 2026-10-05, il est aussi le seul à envoyer un batch de pont (bridgeReady) et, avec l'owner de StockFun, le seul à pré-déployer le vault miroir d'un marché sur Robinhood Chain (predeploy). Jusque-là, les deux étaient ouverts à tous. Le hub distant apprend le keeper d'un batch : avant le premier batch, c'est l'owner de StockFun qui pré-déploie le vault du premier marché, et un marché dont le keeper ne peut pas pré-déployer le vault est laissé hors de son batch.

Sur l'airdrop, depuis le 2026-10-04 : ouvrir le cycle d'un marché (openCycle), envoyer les actions d'un vault au contrat de l'airdrop (sendToAirdrop, en payant les frais LayerZero depuis Robinhood Chain) et placer les actions mises de côté (assignUnassigned). Il choisit le moment, jamais le montant, l'actif, la destination ni le destinataire : le montant est le solde du vault, la destination est le contrat que désigne le protocole, et la répartition découle de la détention. N'importe qui peut ouvrir un cycle ou placer des actions mises de côté, avec le même résultat quel que soit l'appelant. Un envoi arrivé après l'heure de fermeture suivante, 13:00 UTC par défaut, est mesuré sur la fenêtre du lendemain. Depuis la septième boucle d'audit, le 2026-10-06, il n'envoie une action qu'une fois qu'elle vaut ce que son envoi coûte, ce qui ne décide que du moment où elle part : ce qui attend reste au vault pour une fenêtre suivante. Depuis la neuvième, le même jour, il nomme aussi le gas que chaque livraison reçoit sur Ethereum, que le hub distant tient entre le plancher et le plafond que fixe l'owner de StockFun, et relance depuis sa propre clé une livraison bloquée sur l'endpoint de LayerZero sur Ethereum, ce que n'importe qui peut faire : ni l'un ni l'autre ne change ce qui est livré, ni où.

Depuis le 2026-10-05, il paie aussi, à chaque passage, ce que le hook et le lock doivent à un destinataire qui l'avait refusé (payTreasury, payOwed), et encaisse une fois par jour les frais de LP d'un pool créé avec une commission (collectFees). Ces appels sont ouverts à tous, et ne paient que les destinataires fixés : le vault du pool, ou le hook pour le créateur.

Sa clé est une clé chaude. Il ne choisit jamais où va un actif.

Ce que l'owner de StockFun peut faire

C'est ici que se trouve la confiance réelle. L'owner de StockFun est l'owner du protocole : l'owner de la factory sur Ethereum, que le hub distant reflète sur Robinhood Chain.

• Upgrader tous les modules sauf les tokens, le lock de liquidité et le déployeur des vaults miroirs, avec effet immédiat et sans préavis. Les vaults sont upgradés un par un, marché par marché, sur les deux chaînes
• Changer les chiffres du protocole, avec effet immédiat et sans préavis : la taxe, sa répartition et l'anti-snipe, les frais de création, la forme des nouveaux marchés, le seuil de conversion et les bornes de prix des vaults, le cycle de l'airdrop, et les autres listés plus bas
• Lancer le mode fin du lock et, 30 jours plus tard, récupérer toute la liquidité de chaque pool, celle de $STOCKFUN comprise, vers n'importe quelle adresse
• Désigner l'enregistreur de détention auquel chaque token déclare ses transferts. Si la déclaration échoue, le transfert échoue : la seule exception voulue à la règle plus haut, que setRecorder(0) lève aussitôt. Depuis le 2026-10-05, un token refuse un enregistreur lié à un autre PoolManager d'Uniswap que celui de son pool. L'enregistreur s'upgrade en place, ce qui garde son historique, et n'est pas remplacé sur un token vivant : depuis le 2026-10-05, un remplaçant part de la supply du token hors du PoolManager d'Uniswap, si bien que le trading continue, mais il lit les holders qu'il n'a pas vus bouger comme n'ayant rien détenu jusqu'à leur prochain mouvement, et une fenêtre qu'ils couvrent leur verse donc moins, sans verser davantage à personne ; depuis la troisième boucle d'audit du même jour, le contrat de l'airdrop ne mesure aucune fenêtre commencée avant la bascule. Jusqu'au 2026-10-05, un enregistreur neuf faisait échouer chaque vente et cassait les parts d'airdrop des cycles ouverts ensuite
• Enregistrer les baskets, avant qu'ils ne soient figés
• Poser les adresses write-once, une seule fois
• Nommer le keeper et les wallets de frais. Une réclamation paie le wallet en place au moment de la réclamation : un changement redirige aussi le solde équipe ou buyback pas encore réclamé
• Changer le routeur de swap officiel enregistré dans la factory, celui par lequel le hook reconnaît la whitelist anti-snipe
• Faire pointer les futurs vaults vers un autre routeur d'actions ou un autre registre d'oracles ; les vaults existants gardent les leurs
• Associer chaque action d'un basket à son token Robinhood Chain, en ajout seulement
• Fixer la liste d'exclusion de l'airdrop de chaque token, pour les fenêtres qui se ferment ensuite (setExclusions) ; enregistrer l'OFT de chaque action sur Ethereum (registerStockOft)
• Désigner le contrat de l'airdrop auquel les vaults envoient (setAirdropDistributor) ; un contrat remplacé garde chacun de ses cycles réclamable chez lui. Sur Robinhood Chain, désigner la route de l'airdrop, le contrat et le gas de chaque livraison (setAirdrop), et l'adaptateur de chaque action (setStockAdapter) ; depuis le 2026-10-06, fixer la valeur par défaut, le plancher et le plafond du gas que chaque livraison reçoit sur Ethereum (setAirdropReceiveGas, setAirdropComposeGas)
• Remplacer l'adaptateur du pont pour les envois futurs, aussitôt (changeAdapter), par un adaptateur qui garde exactement les mêmes épinglages : le même hub, la même factory, les mêmes tokens de la jambe cash, le même hub distant et la même destination. L'audit de sécurité du 2026-09-29 a établi que le hub distant refuserait les batches du nouvel adaptateur (M-2) ; le 2026-10-05, ce point a été tranché et laissé tel quel : un adaptateur se change en l'upgradant en place, à la même adresse
• Mettre en pause les conversions et le bridging, immédiatement. Un hub distant en pause applique quand même les changements de rôles que porte chaque batch. Sur le contrat de l'airdrop, la pause arrête les envois, les ouvertures et le placement des actions mises de côté, jamais une réclamation
• Déplacer n'importe quel actif hors d'un treasury, d'un hub de pont ou du contrat de l'airdrop, vers n'importe quelle adresse, aussitôt et sans préavis (emergencyTransfer), sur l'une ou l'autre chaîne, à tout moment. Sur le hub distant, depuis le 2026-10-05, charger ce transfert à un seul marché, en passant sa perte dans le même appel (emergencyTransferFromPending, et emergencyTransferRecord pour un enregistrement canonique dont le dépôt est arrivé)
• Après un tel transfert hors du contrat de l'airdrop ou du hub distant, passer la perte sur le cycle ou le marché qui l'a subie (writeDownCycle, writeDownUnassigned, writeOffPending, writeOffRecord, depuis le 2026-10-05). Sur le contrat de l'airdrop, la procédure qui ne laisse jamais ses comptes à court passe la perte avant de déplacer l'action. Un cycle ne peut être déprécié en partie que tant que personne n'y a réclamé l'action, chaque holder perdant alors la même part ; une fois des holders payés, il ne peut l'être que de tout le reste, que perdent les holders pas encore payés, et ce qui arrive ensuite au cycle se partage de nouveau au prorata entre tous ses holders. Aucun autre marché ne paie pour lui ; tant que la perte n'est pas passée ou que les actifs ne sont pas revenus par restore, que n'importe qui peut appeler, les paiements qui en dépendent attendent. Les deux contrats comptent ce qui couvre leurs comptes, jamais leur solde : des actifs en route vers un autre marché ne paient jamais la perte, et un transfert simple vers eux ne couvre rien
• Sortir d'un contrat sans mode urgence ce qui y a été envoyé par erreur, depuis le 2026-10-05 : rescue sur la factory, la Lens, les oracles, l'enregistreur de détention, les routeurs et les adaptateurs du pont ; borné sur le hook (l'ETH égaré seulement, jamais ce qu'il doit), sur le BuybackBurner (son ETH seulement quand aucun burn ne peut plus le dépenser), sur le lock (jamais une position ni une part qu'il garde ; rescueClaims et rescueNft pour des claims v4 ou un NFT) et sur les tokens (ce qui se trouve à l'adresse du token lui-même ; rescueClaims et rescueNft aussi). Le détail est dans Le mode urgence
• Changer sans préavis la configuration LayerZero des adaptateurs d'actions de l'airdrop, sans plafond sur les retraits

L'upgrade est le plus large de ces pouvoirs : il atteint d'un coup chaque règle de la deuxième liste ci-dessus. Avec les réglages, le mode fin, le transfert d'urgence et la configuration des adaptateurs d'actions, il signifie que StockFun n'est pas sans confiance et ne prétend pas l'être. Le treasury est gardé par le protocole avec un chemin de récupération contrôlé par l'owner.

Les réglages

Depuis le 2026-10-05, les chiffres du protocole sont des réglages onchain de l'owner de StockFun, sur les deux chaînes. Chacun prend effet dans la transaction qui le pose, sans préavis, émet un événement, et refuse les valeurs impossibles : un taux au-dessus de 100 %, une répartition plus grande que la taxe, une forme de lancement qu'un pool ne peut pas tenir. Les valeurs ci-dessous sont les valeurs par défaut, celles que donne ce livre.

• Chaque pool, dès le swap suivant. Un changement de la taxe ou de l'anti-snipe vaut dès le swap suivant sur chaque pool, y compris un pool encore dans ses blocs anti-snipe : la baisse se calcule avec les réglages en vigueur, depuis le bloc de lancement du pool. L'anti-snipe ne prélève jamais moins que la taxe. Le plafond de la whitelist s'applique à la création d'un marché
• Les nouveaux marchés seulement, pour leur forme. Une nouvelle supply, de nouvelles bandes, un nouveau tick spacing ou une nouvelle commission de LP valent pour les marchés créés ensuite. Chaque pool garde la commission de LP et le tick spacing avec lesquels il a été créé, et la Lens les donne, marché par marché ; le pool $STOCKFUN prend ceux en vigueur à son lancement
• En direct, pour les vaults. Chaque vault lit le seuil de conversion et ses bornes de prix à chaque conversion, et le lock lit les parts des frais de LP à chaque encaissement
• Les cycles ouverts gardent leur fenêtre. Un nouveau calendrier de l'airdrop vaut pour les fenêtres pas encore ouvertes, et les redécoupe, y compris celles que des actions mises de côté doivent encore examiner

Ce qui reste fixe :

• Le préavis de 30 jours du mode fin, END_DELAY, une constante du lock de liquidité, qui ne peut pas être upgradé
• L'immédiateté du transfert d'urgence : il n'a aucun délai, et aucun réglage ne peut en ajouter un
• Les unités et les encodages : le point de base, l'heure comme unité de l'enregistrement de la détention et des fenêtres de l'airdrop, l'adresse de burn, les formats des messages
• Le câblage : les feeds de prix, les pools sur lesquels achète le routeur d'actions, sur Ethereum, l'OFT USDG, les endpoints LayerZero du pont, le hub distant, le pool Curve. Ils sont fixés au déploiement ou inscrits une fois ; en changer un, c'est pointer vers un autre contrat, ce qui demande un upgrade

Les upgrades

Depuis le 2026-10-02, chaque module est un proxy upgradé en UUPS, sauf les contrats ci-dessous. Comment c'est construit : voir Architecture.

• Immédiat. Un upgrade prend effet dans la transaction qui le fait : pas de timelock, pas de préavis, comme pour les réglages et le transfert d'urgence
• Contrôlé. Seul l'owner du protocole peut upgrader. Une nouvelle implémentation doit répondre à la même autorité d'upgrade, et celles du hook et de l'enregistreur de détention doivent garder le même PoolManager
• Marché par marché. Chaque vault est son propre proxy. Une nouvelle implémentation de vault désignée dans la factory vaut pour les marchés créés ensuite ; les vaults existants sont upgradés un par un
• Stockage ajouté, jamais réordonné. La disposition du stockage de chaque module est enregistrée, et un script la vérifie avant chaque upgrade. Depuis le 2026-10-05, il la compare à toutes les profondeurs : une structure ne grandit qu'à sa fin, et seulement si elle est la valeur d'un mapping ou la dernière variable ; celle d'un élément de tableau ne change jamais

Ne peuvent pas être upgradés :

• Les tokens, tokens de marché et $STOCKFUN : des ERC-20 simples dont la supply est frappée une fois, sans mint, burn, pause ni blacklist. Leur seul setter, setRecorder, et, depuis le 2026-10-05, leurs rescues appartiennent à l'owner du protocole
• Le lock de liquidité, dont le code est ce qui garde la liquidité dans les pools. Sa seule sortie est le mode fin ; ses rescues ne sortent que ce qu'on lui a envoyé par erreur, jamais une position ni une part qu'il garde
• Le déployeur des vaults miroirs, sur Robinhood Chain : l'adresse de chaque vault miroir est dérivée de la sienne

Les deux déployeurs sur Ethereum, qui ne détiennent aucun état, sont remplacés via la factory plutôt qu'upgradés.

Le mode fin

La seule sortie du lock de liquidité, ajoutée le 2026-10-02 pour le cas où le projet s'arrête. L'owner de StockFun appelle end(). Dès lors, aucun nouveau marché ne peut être lancé, tandis que chaque pool continue de trader. Trente jours plus tard, l'owner peut récupérer toute la liquidité de chaque pool, vers n'importe quelle adresse. L'owner peut annuler à tout moment tant que la fin est en attente ; les pools déjà récupérés restent vides. Les 30 jours sont le préavis des holders. Le détail est dans Le lancement en deux positions.

Les dépendances externes

Aucune de ces dépendances n'est cachée, et aucune ne peut faire sortir un actif d'un vault vers une adresse.

Les risques acceptés

• Un upgrade, un changement de réglage et un transfert d'urgence prennent effet aussitôt : les holders n'en ont aucun préavis, contrairement au mode fin, annoncé 30 jours à l'avance
• Chaque transfert de token dépend de l'enregistreur de détention : une déclaration qui échoue fait échouer le transfert. C'est l'exception voulue à la règle d'isolation, avec son levier immédiat, setRecorder(0) ou un upgrade en place de l'enregistreur
• Aucune trésorerie ne s'accumule : tout est distribué, et un airdrop peut être nul si personne ne trade
• L'airdrop est versé en actions wrappées sur Ethereum : elles ne valent que par les actions verrouillées sur Robinhood Chain et par la configuration LayerZero, et un gel des Stock Tokens par leur émetteur bloquerait les actions verrouillées. Depuis le 2026-10-05, une action gelée n'arrête qu'elle-même : sa jambe d'achat, son envoi à l'airdrop et ses réclamations attendent, et les autres actions passent
• Un marché peut ne jamais épuiser sa première bande de liquidité
• Un aller-retour coûte 9,75 % avant tout mouvement de prix, à la taxe par défaut de 5 %
• Le rail cross-chain n'a pas été exercé en conditions réelles au moment où ce livre est écrit