Bot de trading de NFT ETH : distinguer l’ETH, le WETH et les stocks

Définir le modèle de compte du bot de trading de NFT ETH

Le modèle de compte du bot de trading de NFT ETH doit distinguer l’ETH natif, les jetons fongibles de paiement, les avoirs en NFT et les engagements de trading en cours. Chaque registre répond à une question différente et doit conserver ses propres unités et preuves.

Le solde natif indique à l’opérateur combien d’ETH le compte détient. Un solde WETH décrit des unités d’un contrat de jeton particulier. Les stocks NFT identifient des actifs et des quantités. Les ordres décrivent des échanges futurs possibles dont les effets peuvent ne pas encore apparaître dans l’un ou l’autre solde.

Attachez l’identité de la chaîne à chaque registre. Le même symbole de jeton ou une adresse d’apparence familière sur un autre réseau n’établit pas le même actif ni des fonds disponibles. Un tableau de bord multiréseau ne doit pas laisser un total combiné devenir une hypothèse transactionnelle non étayée.

Le modèle doit aussi distinguer les observations actuelles des estimations. Un paiement entrant attendu n’est pas un solde disponible, et une valorisation au prix plancher de collection n’est pas un produit de vente. Ces séparations permettent le rapprochement ultérieur lorsque les interfaces s’actualisent à des moments différents.

Comprendre la séparation des soldes d’ETH et de WETH

La séparation des soldes d’ETH et de WETH reflète une distinction réelle d’actifs. Le WETH représente de l’ETH enveloppé via son contrat de jeton ; ce n’est pas simplement une autre étiquette d’affichage du solde ETH natif. Le chemin transactionnel pris en charge détermine la forme utilisée.

L’explication de WETH d’OpenSea décrit son rôle dans les offres NFT Ethereum. Un bot doit préserver l’identité pertinente du jeton et vérifier les exigences actuelles du circuit plutôt que supposer que tout écran libellé en ETH peut dépenser l’une ou l’autre forme sans autre opération.

Envelopper ou désenvelopper change la composition des actifs du compte et peut entraîner une dépense réseau. Cela doit être enregistré comme une conversion avec les coûts associés, pas comme un revenu de trading ni une nouvelle transaction NFT rentable.

La distinction affecte aussi la disponibilité. Un compte avec beaucoup de WETH mais peu d’ETH natif peut avoir besoin d’un moyen pris en charge pour financer l’opération réseau suivante. Un total combiné unique peut masquer cette contrainte pratique.

Suivre une transaction hypothétique d’enveloppement

Supposons qu’un compte commence avec 1,5 ETH et aucun WETH. Dans un exemple inventé, il enveloppe 1,2 ETH et paie 0,002 ETH de dépense réseau. Après l’opération, il détient 1,2 WETH et 0,298 ETH.

À une valorisation de planification supposée d’un pour un, le montant combiné est de 1,498 équivalents ETH, reflétant la dépense de 0,002 ETH. Cette convention de valorisation ne fusionne pas les soldes et n’établit pas que chacun peut payer directement toute instruction ultérieure.

Si le compte désenveloppe ensuite 0,2 WETH et paie une autre dépense supposée de 0,001 ETH, le WETH tombe à 1,0 et l’ETH natif monte à 0,497. L’opération augmente l’ETH natif disponible tout en réduisant le solde enveloppé.

Préservez les deux côtés de chaque conversion et la référence transactionnelle réelle. Un rapport ne montrant que l’ETH entrant du désenveloppement pourrait classer à tort le principal restitué comme un revenu. L’histoire économique sous-jacente explique pourquoi le solde a changé.

Garder les réserves de gas dans l’actif qui les paie

Pour une transaction Ethereum conventionnelle où le compte paie directement les frais réseau, la dépense de gas est payée en ETH. Un solde WETH ne satisfait pas automatiquement ce besoin de financement natif. Les autres modalités de paiement prises en charge doivent être identifiées explicitement plutôt que supposées.

Le bot doit réserver un montant natif approprié pour les opérations permises et la reprise du compte. Cette réserve est un choix de politique, distinct de tout budget de jetons de paiement pour acquérir des NFT. Elle doit rester visible dans la vue du compte.

Le guide des frais de gas OpenSea pour le trading examine comment différentes actions créent des coûts réseau. Ici, le point comptable important est que l’actif utilisé pour le NFT et celui utilisé pour l’opération réseau peuvent différer.

Ne décrivez pas la réserve comme une dépense avant qu’elle soit réellement dépensée. Elle réduit la permission actuelle d’achat parce que le propriétaire l’a protégée pour un autre usage, mais reste un actif du compte. Confondre une réserve avec des frais peut fausser aussi bien les totaux de trésorerie que la performance présentée.

Calculer le gas dans ses unités réelles

La documentation du gas d’Ethereum distingue les quantités de gas du prix par unité de gas. Le bot doit préserver ces unités plutôt que traiter une limite de gas comme un montant d’ETH ou une cotation de prix comme des frais totaux.

Pour une transaction fictive, une limite de 160 000 unités de gas et des frais maximaux de 50 gwei par unité impliquent une enveloppe maximale de coût de gas de 0,008 ETH. Le calcul utilise un gwei égal à un milliardième d’ETH. Cela ne signifie pas que toute l’enveloppe sera nécessairement facturée.

Si l’usage réel hypothétique est de 120 000 unités à un prix effectif de 30 gwei, la dépense réelle est de 0,0036 ETH. Le registre doit enregistrer ce résultat séparément de la réservation antérieure de 0,008 ETH.

Ce sont des calculs illustratifs Ethereum, pas des tailles typiques de transactions NFT ni des prix actuels. Les estimations réelles dépendent de l’opération et de l’état, et d’autres réseaux peuvent avoir des composantes de frais supplémentaires. Le modèle doit utiliser les règles réelles de reçu et de coût de la chaîne concernée.

Distinguer les engagements WETH des avoirs WETH

Un solde de paiement détenu dans le portefeuille peut soutenir des offres signées susceptibles de s’exécuter ultérieurement. Le bot doit suivre ces engagements en plus du solde actuel de jetons. Une requête de solde seule n’explique pas combien la politique de trading de l’utilisateur a déjà affecté.

Supposons qu’un compte Ethereum hypothétique détienne 1,2 WETH et ait deux engagements d’acquisition actifs séparément pour 0,45 et 0,50 WETH. Leur dépense possible combinée est de 0,95 WETH, laissant 0,25 WETH selon une politique simple de réservation intégrale.

Le portefeuille peut encore afficher les 1,2 WETH avant l’exécution de l’une ou l’autre offre. Cet affichage ne signifie pas que la politique doive autoriser 1,2 WETH supplémentaires d’obligations. Le calcul de réservation décrit l’usage futur possible des mêmes actifs.

Ne généralisez pas ce modèle particulier de détention en portefeuille à toutes les chaînes. Les offres de places de marché Solana peuvent utiliser d’autres modalités de financement. Le guide d’un processus de trading de NFT par contrat intelligent insiste sur la vérification du mécanisme réel derrière l’interface plutôt que sur l’application d’un modèle de compte partout.

Distinguer les autorisations de paiement des permissions NFT

Une autorisation de dépense de jetons fongibles autorise une adresse précise à dépenser selon les règles de ce jeton. Les permissions NFT autorisent des transferts précis ou un opérateur selon la norme NFT et le comportement du contrat. Elles ne doivent pas partager un champ ambigu « approuvé » dans le modèle de compte.

Le bot doit identifier la chaîne, le contrat de jeton, l’adresse autorisée à dépenser ou l’opérateur et le périmètre pertinent. Une approbation de dépense de WETH ne signifie pas qu’un contrat sans rapport puisse déplacer des NFT. Une approbation d’opérateur NFT n’établit pas que le compte possède assez de jetons de paiement pour un achat.

La politique de stratégie du compte reste une restriction distincte. L’approbation technique peut permettre des actions allant au-delà des limites définies par l’ensemble de collections autorisées ou le plafond de prix du bot. Le chemin transactionnel doit appliquer ces règles plus restrictives avant d’utiliser les permissions disponibles.

Lorsqu’une permission change, préservez les preuves et l’heure. Un bouton local ne doit pas être présenté comme une révocation sur la chaîne tant que l’action prise en charge n’a pas réellement abouti. Les ordres existants et les opérations en attente peuvent encore nécessiter un rapprochement distinct.

Identifier les objets ERC-721 par contrat et jeton

La norme ERC-721 définit une interface pour les jetons identifiés individuellement, notamment les opérations de propriété et de transfert. Un registre de trading doit préserver ensemble le contrat et l’identifiant de jeton avec la chaîne.

Deux collections peuvent utiliser le même identifiant numérique sans renvoyer au même NFT. Un numéro d’objet comme 42 n’a donc pas de signification complète sans son contexte de contrat. Le nom affiché et l’image sont des métadonnées supplémentaires plutôt que des remplacements de cette identité.

Utilisez les preuves de propriété appropriées au contrat réel. Un décompte de jetons au niveau de la collection n’établit pas que le compte possède l’objet particulier qu’il entend proposer à la vente. Le bot doit vérifier l’actif précis pertinent pour l’action proposée.

Préservez aussi l’historique lorsqu’un objet sort puis revient. L’identifiant reste identique, mais le coût d’acquisition et l’épisode de détention peuvent changer. Écraser l’ancien registre effacerait le résultat économique de l’opération antérieure.

Utiliser une comptabilité des quantités ERC-1155

La comptabilité des quantités ERC-1155 nécessite des soldes pour chaque identifiant de jeton pertinent. La norme ERC-1155 prend en charge plusieurs types de jetons et montants de transfert dans un contrat. Un indicateur de propriété d’un objet unique ne peut pas représenter exactement tous ces avoirs.

Un bot doit préserver le contrat, l’identifiant, le compte et la quantité dans le registre de stocks. Un transfert de certaines unités peut laisser un solde restant sous le même identifiant. La présence ultérieure de l’objet dans le portefeuille ne signifie pas que la quantité initiale reste inchangée.

Les opérations par lot nécessitent aussi une interprétation soigneuse. Une transaction peut affecter plusieurs identifiants ou montants. Le processus comptable doit reconstituer les variations d’actifs réelles plutôt qu’attribuer toute la transaction à l’objet montré en premier par l’interface.

L’étiquette de norme est une entrée du modèle de propriété, pas une preuve que chaque contrat ou circuit de place de marché prend en charge toute opération possible. Vérifiez le comportement pris en charge pertinent pour l’achat ou la vente prévus et refusez clairement les cas non pris en charge.

Suivre un achat de plusieurs unités jusqu’à une vente partielle

Considérez un achat fictif distinct de huit unités à 0,035 équivalent ETH chacune, avec 0,004 équivalent ETH de dépense d’entrée affectée. Le coût total d’acquisition est de 0,284 équivalent ETH. Avec une répartition égale, chaque unité porte un coût de 0,0355.

Supposons que trois unités se vendent ensuite à 0,05 chacune. Le produit brut est de 0,15. Une déduction inventée de 3 % vaut 0,0045, et une dépense de sortie affectée distincte de 0,002 laisse un produit net de 0,1435.

Les trois unités vendues portent 0,1065 de coût d’acquisition, donnant un gain réalisé de 0,037. Cinq unités restent avec un coût affecté de 0,1775. Leur issue finale reste ouverte et ne doit pas compter comme bénéfice réalisé.

L’exemple utilise une unité commune de planification pour la lisibilité. Un registre réel conserve séparément le jeton de paiement et les dépenses natives avant d’appliquer une méthode de valorisation énoncée. Cela empêche un total pratique de cacher quels actifs sont réellement entrés ou sortis du compte.

Préserver les montants entiers et les identifiants de jetons

Les valeurs sur la chaîne utilisent souvent des unités de base entières, tandis que les interfaces affichent des montants décimaux. Le bot doit effectuer des conversions délibérées en utilisant les décimales de l’actif concerné et préserver les valeurs exactes pour construire les transactions. Les approximations binaires à virgule flottante peuvent être inadaptées aux limites monétaires exactes.

Les identifiants de jetons nécessitent aussi un traitement exact. Ce sont des identifiants, pas des valeurs à arrondir pour la présentation ou les analyses. Un grand identifiant doit survivre au stockage, à l’export et à la recherche sans être modifié par un type de données choisi par commodité.

Le registre interne peut fournir une mise en forme lisible à côté de la valeur exacte. Cela aide l’opérateur à inspecter une proposition sans perdre la précision nécessaire à la vérification de sa transaction. La mise en forme d’affichage ne doit pas modifier le montant autorisé sous-jacent.

Un petit ensemble de tests peut inclure un paiement fractionnaire, un grand identifiant de jeton et deux actifs aux conventions décimales différentes. Les résultats attendus doivent être connus avant l’exécution de l’outil pour qu’une erreur de conversion soit visible plutôt qu’absorbée dans un total d’apparence plausible.

Interpréter séparément les ordres signés et les résultats transactionnels

Une annonce ou une offre signée exprime des conditions susceptibles d’être exécutées selon le protocole applicable. Elle ne prouve pas en soi que la propriété ou le paiement a déjà changé. Le bot doit maintenir l’état des ordres et les effets sur le compte comme des registres reliés mais distincts.

Lors de l’exécution, examinez les variations d’actifs réelles, le destinataire et la contrepartie. Un indicateur général de réussite transactionnelle n’explique pas à lui seul chaque effet économique d’une transaction contenant plusieurs opérations.

Gardez les soumissions incertaines visibles jusqu’à leur résolution par les preuves pertinentes de la chaîne. Un délai dépassé ne doit pas automatiquement libérer la réservation ni créer une autre acquisition indépendante. Le processus de reprise commence par l’intention initiale et la référence transactionnelle.

Cette distinction améliore aussi l’interface utilisateur. Un ordre peut être actif tandis que le compte détient encore le NFT, ou une acquisition peut être vérifiée tandis qu’un index de place de marché n’est pas encore actualisé. L’écran doit décrire ces états plutôt que les réduire à une seule étiquette trompeuse indiquant « terminé ».

Garder explicite l’identité de la chaîne entre les réseaux EVM

Un format d’adresse compatible Ethereum ne rend pas les soldes ou les contrats interchangeables entre les réseaux. Le bot doit inclure l’identité de chaîne lors du stockage des contrats de jetons, des permissions, des circuits d’ordres et des références transactionnelles.

Le guide d’un bot de NFT Polygon fournit une comparaison utile. La compatibilité EVM peut rendre certains concepts logiciels familiers, tandis que les actifs natifs de gas, les contrats déployés et les chemins de place de marché pris en charge exigent encore une vérification distincte.

N’utilisez pas un solde combiné de tableau de bord pour autoriser une transaction sur un réseau sauf si un chemin de financement pris en charge fait partie de la proposition réelle. Des fonds détenus ailleurs ne sont pas automatiquement disponibles à destination simplement parce que leurs symboles correspondent.

Si un circuit entre réseaux est intentionnellement utilisé, enregistrez ses étapes et ses coûts réels. Un transfert entre réseaux en attente est une autre opération de compte non résolue, pas une excuse pour supposer que le solde de destination a déjà augmenté.

Rapprocher les transferts sans inventer de revenu de trading

L’enveloppement, le désenveloppement et les transferts entre les portefeuilles du propriétaire peuvent modifier les soldes sans créer une vente de NFT rentable. Le registre a besoin d’une classification préservant ces différences et évitant de traiter tout actif entrant comme un revenu.

Un NFT reçu sans registre d’achat connu peut avoir un coût historique non résolu. Enregistrez l’actif et les informations manquantes plutôt que d’attribuer un coût de revient nul seulement parce qu’aucun paiement n’apparaissait dans la même transaction.

De même, un NFT sortant peut représenter un transfert interne plutôt qu’une vente. Le produit d’une vente nécessite des preuves de contrepartie et de contexte. Le sens du mouvement du jeton seul n’établit pas le résultat financier.

Cette discipline rend l’examen global du compte plus crédible. Les dépenses en ETH natif, les variations de jetons de paiement et les transferts NFT doivent se rapprocher en un historique cohérent, les éléments inconnus restant visibles plutôt que cachés dans un ajustement rendant le solde final commode.

Tester le modèle de compte avec des différences délibérées

Un test utile comprend assez de WETH pour une offre mais des fonds natifs insuffisants pour l’opération réseau prévue payée directement. Le résultat attendu est un rejet de financement ou une solution prise en charge examinée séparément, pas une affirmation que le solde combiné suffit.

Un autre cas de test peut inclure une vente partielle ERC-1155 et une observation de transfert dupliquée. La quantité restante et la répartition du coût ne doivent changer qu’une fois pour la vente réelle. Des preuves répétées ne doivent pas créer d’unités ou de produit supplémentaires.

Testez aussi la mauvaise chaîne et une autorisation de paiement attribuée à la mauvaise adresse autorisée à dépenser. Ces erreurs doivent être identifiées avant signature, avec assez de contexte pour que l’opérateur comprenne la différence. Un échec générique après soumission est un contrôle plus faible.

Les tests établissent un comportement dans leur périmètre énoncé. Ils ne valident pas une stratégie de valorisation et ne garantissent pas la compatibilité future. Leur valeur est de montrer que le logiciel préserve les distinctions nécessaires pour comprendre le compte.

Un bot de trading ERC-721 doit préserver l’identité de chaîne, de contrat et de jeton à travers les vérifications de propriété, les approbations, les ordres et les transferts confirmés.

Garder explicable le registre du bot de trading de NFT ETH

La vue finale du compte doit permettre au lecteur de distinguer l’ETH natif dépensable, les soldes de jetons de paiement, les engagements possibles liés aux ordres, les quantités de NFT vérifiées et les dépenses réalisées. Un total commun de valorisation peut figurer au-dessus de ces registres sans les remplacer.

Lorsqu’un résultat paraît surprenant, rattachez-le aux variations d’actifs sous-jacentes. Une baisse de WETH peut financer une acquisition, une baisse d’ETH peut payer le gas et une vente NFT partielle peut laisser une importante position ouverte. Le registre doit expliquer chaque relation dans ses propres unités.

Examinez les estimations et les coûts réels après la fin des transactions, tout en préservant l’autorisation initiale. Les différences peuvent améliorer la planification ultérieure, mais réécrire l’ancienne proposition pour correspondre au résultat cacherait si le contrôle a fonctionné.

Un bot de trading de NFT ETH inspire davantage confiance lorsqu’il ne brouille pas les actifs, les normes ou les états. Une séparation claire permet une autorisation exacte et un examen financier honnête, y compris la conclusion que le compte manque des bons fonds ou des bonnes preuves pour l’opération proposée suivante.