Bot de trading de NFT : assurer la cohérence des stocks et des ordres

Donner un sens précis aux stocks du bot de trading de NFT

Les stocks d’un bot de trading de NFT correspondent aux actifs effectivement détenus selon les règles de vérification choisies pour le compte. Ce n’est ni une liste d’objets que le logiciel souhaite acheter, ni un ensemble d’offres signées, ni un groupe de NFT récemment affichés par une recherche sur une place de marché.

Le registre doit identifier la chaîne, l’identifiant de l’actif, la norme, la quantité et le compte qui le contrôle. Un nom affiché peut aider une personne à reconnaître l’objet, mais la logique des stocks doit utiliser des identifiants qui distinguent un droit d’un autre. Des illustrations similaires ne rendent pas deux jetons interchangeables.

Joignez la transaction ou toute autre preuve ayant établi la détention. Conservez également l’heure et l’état de la chaîne lors de sa vérification. Si une action externe du portefeuille change la propriété, les stocks doivent refléter cette action même si le bot ne l’a pas initiée.

Cette définition donne au système une question stable à laquelle répondre : que peut démontrer le compte concernant ses avoirs actuels ? La réponse peut inclure des écarts non résolus, plutôt que prétendre qu’un index de place de marché en retard et une observation récente de la propriété sont nécessairement cohérents.

Conserver les ordres dans leur propre registre

Un ordre décrit les conditions dans lesquelles une opération peut avoir lieu. Signer un ordre ne revient pas à réaliser l’échange d’actifs. La présentation de Seaport d’OpenSea introduit la distinction entre les objets proposés et la contrepartie exigée en retour pour les transactions EVM prises en charge.

Avec une offre d’achat, le compte peut créer une acquisition future possible sans recevoir immédiatement le NFT. Avec une annonce, le compte peut rester propriétaire tout en exprimant sa volonté de vendre. Les registres des stocks et des ordres ont donc besoin d’états distincts et d’un lien clair.

Le suivi des ordres de NFT signés doit préserver l’identité de l’ordre, la chaîne et le protocole concernés, les conditions, l’échéance et les preuves pertinentes de son état. Une étiquette locale comme publié doit décrire ce que l’application sait réellement, plutôt que laisser entendre que l’ordre restera exécutable jusqu’à son échéance nominale.

Le guide consacré à un bot OpenSea explique plus en détail les autorisations et les données de place de marché. Cette distinction compte ici, car lire un ordre, créer une signature et effectuer un transfert sont des capacités différentes. Un modèle de compte ne doit pas déduire l’une de la présence d’une autre.

Distinguer la capacité d’acquisition du solde du portefeuille

Le solde visible d’un portefeuille ne décrit pas tous les engagements potentiels. Plusieurs offres d’achat peuvent solliciter le même actif de paiement, tandis que des transactions en attente peuvent déjà utiliser des fonds que le dernier solde local n’a pas encore rapprochés. Une politique de trading a besoin de son propre calcul d’affectation.

Supposons que le compte fictif autorise une exposition de 2,5 ETH à une collection, mesurée par les coûts d’acquisition et les nouveaux achats réservés. Il détient trois objets acquis pour 0,3, 0,45 et 0,6 ETH, soit un total de 1,35 ETH. Deux achats possibles réservent chacun 0,4 ETH supplémentaires.

La politique comptabilise donc 2,15 ETH d’engagements, ce qui laisse 0,35 ETH. Une nouvelle proposition exigeant 0,38 ETH ne respecte pas cette capacité. Cette conclusion découle de la politique d’exposition choisie, même si le portefeuille dispose d’assez d’actifs liquides pour soumettre la transaction.

L’exemple est volontairement simple. Une autre politique pourrait utiliser des valeurs en scénario de crise ou des limites distinctes par objet et par collection. Quelle que soit la mesure choisie, énoncez-la explicitement et ne comptez chaque obligation économique qu’une seule fois. Un total inexpliqué est difficile à examiner lorsque les soldes, les offres et les avoirs changent ensemble.

Réserver les ressources avant que des tâches concurrentes puissent les dépenser

Deux parties du bot peuvent examiner la même capacité restante et conclure chacune qu’un achat respecte les limites. Si elles autorisent indépendamment leurs actions, celles-ci peuvent, ensemble, dépasser la limite. L’étape de réservation doit donc coordonner les décisions avant que l’une ou l’autre tâche crée un nouvel engagement.

Dans le compte fictif, deux propositions simultanées de 0,25 ETH chacune ne peuvent pas toutes deux utiliser la même enveloppe de 0,35 ETH. La première réservation acceptée laisse 0,10 ETH selon la politique. La seconde doit être réévaluée à partir de cet état actualisé.

Conservez le responsable et l’objet de la réservation. Elle doit renvoyer à une intention économique, telle que l’acquisition d’un objet précis, et rester reliée à l’ordre ou à la transaction finale. Une soustraction générique sans référence peut rester bloquée ou être libérée deux fois.

Il s’agit d’une exigence de cohérence du compte plutôt que d’une prédiction des conditions du marché. Même un modèle de sélection parfait peut créer une exposition indésirable si ses propositions partagent un budget sans coordination. Le registre des réservations rend ces interactions visibles avant l’arrivée des achats effectifs.

Suivre les offres qui se chevauchent sans les supposer exclusives

Un compte peut avoir des offres portant sur un objet, un attribut ou une collection dont les ensembles d’éligibilité se chevauchent. Le système doit comprendre quels objets pourraient satisfaire chaque offre et combien d’acquisitions restent possibles. Un thème commun ne rend pas mutuellement exclusives des obligations signées séparément.

Par exemple, une offre portant sur un objet précis et une offre générale sur une collection peuvent être actives simultanément. Le fait qu’un objet puisse satisfaire l’une ou l’autre n’établit pas qu’une seule acquisition puisse jamais avoir lieu sur l’ensemble de la collection. Un autre détenteur éligible peut accepter l’offre plus large.

Le modèle de stocks doit relier ces offres à leur quantité, à leur financement et aux règles de leur circuit d’exécution. Évitez de calculer l’exposition uniquement en comptant les noms de collections distincts ou les lignes d’ordres affichées. La question pertinente est de savoir ce que le compte pourrait acquérir si des ordres compatibles s’exécutent.

Les modifications d’une offre ne doivent pas en supprimer silencieusement une autre du registre. Si l’opérateur souhaite un remplacement, établissez comment l’ancienne instruction devient sans effet selon les règles applicables et préservez toute incertitude restante. Une étiquette de remplacement dans l’application ne réécrit pas l’état de la place de marché.

Distinguer les annonces des stocks disponibles

Un objet annoncé à la vente peut rester détenu tout en étant engagé dans une vente possible. Le bot peut aussi devoir empêcher une autre tâche interne de prévoir une action incompatible sur ce même objet. C’est une règle de coordination locale, distincte du registre de propriété de la chaîne.

Si un NFT est proposé à la vente par deux circuits compatibles, une vente sur l’un peut affecter la validité de l’autre. Le bot doit examiner et rapprocher les deux registres lorsque la propriété change. Il ne doit pas supposer que toutes les interfaces externes retirent instantanément les annonces obsolètes.

Une réacquisition ultérieure du même identifiant constitue une autre raison d’examiner les anciennes autorisations. La possibilité qu’un ordre antérieur redevienne pertinent dépend de ses conditions réelles et de son état d’invalidation. Considérer un objet comme définitivement à l’abri d’anciennes instructions au seul motif qu’il a quitté le portefeuille une fois est un raccourci sans fondement.

Une conception utile conserve une liste des engagements de vente actifs ou non résolus associés à chaque objet. Cette liste aide l’opérateur à comprendre ce qui peut encore se produire et ce qui doit être retiré lorsque le plan de trading change.

Interpréter l’annulation selon son mécanisme réel

L’annulation est une transition d’état qui nécessite des preuves. Une demande locale, une réponse de place de marché et une invalidation confirmée sur la chaîne peuvent fournir des garanties différentes. Le bot doit enregistrer le mécanisme appliqué et l’incertitude restante.

La référence d’OpenSea sur l’annulation des ordres hors chaîne précise notamment les limites de l’annulation lorsqu’une autorisation d’exécution a déjà été émise. C’est une raison d’examiner les règles actuelles du circuit plutôt que de déclarer que toute réponse positive de l’API met inconditionnellement fin à toute exécution possible.

Si une vente ou un achat se réalise pendant le processus d’annulation, les stocks doivent enregistrer ce résultat. L’intention de l’opérateur d’arrêter n’efface pas le transfert. Toute obligation non exécutée ou autrement restante doit ensuite être traitée selon la structure réelle de l’ordre.

Ne libérez les réservations locales que lorsque les preuves pertinentes justifient cette libération. Un retard temporaire dans la mise à disposition de la capacité est préférable au fait d’indiquer à une autre tâche que les fonds sont libres alors que l’obligation antérieure peut encore s’exécuter.

Donner leur propre état aux transactions en attente

Une transaction peut être soumise, observée en attente, incluse, avoir échoué ou être encore non résolue du point de vue de l’application. Ces étiquettes doivent suivre les preuves disponibles sur la chaîne et les règles de confirmation du compte plutôt qu’un délai choisi pour donner une apparence décisive à l’interface.

Le registre des opérations en attente conserve l’intention initiale, la référence de transaction, les actifs attendus et les ressources réservées. Si la réponse se perd, ce registre fournit le point de départ de la reprise. Un nouveau processus ne doit pas avoir à deviner quel achat le processus précédent a tenté.

Ne créez pas une seconde acquisition simplement parce que la première tentative n’a pas de résultat facilement accessible. Les comportements de remplacement et de nouvelle tentative doivent suivre les règles transactionnelles de la chaîne. Une nouvelle instruction économique diffère de la resoumission ou de l’examen d’une instruction existante.

Le guide d’un bot de NFT automatisé traite en détail de l’intervention de l’opérateur et des limites du fonctionnement sans surveillance. Pour les stocks, le point essentiel est que l’incertitude reste un état explicite du compte, avec une conséquence sur les ressources, jusqu’à sa résolution.

Actualiser les avoirs à partir des variations d’actifs vérifiées

Lorsqu’une transaction s’achève selon les règles de vérification choisies, reliez ses variations d’actifs réelles à l’opération prévue. Confirmez l’objet, la quantité, le destinataire et le paiement plutôt que de vous fier uniquement à un indicateur général de réussite.

Une transaction réussie qui réalise une autre action autorisée ne doit pas automatiquement créer l’avoir en NFT prévu dans le registre. Le système a besoin de preuves du transfert ou de la variation de solde spécifique. Cette distinction est particulièrement utile lorsqu’une transaction contient plusieurs opérations.

Des observations répétées du même transfert économique doivent renforcer ou actualiser les preuves sans dupliquer les stocks. Enregistrez une identité stable pour l’événement ou l’effet de transaction et suivez les règles de révision du protocole concerné. Le nombre de messages reçus n’est pas une quantité d’actifs.

Si l’objet attendu n’apparaît jamais, enregistrez l’écart. Ne fabriquez pas une ligne de stocks pour donner l’impression que la proposition est terminée. Le rapprochement vise à comparer l’intention à la réalité, y compris lorsqu’elles diffèrent.

Préserver les quantités des NFT à plusieurs unités

Tous les avoirs en NFT ne se décrivent pas correctement par un propriétaire et une unité unique. Certaines normes représentent plusieurs unités sous un identifiant de jeton. Le modèle de compte doit utiliser les bonnes règles de quantité avant de pouvoir calculer les stocks disponibles ou les ventes.

Supposons qu’une acquisition fictive porte sur cinq unités à 0,08 ETH chacune, avec un coût total supplémentaire de 0,01 ETH. Le coût total d’acquisition est de 0,41 ETH. Avec une simple répartition égale, chaque unité porte un coût de 0,082 ETH.

Si deux unités se vendent ensuite à 0,11 ETH chacune, le produit brut est de 0,22 ETH. Avec des frais de sortie totaux supposés de 0,006 ETH, le produit net est de 0,214 ETH. Le coût d’acquisition affecté à ces unités est de 0,164 ETH, ce qui laisse un gain réalisé de 0,05 ETH.

Trois unités restent avec un coût affecté de 0,246 ETH. Leur résultat futur n’est pas résolu. Le maintien de l’identifiant du jeton dans le portefeuille ne signifie pas que les cinq unités initiales y restent, et la vente partielle ne clôture pas toute la position.

Construire un registre des coûts d’acquisition des NFT

Un registre des coûts d’acquisition des NFT relie chaque avoir à la contrepartie effectivement payée et aux dépenses de transaction pertinentes. Les estimations peuvent étayer l’autorisation, mais les montants réels ont leur place dans le registre comptable final. Conservez les deux pour pouvoir expliquer les différences.

Les coûts peuvent être libellés dans différents actifs. Enregistrez la devise et le montant d’origine, puis utilisez une méthode explicite de conversion vers une unité de présentation commune. Une variation du prix de l’ETH en dollars ne doit pas modifier le nombre d’ETH enregistrés comme dépensés lors de l’achat initial.

Répartissez les coûts communs de façon cohérente lorsqu’une transaction acquiert plusieurs objets. Une répartition égale peut être compréhensible dans un exemple pédagogique, tandis qu’une autre méthode peut mieux répondre à un objectif comptable particulier. Énoncez la méthode plutôt que d’autoriser toute répartition produisant le rendement par objet le plus favorable.

Les paiements aux créateurs et les frais de place de marché demandent la même attention. S’ils sont déjà inclus dans la contrepartie totale ou le produit net, ne les déduisez pas à nouveau. Le registre doit décrire les mouvements réels de trésorerie plutôt qu’accumuler des étiquettes qui se chevauchent pour une même dépense.

Distinguer les transferts internes des achats et des ventes

Déplacer un NFT entre des comptes contrôlés par le même opérateur peut changer le lieu de détention sans créer de produit de vente. Un transfert vers le portefeuille surveillé peut aussi arriver sans preuves suffisantes pour établir son coût historique.

Enregistrez le mouvement et sa relation connue avec le compte. N’affectez pas un coût nul simplement parce qu’aucun paiement n’accompagnait le transfert observé. Le coût de revient inconnu doit rester inconnu jusqu’à ce que des justificatifs l’établissent, et tout rapport doit expliquer comment la valeur manquante affecte les totaux.

De même, un transfert sortant n’est pas automatiquement une vente profitable ou une perte. Il peut s’agir d’un transfert de garde, d’un don ou d’une autre opération. La classification doit suivre les preuves relatives à la contrepartie et à l’objectif plutôt que le seul sens du transfert du NFT.

Cela empêche les décomptes d’activité de déformer la performance. Un portefeuille actif peut générer de nombreux transferts tout en réalisant peu de véritables achats ou ventes. Les mouvements de stocks et le résultat économique ne sont reliés que lorsque le contexte transactionnel pertinent justifie ce lien.

Préserver l’historique lorsqu’un NFT est cédé puis réacquis

Le même identifiant de NFT peut passer plusieurs fois par le compte. Chaque acquisition a sa propre date, son coût et sa thèse de trading. Réutiliser une ligne en écrasant le coût antérieur effacerait le résultat de la première période de détention.

Créez un épisode de position distinct ou une autre structure historique claire. Une vente clôture la quantité concernée dans l’épisode antérieur ; un achat ultérieur en commence un nouveau. L’identité de l’objet reste la même tandis que son histoire économique gagne un nouveau chapitre.

Cela compte pour évaluer la durée de détention et la rotation d’une stratégie. Un simple indicateur de propriété actuelle ne peut révéler le capital engagé au fil de passages répétés ni indiquer si un achat ultérieur a coûté plus cher que la vente antérieure.

Conserver le registre antérieur aide aussi à examiner les anciens ordres. Un objet qui revient doit être vérifié au regard des autorisations non résolues, plutôt que traité comme un actif entièrement inconnu sans engagements antérieurs associés.

Rapprocher les données après les actions manuelles et les redémarrages

Un bot est rarement la seule source possible d’activité du compte. Le propriétaire peut utiliser une autre interface, transférer un objet ou accepter manuellement une offre. Le processus de stocks doit intégrer ces changements sans les traiter comme impossibles au motif qu’aucune proposition locale n’existe.

Après un redémarrage, chargez les ordres et transactions non résolus avant de créer une nouvelle exposition. Comparez la propriété actuelle et les soldes de paiement avec le dernier registre étayé. Toute différence doit être expliquée par une activité observée ou conservée comme écart explicite en attente d’examen.

Un redémarrage ne doit pas remettre à zéro les compteurs de dépenses ni supprimer les réservations en attente simplement parce qu’elles n’étaient stockées qu’en mémoire. Les obligations du compte survivent au processus applicatif. Des registres durables permettent au processus repris de poursuivre la même histoire économique.

Le guide des logiciels de trading de NFT traite la qualité comptable comme un critère de sélection. Un tableau de bord attrayant est moins utile s’il perd le lien entre les ordres ouverts, les avoirs réels et les coûts historiques chaque fois que l’application se reconnecte.

Un bot de trading ERC-1155 a besoin de registres des stocks et des engagements tenant compte des quantités, car plusieurs unités d’un identifiant de jeton changent le problème comptable.

Tester le bot de trading de NFT avec des preuves contradictoires

Un exercice d’examen utile comprend davantage qu’un achat sans incident suivi d’une vente sans incident. Soumettez au système une observation de transfert dupliquée, une mise à jour retardée de la place de marché, un transfert sortant manuel et une annulation qui chevauche une exécution. Définissez l’état attendu du compte avant de lancer l’exercice.

Pour l’exemple à cinq unités, une notification dupliquée doit toujours laisser cinq unités acquises. Une vente vérifiée de deux unités doit en laisser trois. Un message périmé ultérieur décrivant cinq unités ne doit pas écraser silencieusement l’état plus récent étayé sans examen de sa source et de son heure d’observation.

Testez les totaux de ressources aussi bien que les nombres d’objets. Un échec résolu peut libérer de la capacité d’achat tout en conservant une dépense réseau réelle. Un achat terminé déplace le montant économique de l’engagement en attente vers le coût de l’avoir plutôt que de compter les deux indéfiniment.

L’objectif est un récit cohérent du compte. Un lecteur doit pouvoir expliquer ce qui est détenu, ce qui peut encore s’exécuter et comment les coûts enregistrés sont apparus. Cette base rend les décisions de trading examinables même lorsque les données de marché et l’état de l’application arrivent à des moments différents.