Upgradabilité du routeur vs immuabilité du pool dans l’architecture de STON.fi
Pourquoi STON.fi rend certains contrats impossibles à modifier tout en laissant exactement un seul contrat améliorable — et ce que cette séparation vous apporte concrètement en tant qu’utilisateur.
La plupart des explications sur la sécurité des smart contracts traitent « immuable » comme un bien incontestable et « upgradeable » comme un compromis un peu suspect. L’architecture de STON.fi repousse cette façon de voir les choses d’une manière intéressante : elle ne choisit pas une seule philosophie de manière générale. Elle sépare volontairement ses contrats, en figeant définitivement certains et en rendant spécifiquement flexible un seul d’entre eux, et cette séparation n’est ni une erreur ni une incohérence — c’est la véritable décision de conception qu’il vaut la peine de comprendre si vous voulez savoir où votre confiance est réellement placée lorsque vous utilisez le protocole.
Je veux vous expliquer pourquoi cette séparation existe, contre quoi chaque côté protège réellement, et où se situe encore la vraie hypothèse de confiance une fois que vous avez cartographié tout le système. Parce que « audité et immuable » donne l’impression de clore la conversation sur la sécurité, alors que ce n’est en réalité que le début d’une discussion plus précise.
J’avais tendance à considérer « immuable » comme l’équivalent de « sûr ». Puis j’ai regardé de près ce que STON.fi laisse vraiment modifiable, et j’ai compris que la question intéressante n’était jamais « immuable ou non » — c’était « quelle partie précise, et pourquoi celle-ci ».
🏛️ La structure à connaître d’abord
La documentation de STON.fi décrit l’architecture de son DEX comme un ensemble de types de contrats distincts, chacun gérant une responsabilité spécifique plutôt qu’un seul contrat monolithique qui ferait tout. Le routeur agit comme point d’entrée, recevant les messages de swap et de liquidité entrants et les dirigeant vers le bon pool. Les contrats de pool détiennent les réserves réelles pour une paire de trading et exécutent le calcul de tarification AMM. Les contrats de compte et de portefeuille suivent les positions de liquidité individuelles des utilisateurs et gèrent les opérations de jetons LP séparément des deux autres.
Séparer les responsabilités de cette manière n’est pas seulement une bonne hygiène logicielle — c’est ce qui rend la question de l’immutabilité tout simplement abordable. On ne peut pas demander de manière sensée « STON.fi est-il upgradeable ? » comme une simple question oui/non, parce que la réponse honnête est « une partie, très précisément, et pas les éléments pour lesquels vous vous inquiéteriez probablement le plus ».
🔒 Pourquoi les contrats de pool sont documentés comme immuables
Les contrats de pool sont là où vivent vos fonds déposés, là où se produit la logique de calcul de tarification AMM, et là où se trouve la logique centrale à enjeux élevés de l’ensemble du protocole. La documentation de STON.fi indique que ces contrats ne peuvent pas être modifiés une fois déployés — aucune clé admin, aucun chemin d’upgrade, aucune future version de la logique qui pourrait modifier silencieusement la manière dont vos fonds sont valorisés ou gérés.
Tout cela compte pour plusieurs raisons concrètes. Un pool qui ne peut pas être modifié ne peut pas avoir sa logique changée discrètement pour rediriger des fonds, modifier défavorablement la répartition des frais, ou introduire une porte dérobée après votre dépôt — il n’y a pas de vecteur de type « rug-pull via upgrade » à craindre à ce niveau. Cela signifie aussi que ce qui est audité reste audité : l’examen de Trail of Bits sur STON.fi v2 a porté sur une logique de pool précise, immuable, et comme cette logique ne peut pas changer après coup, les conclusions de l’audit restent applicables de façon permanente à ces contrats exacts, plutôt que de décrire un instantané susceptible de dériver avec le temps. Et cela achète une vraie prévisibilité : toute personne ayant déposé de la liquidité il y a un an interagit aujourd’hui avec une logique de pool mathématiquement identique, sans risque « les règles ont changé pendant que mes fonds étaient verrouillés » à ce niveau.
Le compromis, et c’est un vrai, est que l’immutabilité signifie aussi que tout bug non découvert dans la logique du pool est permanent. Si quelque chose ne va pas, on ne peut pas corriger sur place — la seule solution est de déployer un tout nouveau pool et de migrer manuellement la liquidité, ce qui est plus lent et plus pénible qu’une simple mise à niveau. Le modèle de STON.fi accepte ce compromis délibérément : un risque de correction permanente en échange d’un risque d’override admin définitivement éliminé.
L’immutabilité n’est pas « ce contrat est définitivement sans bug ». C’est « s’il y a un bug, au moins personne ne peut pas le rendre discrètement pire volontairement ».
🔧 Pourquoi le routeur est la seule pièce upgradeable
Le routeur est différent, et délibérément. La documentation d’architecture de STON.fi identifie le routeur comme le point d’entrée du DEX et explicitement comme le seul contrat upgradeable dans l’architecture décrite, avec des upgrades soumis à un processus de time-lock de sept jours plutôt qu’à un changement instantané.
Pourquoi laisser exactement cette partie flexible alors que le reste est figé ? Parce que c’est la couche de coordination, pas la couche de détention de valeur — le routeur dirige le trafic et décide à quel pool doit aboutir une requête de swap donnée, tandis que les contrats de pool détiennent les réserves réelles. Ainsi, mettre à niveau la logique de routage ne nécessite pas de toucher directement aux fonds. Les écosystèmes évoluent aussi d’une manière qui exige que la logique de routage reste à niveau : nouveaux types de pools, nouvelles structures de frais, intégration avec davantage d’infrastructure comme Omniston, autant de changements qui peuvent nécessiter des mises à jour de la façon dont les requêtes sont dirigées, sans avoir besoin de toucher aux pools immuables que ces requêtes atteignent finalement. Et corriger un bug au niveau du routage ne devrait pas exiger de migrer chaque pool de l’écosystème — si une faille est découverte dans la manière dont le routeur dirige le trafic, plutôt que dans les mathématiques AMM elles-mêmes, une voie de mise à niveau permet de la corriger sans demander à chaque fournisseur de liquidité de déplacer ses fonds vers des pools nouvellement déployés.
Le time-lock de sept jours est le mécanisme qui rend cette flexibilité tolérable plutôt qu’alarmante. Toute mise à niveau proposée du routeur doit rester publiquement visible pendant une semaine complète avant d’être activée, offrant aux développeurs, aux chercheurs en sécurité et aux utilisateurs attentifs une vraie fenêtre pour inspecter le changement et réagir — se retirer, soulever des inquiétudes publiquement, ou simplement prêter davantage attention — avant qu’il ne soit mis en ligne.
Une mise à niveau du routeur sans délai serait juste une clé admin avec des étapes supplémentaires. Sept jours, c’est ce qui transforme « faites-nous confiance » en « vérifiez-nous : vous avez réellement le temps ».
⚖️ Ce que cette séparation protège réellement — et ce qu’elle ne protège pas
C’est la partie qui mérite qu’on soit précis, parce qu’une séparation architecturale propre ne signifie pas automatiquement que tous les risques sont éliminés. Le design protège vraiment quelques éléments spécifiques : la logique de tarification centrale de vos fonds déposés ne peut pas être modifiée après coup, puisque les calculs qui déterminent la sortie de votre swap ou le comportement de votre part LP sont fixés définitivement au moment où un pool est déployé. Les changements du routeur ne peuvent pas non plus prendre effet instantanément ou silencieusement : la fenêtre de sept jours garantit un espace public entre le moment où une mise à niveau est proposée et le moment où elle est réellement mise en ligne. Et un audit de la logique de pool reste valide indéfiniment, sans besoin de re-vérification constante, précisément parce que la logique audité ne peut littéralement pas changer sous vos pieds.
Mais il vaut aussi la peine de nommer ce que cette séparation n’élimine pas. Les upgrades du routeur représentent toujours un point de confiance réel, même avec le time lock — ces sept jours vous donnent l’occasion de remarquer et de réagir à une mauvaise mise à niveau, mais ils ne garantissent pas que quelqu’un le fera effectivement à temps, surtout pour les utilisateurs qui ne surveillent pas activement l’activité de gouvernance. Les capacités administratives propres au routeur comptent aussi : la documentation d’architecture de STON.fi indique qu’il gère des sujets liés au trading, aux frais des pools et aux upgrades, ce qui signifie qu’un changement même bien intentionné du routeur touche à des leviers réellement conséquents, pas seulement à une logique de routage cosmétique. Et les pools immuables peuvent encore contenir des bugs non découverts : l’immutabilité garantit que la logique ne sera pas changée malicieusement plus tard, mais elle ne dit rien sur le fait que la logique originale était irréprochable dès le départ. C’est précisément ce que font les audits, et ils ont aussi leurs propres limites, indépendamment de ce qu’ils ont examiné.
Le time-lock vous achète un avertissement. Il ne vous achète pas une garantie que vous le lirez réellement à temps, ni que sept jours suffiront toujours pour agir.
🔍 Comment utiliser concrètement cette information en tant qu’utilisateur
Comprendre cette séparation change ce qui mérite réellement d’être surveillé, plutôt que de traiter « STON.fi » comme une seule boîte noire indifférenciée en laquelle vous faites confiance entièrement — ou non :
Traitez les conclusions d’audit au niveau du pool comme durables, car un examen reste pertinent aussi longtemps que le pool existe précisément parce qu’il ne peut pas être modifié silencieusement après coup.
Faites particulièrement attention pendant les fenêtres d’upgrade du routeur : ces sept jours sont exactement le moment où il vaut la peine de lire les changements proposés, plutôt que de les laisser passer en survolant un avis de gouvernance comme du simple bruit de routine.
Comprenez que « non-custodial » et « aucun risque d’admin du tout » ne sont pas des affirmations identiques — l’immutabilité des pools traite une catégorie de risque de manière approfondie, tandis que l’upgradeabilité du routeur exige encore un socle de confiance dans le processus.
Rappelez-vous que le risque de bug persiste au niveau du pool, quelle que soit la politique d’upgrade : aucune décision d’architecture ne remplace une vraie revue de sécurité du code original.
Tout cela n’est pas fait pour donner l’impression que la conception de STON.fi est pire qu’elle ne l’est — au contraire. Un protocole qui prétendrait que tout est également immuable, sans aucun mécanisme pour corriger, au fil du temps, les problèmes de couche de routage, ferait face à un problème bien plus grave : soit rester bloqué de façon permanente avec un défaut de routage, soit recourir au processus pénible et perturbant de migration de l’ensemble d’un écosystème vers un système fraîchement déployé juste pour corriger quelque chose qui n’avait même pas besoin de toucher aux fonds des utilisateurs.
🧭 Vue d’ensemble
Ce que cette architecture démontre vraiment, c’est que « immuable » et « upgradeable » ne s’opposent pas comme deux philosophies en compétition où l’une serait simplement la bonne — ce sont des outils adaptés à des tâches différentes au sein du même système. La logique de valorisation et de tarification, qui détient de la valeur, bénéficie énormément d’être figée, parce que le coût d’un pool modifié malicieusement est catastrophique et irréversible dans le pire des cas. En revanche, la logique de coordination et de routage bénéficie de rester flexible : les écosystèmes évoluent et, à la longue, une infrastructure rigide devient une charge en soi, incapable de s’adapter sans des migrations douloureuses et perturbatrices.
La décision de design vraiment bonne ici n’est pas « rendre tout immuable » ou « garder tout flexible » — c’est d’identifier correctement la catégorie à laquelle appartient chaque contrat précis, et d’appliquer la bonne contrainte à chacun individuellement, plutôt qu’une politique unique appliquée au hasard par excès de prudence ou par excès de commodité. La séparation de STON.fi entre des pools verrouillés et un routeur time-lock, explicitement et transparenment upgradeable, correspond exactement à ce type de choix délibéré et réfléchi, et elle n’est pas unique à STON.fi non plus : bon nombre de protocoles DeFi mûrs, sur des chaînes différentes, arrivent à une version plus ou moins équivalente de cette séparation une fois qu’ils ont assez longtemps vécu la douleur des extrêmes. Un système totalement immuable finit par rencontrer un bug de routage ou un besoin d’intégration auquel il ne peut pas s’adapter sans une migration complète, perturbante. Un système entièrement upgradeable, sans aucun cœur immuable, demande aux utilisateurs de faire confiance à une promesse continue plutôt qu’à un ensemble fixe de règles vérifiables indépendamment. Se délibérer du milieu, plutôt que de choisir par défaut un extrême par idéologie, est ce qui distingue une architecture pensée d’une architecture qui n’a fait que choisir une philosophie et s’y tenir, indépendamment des compromis réels.
La question intéressante n’était jamais « immuable ou upgradeable ». C’est « quelle partie précise, et pourquoi celle-ci » — et une fois que vous pouvez répondre à ça, vous comprenez le profil de risque réel du protocole plutôt qu’un libellé en un mot.
❓ Questions fréquentes
Les contrats de pool de STON.fi peuvent-ils être modifiés après le déploiement ? Non. La documentation de STON.fi décrit les contrats de pool comme immuables : la logique centrale de tarification AMM et le code de gestion des réserves ne peuvent pas être modifiés une fois qu’un pool est déployé, ce qui fige définitivement la logique telle qu’elle a été revue et déployée à l’origine.
Qu’est-ce qui peut réellement être mis à niveau dans l’architecture de STON.fi ? Seul le contrat du routeur, qui sert de point d’entrée en orientant les requêtes de swap et de liquidité vers les pools appropriés. C’est explicitement la seule composante upgradeable, et tout upgrade proposé passe par un processus de time-lock de sept jours avant d’être activé.
L’upgradeabilité du routeur signifie-t-elle que STON.fi dispose d’une porte dérobée administrateur vers les fonds des utilisateurs ? Le routeur ne détient pas directement les réserves des utilisateurs — ce sont les contrats de pool qui les détiennent, et ils sont immuables. Les mises à jour du routeur affectent le trading, les frais et la logique de routage plutôt que la saisie directe des fonds déposés, et tout changement est soumis à la fenêtre publique de time-lock avant de prendre effet.
L’immuabilité des pools garantit-elle l’absence de bugs dans les contrats de STON.fi ? Non. L’immutabilité signifie que la logique déployée ne peut pas être altérée de manière malveillante après coup — elle ne dit rien sur le fait que le code original était irréprochable. C’est précisément le rôle des audits de sécurité indépendants : ils examinent la logique avant et pendant le déploiement, et ce n’est pas une promesse que l’immutabilité apporte à elle seule.
$ZEC
