Cette page est traduite automatiquement par IA. La version anglaise fait foi.Voir la version anglaise →
Les portefeuilles intégrant Raydium doivent généralement répondre à quatre questions par utilisateur : dans quels pools cet utilisateur a-t-il des LP ? quelles positions (NFT CLMM) détient-il ? dans quelles farms est-il mis en jeu ? quelle est la valeur totale ? Cette page documente chacun de ces points.
Détection des positions Raydium
Jetons LP classiques (CPMM, AMM v4)
Ils ressemblent à n’importe quel autre jeton SPL : le compte ATA de l’utilisateur détient un solde. Un portefeuille l’affiche par défaut comme un simple jeton. Pour le révéler en tant que position LP Raydium :- Énumérez les comptes de jetons de l’utilisateur :
connection.getParsedTokenAccountsByOwner(user, { programId: TOKEN_PROGRAM_ID }). - Pour chaque mint, vérifiez la liste des mints Raydium :
GET https://api-v3.raydium.io/pools/info/lps?lps=<LP_MINT>,...(regroupez jusqu’à ~50 mints LP par appel). - Pour les mints correspondants, l’API retourne la référence du pool. Utilisez-la pour calculer la valeur de la position en jetons :
NFT de position CLMM
Les positions CLMM sont des NFT. Le PDAPersonalPositionState de chaque position est dérivé du mint du NFT. Pour détecter :
- Énumérez les NFT de l’utilisateur. Pour les NFT Metaplex hérités : filtrez les comptes de jetons pour ceux avec un approvisionnement de 1 et 0 décimales.
- Pour chaque mint de NFT, essayez de dériver le PDA PersonalPositionState :
-
Énumérez les positions du portefeuille avec
raydium.clmm.getOwnerPositionInfo({ programId })et faites correspondre surnftMint(il n’y a pas degetPositionInfo). Chaque entrée vous donne :poolId→ récupérez le pool pour résoudre les mintstickLower,tickUpper→ affichage de la plageliquidity,tokensOwedA/B→ calculez la valeur de la position + frais en attenterewardInfos→ récompenses en attente par flux
-
Pour les NFT de position émis sous Token-2022 (
OpenPositionWithToken22Nft), le programme du mint du NFT est Token-2022 plutôt que SPL Token. Énumérez les deux lors de l’analyse.
Mises en farm
Farm v3 / v5 / v6 ont chacun un PDA de registre par utilisateur. Dérivations :UserLedger possibles en hachant l’utilisateur avec une liste organisée d’ID de farm « probables ». L’énumération exhaustive de tous les ID de farm est impraticable (des milliers existent) ; utilisez l’API.
Calcul de la valeur de position
LP CPMM / AMM v4
Les trois modules n’ont pas la même signature :liquidity.getPoolInfoFromRpc prend { poolId }, tandis que cpmm.getPoolInfoFromRpc et clmm.getPoolInfoFromRpc prennent une chaîne base58 positionnelle.
raydium.token ou un oracle de prix).
Position CLMM
- Valeur de liquidité (prix actuel)
- Frais non collectés
- Récompenses en attente par flux
- Plage :
[tickLower_price, tickUpper_price]avec une barre visuelle montrant si le prix actuel est dans la plage
Mise en farm
reward_per_share_x64 avec la formule de mise à jour paresseuse avant de calculer (temps écoulé × taux d’émission ÷ total_staked).
Simulation de transaction pour aperçu
Avant qu’un utilisateur ne signe, les portefeuilles affichent généralement un aperçu des changements de solde. UtilisezsimulateTransaction :
accounts demande au validateur de retourner l’état du compte post-simulation pour les adresses listées. Beaucoup plus précis que d’essayer de prédire le changement de solde à partir de la forme d’instruction seule.
Pièges de simulation
- Les swaps CLMM ont besoin de tableaux de ticks valides. Si la taille d’entrée de l’utilisateur traverserait un tableau de ticks non initialisé, la simulation revient (comme l’exécution). Surfacez cela clairement dans l’interface utilisateur.
- Frais de priorité. La simulation s’exécute sans les instructions de budget de calcul appliquées. Pour une grande transaction qui dépasserait les 200k CU par défaut, la simulation échoue mais l’exécution réelle avec une limite CU explicite réussit. Définissez toujours la limite CU sur la tx simulée aussi.
- Blockhash frais. La simulation utilise le blockhash actuel ; si la signature prend >60s, la tx devient invalide. Re-simulez si l’utilisateur hésite.
Affichage Token-2022
Les jetons sous le programme Token-2022 doivent être étiquetés comme tels dans la liste de jetons du portefeuille, car ils ont des surfaces de risque différentes :- Mints avec frais de transfert : affichez les
transferFeeBasisPointsactuels comme « Frais de transfert : X% » à côté du solde. Avertissez lors de la réception — les utilisateurs peuvent ne pas réaliser qu’ils recevront moins que ce que l’expéditeur a envoyé. - Mints avec hook de transfert : surfacez l’ID du programme hook. Un hook malveillant peut bloquer les transferts sortants ; les utilisateurs doivent vérifier que le hook est celui qu’ils attendent.
- Mints non transférables : affichez « Non transférable » et désactivez swap/envoi. Ce sont généralement des jetons liés à l’âme ou des identifiants.
- Mints porteurs d’intérêts : le solde de l’interface utilisateur dérivé de
TokenAccount.amountne reflète pas les intérêts accumulés. UtilisezamountToUiAmountde@solana/spl-token(qui applique le facteur d’échelle) pour la valeur affichée.
Affichage de l’APR de la farm
L’APR affiché aux utilisateurs doit combiner tous les flux de récompenses en direct, convertis en USD et annualisés :APR : X,Y%. Si le mint de mise en jeu est un jeton LP, calculez également l’APR des frais de base du LP sous-jacent et étiquetez la somme comme « APR total » ou « APR + frais ».
Pointeurs
products/clmm/ticks-and-positions— dérivation de la valeur de position.products/farm-staking/accounts— champs d’état de la farm.algorithms/token-2022-transfer-fees— sémantique d’affichage pour les jetons avec frais de transfert.
- Raydium SDK v2 — assistants de position/farm.
- Points de terminaison de position utilisateur sur
api-v3.raydium.io.

