Bot d’ordres à cours limité sur DEX : comprendre ce qui peut être exécuté

Identifier le mécanisme derrière l’appellation de l’ordre

Commencez par vous demander ce qui existe une fois que l’utilisateur a appuyé sur le bouton de soumission. Il peut s’agir d’un ordre signé hors chaîne, d’une transaction enregistrant un ordre sur la chaîne, d’une allocation placée sous séquestre ou d’une règle de surveillance locale. Le mécanisme réel détermine quel composant doit rester disponible et à quel niveau la validité est contrôlée.

Un ordre signé peut autoriser un échange ultérieur sans transférer immédiatement les actifs. Un déclencheur local peut rester une simple instruction visant à construire une transaction future. Un mécanisme de séquestre peut engager des actifs dans un contrat dont les règles de retrait et d’exécution doivent être examinées séparément.

Ne déduisez pas ces propriétés du mot « décentralisé ». Les éléments pertinents sont les conditions de l’ordre, le contrat de règlement, la garde des actifs, la découverte de l’ordre et les parties capables d’agir. Les différentes conceptions font des compromis différents sans relever d’un modèle universel de garde des actifs.

Le guide des ordres à cours limité sur les memecoins fournit des repères utiles sur les déclencheurs et l’expiration. Cet article se concentre sur une question supplémentaire : quelles conditions doivent rester réunies pour qu’un ordre DEX en cours puisse être exécuté ?

Définir la protection du prix d’un bot d’ordres à cours limité sur DEX

La protection du prix d’un bot d’ordres à cours limité sur DEX doit être décrite comme une limite imposée à l’échange autorisé, en précisant sa portée exacte. Un vendeur pourrait exiger au moins douze unités de cotation pour chaque jeton échangé. Un acheteur pourrait autoriser au maximum huit unités de cotation par jeton acquis.

Cette limite ne promet pas que l’opération aboutira. Lorsque personne ne peut ou ne veut respecter les conditions, la position ou le budget non dépensé subsiste. Il s’agit d’un compromis délibéré entre un prix acceptable et la certitude d’exécution, et pas nécessairement d’un dysfonctionnement.

Distinguez aussi le ratio d’échange du résultat complet pour le compte. Les frais de réseau, les coûts de service applicables et les comportements inhabituels de transfert de jetons peuvent ne pas être pris en compte dans un simple prix affiché. L’utilisateur doit savoir si le minimum indiqué porte sur les montants du contrat ou sur les actifs effectivement reçus.

Une évaluation doit examiner ce que vérifie le mécanisme de règlement plutôt que de considérer l’intitulé de l’interface comme une preuve. Une cible surveillée combinée à une tolérance de swap choisie indépendamment peut produire une limite économique différente de la cible que l’utilisateur garde en mémoire.

Exprimer l’échange en quantités de jetons sans ambiguïté

Chaque ordre nécessite des identifiants exacts de réseau et d’actifs, un sens, des montants et des destinataires. Les symboles sont des étiquettes pratiques, mais des noms identiques ou des actifs présentés de façon similaire peuvent transformer un prix apparemment correct en autorisation d’effectuer le mauvais échange.

Exprimez l’échange dans des unités lisibles par un humain tout en préservant les montants entiers sous-jacents et l’interprétation des décimales. Vendre 250 unités d’un jeton contre au moins 3 000 unités de cotation implique douze unités de cotation par jeton. Inverser ce ratio produit un nombre différent, exprimé dans une unité différente.

Pour un ordre d’achat, déterminez si l’utilisateur fixe le montant à dépenser, la quantité qu’il souhaite acquérir ou les deux au moyen d’un ratio. Un prix maximal ne détermine pas à lui seul le budget total. L’ordre a toujours besoin d’un plafond de quantité et d’un traitement clair des coûts.

Le guide du marché Uniswap sur Base explique pourquoi l’identité de la chaîne, de l’actif et du pool compte. Un processus d’ordre à cours limité conserve ces identifiants au-delà de la découverte, jusque dans l’autorisation qui peut rester utilisable après la fermeture de l’écran initial.

Distinguer un déclencheur de la limite imposée au règlement

Prenons une application fictive qui surveille un jeton à dix unités de cotation. Elle a pour instruction de vendre lorsqu’une observation atteint douze. Dès que cette condition se réalise, l’application demande une cotation de swap et prépare une transaction.

Si la transaction qui en résulte permet un échange effectif à moins de douze, alors douze était un déclencheur, et non le minimum de vente imposé à l’exécution. Ce comportement peut être intentionnel, mais l’utilisateur doit voir les deux paramètres avant de l’autoriser.

À l’inverse, un ordre dont les conditions imposent au moins douze peut rester inexécuté après que le graphique a montré des échanges au-dessus de douze ailleurs. Le lieu de négociation observé, la taille de l’ordre, les coûts d’acheminement et l’occasion d’exécution peuvent différer des conditions précises en attente de règlement.

Un test utile examine le scénario défavorable : le déclencheur s’active, puis le prix exécutable change avant la soumission. Le bot doit soit préserver la limite autorisée, soit demander une décision selon les règles définies. Assouplir discrètement la limite pour obtenir une opération achevée modifie l’instruction économique de l’utilisateur.

Un processus de trading sur MegaETH ajoute une autre distinction temporelle : il faut toujours distinguer les preuves d’exécution rapide et la préconfirmation du séquenceur du règlement ultérieur sur Ethereum.

Pour un déclencheur mobile, la configuration d’un stop suiveur sur DEX ajoute un plus haut de référence persistant tout en préservant la distinction entre le signal et un montant acceptable qu’une exécution peut effectivement procurer.

Comprendre le financement sans supposer que les actifs sont bloqués

Certains modèles d’ordres signés laissent les actifs dans le portefeuille de l’émetteur de l’ordre jusqu’à l’exécution. Dans ce cas, le titulaire du compte peut créer d’autres obligations qui sollicitent le même solde. Un ordre visible ne prouve pas à lui seul que la totalité de son montant reste disponible.

D’autres mécanismes placent les actifs sous séquestre ou réservent des ressources au moyen de leur propre comptabilité. Le bot doit suivre le fonctionnement réel, notamment ce qui permet de retirer les fonds et si les mêmes avoirs peuvent servir à une autre opération.

Utilisez un registre interne des engagements même lorsque le mécanisme sous-jacent permet d’engager plus que les avoirs disponibles. Si un compte détient 500 jetons et que deux ordres exécutables indépendamment en proposent chacun 400, l’interface doit expliquer qu’ils ne peuvent pas tous deux être exécutés intégralement selon leurs conditions sans avoirs supplémentaires.

Ne comptez pas sur une insuffisance temporaire de fonds comme méthode d’annulation durable. Si l’autorisation signée reste valide, réapprovisionner le compte ultérieurement peut rétablir la possibilité d’exécuter l’ordre. Le financement, l’autorisation et l’annulation sont des états distincts qui nécessitent des enregistrements distincts.

Traiter séparément l’autorisation de dépense et l’autorisation de l’ordre

Dans un processus ERC-20, une autorisation de dépense de jetons correspond à la permission donnée par un propriétaire à un tiers précis de transférer ces jetons. La spécification ERC-20 définit le modèle d’autorisation de dépense sous-jacent. Un ordre peut ajouter des conditions signées concernant les montants, les destinataires et la validité.

L’existence d’une autorisation de dépense ne prouve pas qu’un ordre particulier est actuellement valide. De même, annuler un ordre ne supprime pas nécessairement toutes les permissions relatives aux jetons accordées à son infrastructure de règlement. L’utilisateur doit comprendre ces deux relations.

Vérifiez l’adresse qui doit être autorisée à dépenser les jetons, la chaîne et le jeton avant de donner l’autorisation. Un nom de marque familier sur un écran ne remplace pas la vérification de la portée réelle de la permission. Le destinataire de l’ordre mérite la même attention que son prix.

Les modifications de permissions peuvent affecter d’autres activités légitimes utilisant le même compte. Un bot doit décrire les conséquences d’une révocation ou d’un remplacement plutôt que de traiter toutes les permissions comme de simples paramètres d’arrière-plan que l’on peut supprimer sans conséquence. L’objectif est une chaîne d’autorisations vérifiable, où chaque permission est reliée à l’opération qui en a besoin.

Suivre un cycle de vie fictif avec des exécutions partielles

Supposons un mécanisme hypothétique qui prend explicitement en charge des exécutions partielles répétées. Un compte propose 1 000 Example Tokens contre au moins trois unités de cotation chacun. La quantité initialement mise en vente est de 1 000 et la contrepartie brute minimale initiale est de 3 000 unités de cotation.

Une première exécution achevée échange 400 jetons contre 1 220 unités de cotation. Son prix moyen est de 3,05. La quantité restant à vendre passe à 600 jetons. Une deuxième exécution échange 250 jetons supplémentaires contre 775 unités de cotation, soit une moyenne de 3,10.

La quantité exécutée est désormais de 650, la contrepartie brute de 1 995 et la quantité non exécutée de 350. La moyenne cumulée des exécutions est d’environ 3,0692 unités de cotation par jeton. Cette moyenne décrit la partie exécutée ; elle ne valorise pas les avoirs restants au même prix.

Ces chiffres illustrent les exécutions partielles d’un bot d’ordres à cours limité sur DEX uniquement pour un mécanisme qui prend ce comportement en charge. Un swap atomique unique et un ordre persistant partiellement exécutable sont des modèles différents. Le bot ne doit pas inventer un reliquat encore actif lorsque l’opération sous-jacente a soit été exécutée intégralement, soit été annulée par réversion.

Maintenir la cohérence entre exécution partielle et comptabilité

Poursuivons l’exemple fictif avec un coût d’acquisition tout compris de deux unités de cotation par jeton. Selon cette convention simplifiée de coût unitaire, les 650 jetons vendus se voient attribuer un coût de 1 300 unités. Supposons vingt unités de cotation supplémentaires de coûts imputables aux ventes réalisées.

Le produit net réalisé s’élève à 1 975, soit un gain réalisé de 675. Les 350 jetons restants conservent un coût d’acquisition de 700 unités. Leur valeur future et le résultat de leur vente éventuelle restent inconnus.

Un tableau de bord qui applique le prix moyen des exécutions aux 1 000 jetons surestimerait ce qui a été vendu. Un tableau de bord qui ignore la détention restante ferait disparaître un actif ayant une importance économique. Ces deux erreurs viennent du fait de réduire l’état de l’ordre à un seul pourcentage d’exécution.

Enregistrez l’identifiant de chaque exécution, les mouvements de jetons et le traitement des coûts, puis rapprochez le total avec le compte. Le guide d’exécution Pancakeswap aborde l’interprétation des itinéraires et des cotations, ce qui aide aussi à expliquer pourquoi une proposition affichée et le produit effectivement reçu dans le portefeuille peuvent différer.

Examiner pourquoi un prix atteint peut ne donner lieu à aucune exécution

Un prix sur un graphique peut refléter une petite transaction, un autre pool ou un actif de cotation différent. Il peut établir qu’un échange a eu lieu à un niveau affiché sans établir que l’intégralité de l’ordre de l’utilisateur pouvait y être exécutée.

Dans un système reposant sur des acteurs externes chargés d’exécuter les ordres, quelqu’un doit trouver l’ordre et avoir un intérêt économique à le régler selon les règles du protocole. Les coûts, les occasions concurrentes et les itinéraires disponibles peuvent compter même lorsque le ratio d’échange affiché paraît favorable.

Considérez cela comme une explication propre à un mécanisme, et non comme l’affirmation que tous les DEX utilisent le même modèle d’acteurs d’exécution. Un carnet d’ordres natif ou un swap soumis par une application présente des contraintes différentes de découverte et d’exécution.

Mesurez ce qui est utile : à quelle fréquence un ordre valide et financé a-t-il bénéficié d’une possibilité d’exécution réalisable pour sa taille réelle ? Compter chaque contact du graphique avec le prix comme une exécution garantie manquée produit des statistiques de performance trompeuses et peut inciter les utilisateurs à assouplir leurs contraintes pour une mauvaise raison.

Intégrer l’expiration à la décision économique

L’échange acceptable défini par un ordre peut devenir obsolète lorsque la situation de l’utilisateur change. L’expiration limite la durée pendant laquelle cette autorisation est censée rester utilisable. Elle doit faire partie de la décision initiale, plutôt que d’être un champ obscur hérité d’un paramètre par défaut.

Vérifiez comment le mécanisme évalue l’échéance. Un minuteur local, une condition de validité sur la chaîne et l’heure à laquelle un service cesse de rendre l’ordre repérable ne sont pas interchangeables. La question pertinente est de savoir à quel moment une tentative de règlement ne peut plus satisfaire les conditions réelles de l’ordre.

Un bot doit distinguer un ordre dont l’expiration est confirmée d’un écran qui a cessé de l’afficher. Conservez l’échéance initiale, la convention horaire et le statut final observé afin que l’utilisateur puisse expliquer pourquoi une exécution ultérieure a eu lieu ou non.

Le renouvellement est une nouvelle décision économique. Recréer automatiquement un ordre expiré indéfiniment annule l’intérêt d’une limite de durée, sauf si cette règle de renouvellement a été explicitement choisie. Vérifiez à nouveau la quantité restante, le financement actuel et le maintien de l’intention avant d’autoriser une nouvelle période de validité.

Gérer la concurrence entre annulation et exécution sur un bot d’ordres à cours limité sur DEX

L’annulation d’un ordre par un bot d’ordres à cours limité sur DEX exige des preuves que l’autorisation restante ne peut plus être exécutée selon ses règles. Appuyer sur Annuler ou recevoir un accusé de réception de la soumission peut entamer ce processus sans l’achever.

Reprenons l’ordre fictif dont 350 jetons restent à vendre. Pendant qu’une annulation est en attente, une autre exécution valide échange 100 jetons contre 305 unités de cotation. Une fois cette exécution et l’annulation résolues, 750 jetons ont été vendus et 250 restent invendus.

La quantité annulée est donc de 250 dans ce scénario, et non de 350 comme affiché au début de l’annulation. Indiquer le nombre le plus élevé effacerait une exécution réelle et rendrait les registres des avoirs incohérents avec le compte.

Les différents mécanismes utilisent des méthodes d’annulation différentes. Certains nécessitent une invalidation sur la chaîne, tandis qu’une règle purement locale qui n’a pas été transmise peut être désactivée dans l’application. Le système doit expliquer quel cas s’applique et ne doit pas considérer la suppression d’une ligne locale comme une annulation universelle de conditions signées précédemment diffusées.

Remplacer un ordre sans doubler l’engagement

Modifier le prix souhaité peut nécessiter d’annuler ou d’invalider l’ancienne autorisation et d’en créer une nouvelle. Lorsque le remplacement n’est pas atomique, les deux versions peuvent temporairement rester exécutables. Ce chevauchement doit être pris en compte dans le calcul des avoirs et du financement.

Supposons que le propriétaire veuille remplacer une vente de 300 jetons à quatre unités de cotation par une vente des mêmes 300 jetons à 3,80. Publier le remplacement avant d’avoir résolu l’ordre initial peut créer deux engagements de vente distincts plutôt qu’un seul ordre mis à jour.

Le traitement correct dépend des règles réelles de remplacement et d’invalidation du mécanisme. Le bot doit conserver les liens entre versions et savoir si les anciennes conditions peuvent encore produire un effet avant de libérer la quantité qui leur est réservée.

Les modifications de prix doivent également préserver la limite de coût voulue par l’utilisateur. Si l’écran affiche un résultat net estimé, modifier uniquement un ratio d’échange brut peut ne pas permettre d’obtenir ce montant net après les coûts applicables. Recalculez l’aperçu et rendez l’autorisation modifiée compréhensible.

Traduire un objectif net en conditions compatibles

Supposons qu’un autre vendeur fictif souhaite obtenir au moins 120 unités de cotation après avoir vendu dix jetons et payé un coût fixe supposé de deux unités de cotation. Avec ces hypothèses simplifiées, la vente doit produire au moins 122 unités de cotation brutes, soit 12,20 par jeton. Une limite brute de douze ne satisferait pas l’objectif net annoncé.

Les coûts réels peuvent varier, et une exécution partielle peut modifier la répartition d’un coût fixe sur la quantité exécutée. L’aperçu doit préciser ses hypothèses au lieu de présenter un prix converti comme une garantie permanente du produit net.

Les incréments de prix peuvent introduire un autre problème de conversion. Si un mécanisme n’accepte que des prix au centième d’unité, un minimum calculé de 12,347 pour un vendeur ne peut pas être représenté exactement. Arrondir à 12,34 assouplit ce minimum, tandis que 12,35 préserve une limite plus stricte. Pour le maximum d’un acheteur, le problème se pose dans le sens inverse.

Utilisez les règles réelles de montant et de précision du mécanisme, qui peuvent exprimer un ratio plutôt qu’un pas de cotation conventionnel. Le principe essentiel est que le formatage et l’arrondi ne doivent pas autoriser silencieusement un échange en dehors de la limite fixée par l’utilisateur. Si les conditions demandées ne peuvent pas être représentées, expliquez les conditions ajustées avant de créer l’ordre.

Mesurer les ordres inexécutés dans le cadre de la stratégie

Une évaluation qui ne rapporte que les ordres exécutés peut masquer les effets de sélection de la stratégie. Des limites apparemment favorables peuvent être exécutées dans des conditions défavorables tandis que d’autres propositions restent intactes. L’échantillon des seules exécutions ne permet pas d’établir ce que l’ensemble du processus de décision a accompli.

Conservez les ordres inexécutés et expirés dans le dossier de recherche, avec leur intention initiale. Pour une vente, conserver l’actif peut entraîner des gains ou des pertes ultérieurs. Pour un achat, laisser les fonds non dépensés peut préserver le capital ou faire manquer une occasion. Ces résultats font partie de la comparaison des stratégies, même en l’absence de frais de transaction.

Comparez les options en utilisant les mêmes moments de décision et les mêmes éléments disponibles. Un échange de type ordre au marché, un ordre persistant assorti de limites et l’absence d’action exposent le compte à des trajectoires différentes. N’attribuez pas à l’ordre à cours limité inexécuté une exécution favorable hypothétique simplement parce qu’un graphique ultérieur semble franchir son prix.

Le taux d’exécution devient ainsi une mesure descriptive plutôt qu’un objectif à maximiser à tout prix. Un faible taux d’exécution peut révéler des conditions inadaptées, mais assouplir ces conditions modifie la stratégie et nécessite une évaluation distincte.

Expliquer ce qui persiste lorsque l’interface est fermée

Un dispositif de surveillance local peut nécessiter un processus en cours d’exécution pour observer son déclencheur et construire une transaction. Un ordre signé déjà diffusé peut suivre un cycle de vie différent, car d’autres participants peuvent en conserver une copie et tenter de le régler selon ses règles de validité.

Fermer un navigateur, déconnecter l’affichage d’un portefeuille ou arrêter un bot ne doit donc pas être automatiquement décrit comme l’annulation de tous les ordres en cours. L’utilisateur doit savoir quelles autorisations persistent et quelles tâches de surveillance s’arrêtent.

La reprise doit reconstruire l’ensemble des ordres en cours à partir d’enregistrements persistants et de preuves de règlement appropriées. L’absence de cache local ne remet pas les compteurs à zéro si des conditions signées antérieures restent utilisables. Rapprochez les quantités exécutées avant de reconstituer l’engagement restant.

Le même principe s’applique lors d’une migration entre interfaces. Exportez suffisamment d’informations pour identifier les ordres et leurs états finaux, puis vérifiez les autorisations non résolues au moyen du mécanisme pertinent. Une nouvelle interface ne doit pas supposer que l’ancienne a emporté ses obligations économiques avec elle en disparaissant.

Évaluer la conception à l’aide de cas défavorables

Une évaluation utile comprend un ordre valide inexécuté, un financement insuffisant, une permission modifiée, une expiration, une exécution partielle et une concurrence entre annulation et exécution. Ces cas en révèlent davantage sur la conception qu’une seule transaction réussie à un prix favorable.

Testez les calculs avec des enregistrements fictifs avant d’engager des fonds importants. L’enregistrement doit préserver le lien entre la quantité initiale, la quantité exécutée et le reliquat résolu. Les coûts ne doivent apparaître qu’une fois, et les moyennes affichées doivent s’appliquer uniquement à la quantité qu’elles décrivent réellement.

Testez aussi un jeton ou un itinéraire que le mécanisme ne prend pas en charge. Le résultat approprié peut être un rejet clair. Un bot qui tente de traiter tous les actifs selon les mêmes hypothèses peut se comporter de façon moins utile qu’un bot qui explique son périmètre plus restreint.

Un bot d’ordres à cours limité sur DEX inspire confiance en préservant les conditions d’échange de l’utilisateur et en expliquant chaque obligation non résolue. La limite de prix est une composante de ce travail. Le financement, la validité, l’exécution partielle et l’annulation déterminent si cette limite garde son sens tout au long de la vie de l’ordre.