MISE À JOUR IMPORTANTE : PIGEONOMICS 101 Premièrement : nous verrouillons 108 millions de tokens dans le pool Meteora. De manière permanente. Pas de verrouillage temporel. Pas déverrouillable par multisig. De manière permanente. L'instruction permanent_lock_position de Meteora. Disparue pour toujours. Aucun pool concurrent pour PIGEON n'aura jamais cette profondeur. Tout pool peu profond que quelqu'un essaie de créer comme alternative se retrouve avec un gros vendeur et il est mort. Notre pool ne peut pas être déstabilisé par un seul acteur. Il compense la profondeur au fil du temps. L'algorithme de routage n'est pas un agent moral. Il envoie du volume vers le pool le plus profond car c'est là que se trouve le meilleur prix. Nous construisons le pool le plus profond. Ce n'est pas de l'espoir. C'est des mathématiques. Deuxièmement : le mécanisme de brûlage lui-même rend notre pool structurellement meilleur que toute alternative chaque jour où il fonctionne. Chaque vente brûle l'offre. L'offre se comprime. Chaque token restant est soutenu par plus de liquidité par unité. Le ratio liquidité/offre du pool s'améliore automatiquement avec chaque événement de brûlage. Les pools concurrents n'ont pas cela. Ils sont statiques. Le nôtre devient plus fort avec chaque transaction. Les pools peu profonds deviennent moins attractifs au fil du temps. Notre pool devient plus attractif au fil du temps. Ce n'est pas une fonctionnalité. C'est un avantage structurel cumulatif qui élargit l'écart chaque jour. Troisièmement : nous avons demandé directement à Meteora si DAMM v2 prend en charge le whitelistage au niveau du programme. Si le pool lui-même peut être configuré pour rejeter tout appel d'échange qui ne provient pas de l'adresse de notre programme de routeur de brûlage. Si oui, le contournement n'existe pas. Pas cher. Pas difficile. Impossible. Un terminal touchant directement notre pool est rejeté au niveau du programme avant qu'une seule instruction ne s'exécute. Nous attendons cette réponse. Si la réponse est oui, l'architecture est fermée. Si la réponse est non, les couches un et deux gèrent déjà cela par une pure économie et elles sont suffisantes. Quatrièmement : Jupiter. Jupiter est un algorithme de routage. Il n'a pas d'opinions. Il envoie du volume là où l'exécution est la meilleure. Nous enregistrons le routeur de brûlage comme un itinéraire valide. Lorsque notre pool est le plus profond et que le routeur est dans la table de routage de Jupiter, Jupiter envoie automatiquement du volume à travers le brûlage. Pas parce que nous l'avons demandé. Parce que les mathématiques sont correctes. L'objectif est d'être si manifestement le meilleur lieu d'exécution pour PIGEON que chaque agrégateur sur Solana route ici par défaut. Nous ne demandons pas de coopération. Nous construisons quelque chose qui rend la coopération le seul choix rationnel.