Migration et AMM externe

Migration atomique sur l'achat de courbe finale, conversion de précision USDC, verrouillage LP, limites de donation et prix des produits constants externes.

Lorsque les Token vendables de la courbe atteignent zéro, BigShortProtocol-EVM établit la liquidité externe avec les Token réservés + réserves nettes réelles d’USDC de la courbe, tout en lançant le Short Engine propre au Token. La migration n’utilise pas d’USDC virtuels, ne mélange pas les fonds des courbes d’autres Token et ne traite pas la réserve de prêt comme liquidité externe initiale.

1. Déclenchement et ordre d’exécution

Ordre	Action	Résultat métier
1	Déterminer l’achat final	Solde vendable de Token à zéro, état `Complete`
2	Distribuer les Token de l’achat et rembourser le trop-payé	Le bénéficiaire du remboursement est l’émetteur de la transaction
3	Émettre les événements de transaction interne et de fin	Enregistrement de l’instantané final des réserves internes
4	Revérifier l’instantané de configuration du Token et l’adresse Engine attendue	Aucun basculement vers un Profile par défaut défini ultérieurement
5	Passer à `Migrating` et valider la Pair principale	Vérification de l’identité, du code d’exécution, des réserves et des soldes
6	Transférer 206,900,000 Token et les USDC réels représentables	Constitution de liquidité externe réelle
7	Frapper les LP de migration à l’adresse zéro et vérifier	Vérification que l’adresse zéro détient tous les LP initiaux
8	Déployer et initialiser le Short Engine	Liaison avec les réserves réelles de la Pair et le stock de prêt existant
9	Vérifier les liaisons et ouvrir le trading de la Pair principale	`externalTradingEnabled` devient vrai
10	Annuler le solde réel d’USDC de cette courbe et enregistrer la migration	État final `Migrated`

2. De native18 à l’USDC ERC-20 à six décimales

Le solde USDC natif Arc et l’interface USDC ERC-20 externe représentent le même actif de cotation à des précisions différentes. Le code actuel utilise :

Scénario	Précision	Une unité USDC
Paiements internes, comptabilité Factory, comptabilité interne Engine	native18	10¹⁸
Interface USDC ERC-20 de la Pair externe	external6	10⁶
Rapport de conversion $s$	—	10¹²

Soit $Q_{18}$ :

Q_{6} = ⌊ \frac{Q_{18}}{10^{12}} ⌋

Q_{migrated, 18} = Q_{6} \cdot 10^{12}, D = Q_{18} mod 10^{12}

Ici donc, $Q_{6}$ est le nombre de plus petites unités ERC-20 USDC transférées dans la paire, et $D$ est un reste en dessous de 0.000001 USDC. Le contrat n’arrondit pas ce reste ni ne l’inclut silencieusement dans les réserves de Pair.

Attribution du reliquat de migration

La migration retire le $Q_{18}$ complet de cette courbe du total des dettes des courbes non migrées, puis ajoute la dette de reliquat $D$ . Les réserves des courbes d’autres Token ne diminuent pas du fait de cette migration.

3. Exemple d’épuisement à l’échelle complète et trois valorisations

Exemple D : achat de tout le stock initial en une fois, sans taxe ni don

pour acheter les 793,100,000 Token, le net entrant dans la courbe est :

Q_{18} = ⌈ \frac{(4,292 \times 10^{18}) \cdot (793,100,000 \times 10^{18})}{(1,073,000,000 - 793,100,000) \times 10^{18}} ⌉

Élément	Résultat exact
USDC nets dans la courbe	12,161.433369060378706681
Token ajoutés à la Pair	206,900,000 Token
USDC ajoutés à la Pair	12,161.433369 USDC
Entier USDC external6	12,161,433,369
Reliquat de migration	0.000000060378706681 USDC

Ces exemples uniques partent d’un état initial explicite. Ils ne promettent pas que tous les parcours d’achats/ventes multiples cumulent exactement le même résultat à la plus petite unité ; les arrondis par transaction et le point d’entrée à budget exact créent des différences.

Ne pas confondre fin de courbe, valeur externe réelle et ancrage idéal

Indicateur	Valeur de cet exemple	Usage
USDC virtuels internes après le dernier achat	16,453.433369060378706681	Réserve virtuelle enregistrée à la fin de la courbe
Token virtuels à la fin de la courbe	279,900,000	Réserve virtuelle enregistrée à la fin de la courbe
Capitalisation du protocole à la fin de la courbe	58,783.256052377201524405 USDC	Calculée à partir des réserves virtuelles internes
USDC externes initiaux réels	12,161.433369	Fonds réels de la Pair
Token externes initiaux réels	206,900,000	Fonds réels de la Pair
Capitalisation externe initiale réelle du protocole	58,779.281628806186563557 USDC	`actualStartMarketCap`
Paramètre fixe d’USDC idéaux de migration	12,161.433370	Paramètre de risque, pas un montant de transfert imposé
Capitalisation idéale fixe de migration	58,779.281633639439342677 USDC	`startMarketCap`, ancrage des courbes de risque/marge

Le prix externe initial réel est d’environ 0.000058779281628806186564 USDC/Token. Les paramètres actuels n’imposent pas une « continuité parfaite du prix marginal à la plus petite unité avant et après migration ». Les réserves virtuelles internes et les réserves réelles de migration sont deux ensembles de valeurs distincts.

L’ancrage idéal fixe fournit une base reproductible au modèle de risque ; les réserves réelles de la Pair déterminent le prix spot, le coût de rachat de dette et chaque swap réel. Le paramètre de modèle de 12,161.433370 USDC ne doit pas être présenté comme un montant reçu nécessairement à chaque migration.

4. Précréation de Pair, dons et protection contre la contamination

Quels états préalables sont acceptables ?

Au début de la migration, il faut :

Réserve Token de la Pair à 0.
Solde réel de Token de la Pair à 0.
Offre totale de LP de la Pair à 0 ; aucun ancien LP détenu par autrui.
Réserve USDC de la Pair inférieure ou égale à son solde réel d’USDC.
Validation par le Profile de l’adresse Pair, de la composition en tokens, du lieu de négociation associé et de l’identité du code.

Après transfert, la migration vérifie aussi l’ajout réel d’USDC. Après frappe LP, la réserve Token doit être égale à l’allocation migrée, et la réserve USDC au solde réel d’USDC avant migration + USDC ajoutés cette fois. Une différence déclenche PairContaminated ou l’erreur de validation concernée et annule la transaction.

La vérification de l’instantané de configuration ne se limite pas à un numéro de version. La migration revalide les hashes de code et les relations du déployeur Engine, de l’implémentation Engine et de la Factory/Router du lieu de négociation ; elle contrôle le hash des paramètres Engine et la configuration Oracle. Elle dérive l’adresse attendue via le hash du code d’initialisation Pair et vérifie la Pair réelle via son hash de code d’exécution. Si le code d’exécution du déployeur ou de l’implémentation diffère de la valeur enregistrée, le dernier achat est annulé atomiquement au lieu d’utiliser silencieusement une implémentation modifiée.

Ces règles ne garantissent pas l’acceptation de dons de toute taille. Les plages entières des réserves Pair, la frappe LP et les autres contraintes restent applicables. Un don non intégré aux réserves peut aussi être retiré par des opérations normales de Pair avant migration ; il faut donc retenir le solde au moment de son exécution.

Où vont les dons ?

Soit $Q_{pre, 6}$ :

Q_{actual, 6} = Q_{pre, 6} + Q_{6}

Cette courbe ajoute toujours 206,900,000 Token. Les dons d’USDC conservés à la migration entrent dans le pool réel et ne sont remboursés ni au donateur ni au dernier acheteur. Ils augmentent le prix initial réel et actualStartMarketCap, ne réécrivent pas l’ancrage idéal fixe de migration. La libération de capacité pondérée dans le temps n’est pas non plus immédiatement achevée par un don créant un prix élevé à l’instant de migration.

Exemple E : 170 USDC supplémentaires conservés dans la Pair de l’exemple D

Élément	Sans don	Avec don supplémentaire de 170 USDC
Réserve externe Token	206,900,000	206,900,000
Réserve externe USDC	12,161.433369	12,331.433369
Capitalisation initiale réelle du protocole	58,779.281628806186563557	59,600.934601256645722571
Capitalisation idéale fixe de migration	58,779.281633639439342677	58,779.281633639439342677

Transférer directement des USDC à la Factory est différent : cela n’augmente pas automatiquement les realNativeReserves d’un Token et ne devient donc pas automatiquement ses fonds de migration. Solde comptable de la courbe, solde total de Factory et solde réel de Pair sont distincts.

5. Destination finale des LP et du stock de prêt

Aucun LP initial n’est rachetable par un détenteur ordinaire

{LPBalance}_{zero} = LPTotalSupply

Les LP frappés cette fois doivent aussi être supérieurs à 0, et le total LP supérieur à la liquidité retournée par cet appel, afin de couvrir la structure de liquidité minimale initiale V2. Ni créateur, ni exploitant, ni portefeuille du protocole, ni dernier acheteur ne reçoit ces LP de migration.

« Brûler les LP » signifie ici que l’adresse zéro détient les LP et qu’un compte ordinaire ne peut pas les récupérer pour les racheter. Cela ne signifie pas que Offre totale ERC-20 devient 0, ni que les Token de la Pair sont brûlés. Le contrôle de migration porte sur l’instant initial ; il ne permet pas d’affirmer que l’AMM externe n’acceptera jamais de nouvelle liquidité ni ne frappera d’autres LP.

La réserve de prêt reste indépendante

Les 199,861,071 Token sont déjà détenus à l’adresse précalculée de l’Engine. La migration ne fait que déployer et initialiser l’Engine, sans nouvelle frappe ni transfert de ce principal à la Pair. L’initialisation lit les réserves réelles de Pair et suit le principal de prêt disponible dans une comptabilité séparée.