2026-09-09 — AMM v4 : dépendances Solana 3.0 et récupération des lamports excédentaires

Deux choses sans rapport arrivent ensemble dans une seule reconstruction. La première est de la maintenance : AMM v4 était épinglé à solana-program =2.1.0 depuis la mise à niveau 2.1, et cet épinglage était bloquant. Les assistants du système-programme ont été déplacés dans leur propre crate solana-system-interface dans Solana 3.0, spl-token a atteint 9.0, et spl-associated-token-account a atteint 8.0. Cette version les prend tous les trois. La seconde est de l’argent que le protocole doit. SIMD-0437 réduit le minimum exempt de rent de 90 % en cinq étapes, et l’étape 1 a atterri sur mainnet le 3 septembre 2026. Chaque compte créé par AMM v4 avant cela — des centaines de coffres de pools, de mints LP, de comptes AmmInfo et TargetOrders — est maintenant surfinancé, et les lamports dans un compte appartenant à un programme ne peuvent être déplacés que par ce programme. D’où une nouvelle instruction.

​

TL;DR pour les intégrateurs

• Rien de ce qu’un trader ou LP appelle n’a changé. Initialize2, Deposit, Withdraw, SwapBaseIn, SwapBaseOut, SwapBaseInV2, SwapBaseOutV2, WithdrawPnl et SetParams conservent leurs listes de comptes, dispositions d’arguments et mathématiques. Aucune disposition de compte n’a changé. Aucun code d’erreur existant n’a bougé.
• Une instruction est ajoutée : WithdrawExcessLamports, tag 18. Réservée à l’admin, pas d’arguments, liste de comptes variadique. Elle retourne les lamports au-dessus du minimum exempt de rent des comptes contrôlés par AMM v4 et ne touche à rien d’autre. Voir products/amm-v4/instructions.
• Un code d’erreur est ajouté : 60 LamportsCalculateError. AmmError n’est pas numéroté par Anchor — il commence à 0 — donc c’est custom program error: 0x3c. Les codes 0–59 sont inchangés.
• CreateConfigAccount (tag 14) a cessé de lire la sysvar de rent et est maintenant documentée comme une instruction à 4 comptes. Rien dans cette version n’est cassant, ceci inclus : le compte était en dernier dans la liste et le gestionnaire lit positivement sans vérification de longueur, donc l’outillage admin qui le passe toujours continue de fonctionner.
• Un rafraîchissement IDL est requis si vous générez des clients à partir d’un. Une nouvelle instruction, une nouvelle variante d’erreur, une liste de comptes modifiée.

​

WithdrawExcessLamports

L’instruction prend le portefeuille de collecte de lamports comme seul signataire et destination, le PDA d’autorité AMM v4, le programme SPL Token, puis n’importe quel nombre de comptes source. Elle se distribue selon le propriétaire de chaque compte source : La branche wSOL est la plus intéressante. Le solde en lamports d’un compte SOL enrobé est son solde de token, donc le programme token rejette WithdrawExcessLamports sur lui purement et simplement. L’aller-retour via SyncNative et un UnwrapLamports de taille delta extrait uniquement l’excédent donné et laisse le solde enrobé exactement où il a commencé — ce qui est affirmé après, avec LamportsCalculateError si l’arithmétique n’est pas d’accord. Un coffre de pool côté SOL conserve donc sa liquidité complète lors d’un balayage, et aucun LP ne voit de changement de prix à travers un. Le signataire est une clé dédiée par cluster, codée en dur sous le même module config_feature que les adresses existantes du propriétaire AMM et des frais de création de pool. Contrairement à CPMM et LaunchLab, AMM v4 n’accepte que ce portefeuille — il n’y a pas de secours admin. Les adresses sont dans reference/program-addresses.

​

CreateConfigAccount a cessé de lire la sysvar de rent

Solana 3.0 est ce qui rend Rent::get() la façon naturelle de lire les paramètres de rent, donc la version a remplacé les quatre appels Rent::from_account_info(...) dans le programme. Dans trois d’entre eux — les assistants qui créent les comptes token, le mint LP et les comptes PDA d’un pool lors de Initialize2 — le compte sysvar est toujours passé et toujours transmis dans les CPIs du programme token, donc rien sur cette liste de comptes ne change. Dans CreateConfigAccount la sysvar n’avait pas d’autre but et était le dernier compte de la liste, donc elle est sortie de la liste documentée : Envoyer l’ancienne liste de cinq comptes fonctionne toujours. Le compte supprimé était en dernier, et process_create_config lit ses quatre comptes positivement via next_account_info sans rien vérifier le nombre total, donc un compte rent en fin de liste n’est jamais regardé. L’outillage admin devrait être mis à jour pour la clarté, pas l’urgence. Aucun constructeur orienté utilisateur ne construit cette instruction du tout. Initialize2 est le cas à ne pas sur-lire : il a aussi cessé d’appeler Rent::from_account_info, mais son compte de rent reste en position 3 et est toujours véritablement utilisé — le programme le transmet dans les CPIs spl_token::initialize_account et initialize_mint qui créent les coffres et le mint LP du pool. Le supprimer de cette liste de comptes casse la création de pool.

​

Changements de dépendances

Les pièces du système-programme que le programme utilise — system_instruction::create_account, transfer, allocate, assign, et l’ID du programme lui-même — viennent maintenant de solana-system-interface plutôt que de solana_program::system_program et solana_program::system_instruction. L’ID du programme est identique au byte, donc c’est un déplacement au moment de la compilation sans conséquence on-chain, y compris pour les vérifications InvalidSysProgramAddress qui le comparent. Deux modules morts ont également été supprimés : srm_token et msrm_token, les déclarations de mint Serum/MSRM laissées de la suppression d’OpenBook. Rien ne les référençait.

​

Ce qui n’a pas changé

• Chaque disposition de compte. AmmInfo, StateData, TargetOrders, AmmConfig — mêmes tailles, mêmes décalages de champs. Aucun changement d’indexeur ou de décodeur.
• Codes d’erreur 0–59. LamportsCalculateError est ajouté à 60, donc rien ne se décale.
• Le PDA d’autorité AMM. Toujours un PDA pour tout le programme, seed ["amm authority"], nonce 254.
• Frais, comptabilité PnL et la courbe. Intouchés. WithdrawExcessLamports déplace les lamports qui n’ont jamais fait partie des réserves d’aucun pool.
• Token-2022. Toujours non supporté. La nouvelle instruction parle uniquement au programme SPL Token hérité.
• ID du programme. Inchangé — voir reference/program-addresses.

​

Pages mises à jour

• products/amm-v4/instructions — WithdrawExcessLamports ajouté avec sa liste de comptes et sa table de distribution par propriétaire ; nouvelle section CreateConfigAccount / UpdateConfigAccount couvrant la suppression de la sysvar de rent ; lignes du tableau d’inventaire et de la matrice de changement d’état ajoutées.
• products/amm-v4/overview — bannière de version.
• reference/error-codes — nouvelle section « AMM v4 : AmmError n’est pas numéroté par Anchor » documentant le code 60 et la numérotation basée sur 0.
• reference/program-addresses — nouvelle section « Portefeuilles de collecte de lamports excédentaires ».
• solana-fundamentals/rent-and-reclaimable-rent — nouvelle section « Ce que les programmes Raydium balayent de leur propre côté » ; la note SOL enrobée corrigée pour dire que les deux programmes token exposent UnwrapLamports.
• solana-fundamentals/toolchain — Agave 3.1.10, release.anza.xyz, Rust 1.91.0.