Algorithme de trading sur Solana : suivre une règle de bout en bout

Un exemple d’algorithme de trading sur Solana doit avoir un objectif

L’objectif de R1 est de produire une proposition de réduction partielle qui puisse être examinée, pour une position déjà gérée par le processus. Elle ne découvre pas de nouveaux jetons, ne déduit pas les intentions du trader et ne sélectionne pas un portefeuille complet. Ce périmètre restreint permet de concentrer l’exemple sur la relation entre les observations et un seul type d’action.

L’algorithme utilise une adresse de mint fixe pour le jeton et une interprétation du marché prise en charge. Il observe des cotations pour la vente d’exactement 100 jetons contre un actif de cotation désigné. Chaque comparaison porte sur le même sens d’opération et la même quantité. Une cotation pour l’achat de 100 jetons ou la vente d’une quantité différente n’est pas intégrée à la référence comme si elle était équivalente.

Le précédent guide de l’architecture d’un bot de trading sur Solana distingue observation, stratégie, autorisation et rapprochement. R1 respecte ces frontières. Le déclenchement d’une règle constitue une décision proposée, tandis que le résultat sur le compte nécessite des éléments issus des étapes suivantes.

Définir le contenu du paquet d’observation

Chaque paquet d’observation contient l’identité du mint, l’actif de cotation, la quantité en entrée, le montant attendu en sortie, l’heure de l’observation, le périmètre de la source ou de l’itinéraire, ainsi que le statut de l’interprétation. Il précise aussi quels coûts sont déjà pris en compte dans le montant de sortie. Le paquet doit être enregistré avant de servir de donnée d’entrée à la règle.

Pour R1, le montant de sortie correspond à une cotation de vente pour une quantité précise, et non à un prix général du jeton. La comparaison est ainsi plus étroitement liée à la quantité que l’on souhaite céder, tout en laissant subsister une incertitude d’exécution. Une cotation atteste des conditions à un instant donné ; elle ne garantit pas un résultat ultérieur sur le compte.

L’heure à laquelle le paquet est devenu disponible doit être clairement établie. Une cotation récupérée dans l’historique après l’heure limite de décision ne peut pas être intégrée à une relecture comme si elle avait été connue plus tôt. La piste de preuves de cet algorithme commence par ce que le système pouvait effectivement examiner au moment où la règle s’est exécutée.

Définir une fenêtre de référence entièrement constituée

R1 compare la dernière cotation admissible à la moyenne des montants de sortie de trois observations antérieures achevées, sélectionnées selon un calendrier fixe. Ce calendrier et la politique de fraîcheur font partie de la version de la règle. Ils ne sont pas choisis après coup pour rendre la référence favorable.

Les trois observations de référence doivent toutes respecter les mêmes exigences d’identité, de quantité, de sens d’opération et de prise en charge. Si l’une d’elles manque ou n’est pas valide, R1 s’abstient dans cet exemple. Elle ne raccourcit pas discrètement la référence et ne remplace pas la valeur manquante par la dernière cotation.

Un algorithme plus complexe pourrait utiliser un autre calcul, mais sa spécification devrait être tout aussi claire. Il ne s’agit pas de prétendre que trois observations constituent un modèle prédictif solide. Un calcul simple et fixe permet plutôt d’examiner facilement le périmètre des données d’entrée et de montrer comment les données manquantes modifient la décision.

Fixer la cadence d’examen de l’exemple

Pour cette spécification détaillée, imaginons des examens programmés toutes les cinq minutes. Un examen à 10:00 utilise comme référence les paquets de cotation enregistrés à 09:45, 09:50 et 09:55, ainsi qu’une dernière cotation distincte pour l’examen en cours. Chaque paquet doit avoir respecté une limite de fraîcheur d’une minute lors de son acceptation à l’heure de son propre examen ; le dernier paquet doit encore respecter cette limite au moment de la décision actuelle.

Ces intervalles sont des paramètres illustratifs, et non des fréquences de trading recommandées. Ils rendent l’exemple reproductible et empêchent l’implémentation de sélectionner les trois observations historiques qui produisent une référence commode. Si un paquet programmé n’était pas disponible, la règle de R1 concernant les données manquantes s’applique, plutôt que de remonter plus loin dans le passé sans changement explicite de version.

Énoncer le déclencheur en langage courant

R1 propose une réduction lorsque le dernier montant de sortie admissible dépasse d’au moins 5 % la moyenne des trois montants de sortie de référence. Ce seuil est choisi uniquement à titre d’illustration. Une égalité au seuil satisfait la règle, et le calcul utilise les valeurs enregistrées non arrondies avant leur mise en forme pour l’affichage.

La condition décrit une variation relative du produit de vente coté pour une même quantité de 100 jetons. Elle n’affirme pas que toute la position peut être vendue à ce taux implicite ni que l’évolution ultérieure du prix est prévisible. Ce seraient d’autres questions, nécessitant d’autres éléments probants.

Le guide des signaux de trading sur Solana explique pourquoi une détection ou une prévision ne constitue pas automatiquement un avantage économique. Le déclencheur de R1 est simplement une correspondance définie entre un événement et une proposition. Son utilité nécessiterait une évaluation distincte des résultats, des coûts et du comportement alternatif qu’il remplace.

Calculer le déclencheur à la main

Supposons que les montants de sortie fictifs de référence soient de cinquante, cinquante-deux et cinquante et une unités de cotation. Leur moyenne est de cinquante et un. Le dernier montant de sortie est de cinquante-quatre. La hausse relative est de trois divisé par cinquante et un, soit environ 5,88 % : la condition numérique de déclenchement est donc satisfaite au regard du seuil de 5 % de R1.

Le calcul doit être enregistré avec les identifiants des données d’entrée. Une personne chargée de l’examen peut alors le reproduire sans avoir besoin de consulter la page actuelle du marché. Si une donnée est corrigée ultérieurement, conservez la décision d’origine et indiquez en quoi le calcul corrigé diffère, plutôt que de réécrire discrètement le résultat antérieur.

Cette opération arithmétique ne prouve pas que la vente proposée est avantageuse. Elle établit uniquement que les observations enregistrées satisfont au déclencheur spécifié. Les étapes suivantes vérifient que la position existe, que la quantité est disponible, que la cotation reste actuelle et que l’action respecte la politique du compte.

L’examen d’une règle de trading sur Solana inclut l’admissibilité

R1 ne s’applique qu’à une position gérée disposant d’au moins 300 jetons disponibles avant la réduction proposée de 100 jetons. L’exemple laisse donc au moins 200 jetons après une réduction réussie. Cette règle de quantité est illustrative et relève de la définition de la stratégie ; elle ne constitue pas une recommandation universelle de dimensionnement.

La règle exige aussi une interprétation du jeton et du marché prise en charge, une référence complète, une dernière observation récente et l’absence d’intention de réduction non résolue réservant les mêmes avoirs. Si l’une des exigences n’est pas respectée, le résultat indique le motif de l’abstention au lieu de renvoyer un score nul trompeur.

L’examen des règles d’un algorithme de trading sur Solana doit vérifier ces exigences avant d’inspecter le calcul du seuil. Un résultat mathématiquement correct de 5,88 % ne compense ni un mauvais mint, ni des éléments périmés, ni des avoirs indisponibles. L’admissibilité détermine si le calcul a un sens pour l’action envisagée.

Limiter la proposition au périmètre de l’autorisation

Lorsque R1 se déclenche, elle crée une proposition de réduction de la position de 100 jetons. La proposition comprend la version de la règle, les références des éléments probants, la quantité, le contexte de cotation actuel et l’échéance d’expiration. Elle ne signe ni ne soumet elle-même de transaction.

Une étape distincte d’autorisation vérifie la politique du compte et son état actuel. Le compte peut rejeter la proposition parce qu’une autre action a réservé les avoirs, que les droits nécessaires ne sont pas disponibles ou que l’itinéraire proposé sort du périmètre autorisé. Ce rejet constitue un résultat valide même lorsque la règle d’observation de R1 était satisfaite.

Le guide des systèmes de trading sur Solana explique l’attribution durable de la responsabilité de ces enregistrements. Distinguer proposition et autorisation permet à la personne chargée de l’examen de différencier une abstention de la stratégie d’un rejet par le compte. Ces résultats appellent des améliorations différentes et ne doivent pas être regroupés dans un décompte générique d’absences d’opération.

Revérifier la cotation avant une tentative

La cotation ayant déclenché R1 peut expirer avant que l’action soit prête à être soumise. Le processus doit obtenir des éléments actuels et appliquer une politique explicite en cas de changement significatif. Un ancien déclenchement n’établit pas que le montant de sortie initialement observé reste disponible.

Si la nouvelle cotation ne respecte plus les conditions de la proposition, l’action peut être rejetée ou renvoyée pour réévaluation. La politique doit préciser si la condition de déclenchement initiale doit toujours être satisfaite ou si une limite d’exécution autorisée séparément régit la tentative. L’exemple ne laisse pas ce choix à une décision improvisée d’un composant d’exécution.

Conservez séparément la cotation déclencheuse et la cotation d’exécution ultérieure. Leur écart fournit des éléments utiles sur le délai et la faisabilité. Remplacer la cotation d’origine par la suivante rendrait plus difficile l’explication de la raison pour laquelle l’algorithme s’est initialement déclenché.

Réserver les avoirs nécessaires à la réduction autorisée

Supposons que le compte dispose de 500 jetons disponibles lorsque la proposition de 100 jetons est autorisée. Le processus réserve la quantité proposée afin qu’une autre règle de sortie ne puisse pas supposer indépendamment que les 500 jetons restent tous disponibles. Si l’action aboutit comme prévu, il reste 400 jetons, avant prise en compte de tout changement indépendant sur le compte.

La réservation persiste tant que la tentative reste non résolue, conformément à la politique de rapprochement. Elle peut être levée lorsqu’une proposition non soumise expire ou lorsque des éléments étayés établissent un résultat permettant cette levée. L’ordonnanceur ne doit pas la lever simplement parce qu’un nouvel intervalle commence.

Le précédent guide de coordination du take-profit et du stop-loss sur Solana traite des conditions de sortie concurrentes. R1 est une source possible de proposition de réduction. Son implémentation doit coopérer avec toutes les autres sources par l’intermédiaire de l’enregistrement partagé de la position, plutôt que de gérer les avoirs de manière isolée.

Enregistrer la soumission comme une tentative

Le composant d’exécution enregistre l’intention autorisée et la tentative de transaction qui en résulte. Il conserve l’identité et les informations temporelles nécessaires au suivi du résultat. Une réponse de soumission réussie ne constitue pas à elle seule une vente ayant fait l’objet d’un rapprochement ; la documentation sendTransaction de Solana explicite cette distinction. Documentation de soumission de Solana.

Si la réponse est incertaine, le processus doit examiner la tentative existante. Il ne doit pas relancer R1 et créer une nouvelle intention de vente simplement parce que la demande précédente n’a pas renvoyé un statut final commode. La proposition d’origine et les avoirs qu’elle réserve font toujours partie de l’état du compte.

Cette séparation améliore aussi la recherche. Une proposition déclenchée, une proposition autorisée et une réduction achevée correspondent à des décomptes distincts. La faisabilité opérationnelle de l’algorithme ne peut être évaluée que si l’enregistrement conserve les transitions et les raisons pour lesquelles certaines propositions ne deviennent jamais des changements sur le compte.

Rapprocher la position une fois le résultat établi

Une fois le résultat de la transaction établi selon la politique choisie, comparez l’effet sur le compte à l’intention. Enregistrez la quantité cédée, le produit de vente, les coûts et les avoirs gérés restants. Si le résultat diffère des attentes, conservez l’écart et résolvez-le avant que des actions dépendantes ne supposent l’état entièrement régularisé.

La position ne doit pas être marquée comme entièrement clôturée après une réduction de 100 jetons sur 500. Elle reste ouverte avec la quantité rapprochée. Un statut de tentative achevée et un statut de position clôturée décrivent des objets différents et doivent rester distincts dans l’interface et dans l’export.

La position restante influe aussi sur la prochaine évaluation de R1. La règle doit utiliser les avoirs actuellement disponibles, en tenant compte des autres réservations et des changements externes. Recopier la quantité initiale de 500 jetons dans chaque proposition future enfreindrait précisément la condition d’admissibilité établie par la spécification.

Définir quand la règle peut se déclencher de nouveau

Sans politique de réarmement, R1 pourrait émettre une nouvelle réduction chaque fois qu’elle observe la même condition persistante. Déterminez si l’algorithme autorise des réductions répétées, attend que la condition cesse d’être remplie ou exige un nouvel épisode de référence avant qu’une autre proposition puisse être ouverte.

Dans cette spécification illustrative, un épisode de déclenchement ne peut avoir qu’une seule intention de réduction ouverte. Une fois l’intention résolue, R1 exige un nouvel examen complet et à jour dont le dernier montant de sortie ne dépasse pas de plus de 2 % sa référence admissible avant qu’un autre épisode puisse commencer. Cette réinitialisation met fin à l’ancienne condition ; un examen ultérieur doit de nouveau atteindre le seuil d’ouverture de 5 % pour créer un nouvel épisode. Les exigences relatives aux avoirs et aux droits d’action continuent de s’appliquer indépendamment.

Cela empêche les observations répétées de devenir des empilements accidentels d’intentions de sortie. Cela définit aussi l’unité de recherche : un épisode possède une condition d’ouverture, un résultat de proposition et une clôture ou une réinitialisation. Le nombre de notifications et le nombre d’observations peuvent alors être distingués du nombre de décisions effectives de l’algorithme.

Tester le cas d’une référence incomplète

Supprimez l’observation centrale de la référence tout en maintenant le dernier montant de sortie à cinquante-quatre. Selon R1, le résultat attendu est l’abstention, car la référence requise de trois observations est incomplète. Le système ne doit pas calculer la moyenne de cinquante et de cinquante et un puis prétendre que la règle d’origine a quand même été exécutée.

L’enregistrement doit désigner la donnée d’entrée manquante et conserver la dernière observation valide pour des recherches ultérieures. Une fois l’observation manquante arrivée, le système peut reconstituer le calcul antérieur, mais il s’agit d’un résultat rétrospectif. Celui-ci ne devient pas un signal qui était disponible en temps réel au moment de la décision initiale.

Ce cas teste le périmètre des informations plutôt que l’arithmétique. Un programme peut calculer correctement une moyenne tout en enfreignant la règle en utilisant un jeu de données incomplet ou arrivé tardivement. Une validation pertinente vérifie l’admissibilité des données d’entrée avant de vérifier le résultat numérique.

Tester une cotation périmée et des avoirs modifiés

Conservez ensuite une référence complète, mais faites en sorte que la dernière cotation dépasse la limite de fraîcheur de R1. Le résultat attendu est l’abstention ou l’expiration de la proposition, selon l’étape. Un écran nouvellement affiché ne doit pas remettre à zéro l’âge de la cotation sous-jacente.

Rétablissez ensuite une cotation récente tout en réduisant les avoirs disponibles à moins de 300 par un changement externe contrôlé. La condition numérique de déclenchement peut toujours être satisfaite, mais la position n’est plus admissible. L’enregistrement doit identifier la condition de quantité plutôt que de prétendre que le signal a disparu parce que le marché a changé.

Ces cas montrent pourquoi les règles d’observation et l’état du compte doivent rester liés. Un même paquet de données de marché peut conduire à des résultats autorisés différents lorsque les avoirs ou les droits d’action changent. Ce n’est pas une incohérence ; c’est le comportement prévu d’un processus algorithmique complet assorti de prérequis explicites.

Comparer R1 à une alternative définie

Pour évaluer l’utilité de R1, choisissez un comportement de référence reposant sur les mêmes hypothèses de compte, d’observation et de coûts. L’alternative pourrait être une réduction fixe programmée ou l’absence de réduction jusqu’à un examen ultérieur annoncé à l’avance. Ce choix doit correspondre à la question de recherche et éviter le biais rétrospectif.

Le guide des algorithmes de trading sur Solana développe les comparaisons équitables entre règles. R1 ne doit pas bénéficier de cotations plus favorables, d’un budget plus important ou d’un horizon de sortie différent de l’alternative, sauf si cette différence fait explicitement partie de l’étude.

La comparaison doit inclure les réductions proposées mais non exécutées, les avoirs restants et les coûts. Examiner uniquement les réductions achevées peut masquer les cas où la règle s’est déclenchée mais où l’action était irréalisable. Une trajectoire complète du compte est plus instructive qu’un ensemble d’exemples de réussite isolés.

Figer la règle avant un examen ultérieur

La spécification finale de R1 comprend son univers, la quantité cotée, la sélection de la référence, le seuil, l’admissibilité, l’expiration, le réarmement, le passage à l’autorisation et la comptabilisation du résultat. Figez cette définition complète avant d’examiner une période d’évaluation ultérieure. Modifier un seul prérequis caché peut changer sensiblement le résultat.

Le précédent guide du processus de recherche sur Solana explique pourquoi les heures limites et les règles fixes comptent. Si la période ultérieure révèle un défaut ou un résultat peu attrayant, documentez la révision sous le nom R2 et précisez quels éléments ont servi à la choisir.

Une règle révisée après l’examen d’une fenêtre d’évaluation ne doit pas continuer à prétendre que cette même fenêtre a validé indépendamment la version révisée. L’enregistrement peut néanmoins constituer un élément précieux pour le développement. Une gestion honnête des versions préserve les enseignements de la recherche sans donner l’impression que la règle finale avait été sélectionnée à l’avance.

Décomposer l’examen du résultat

Vérifiez si R1 a reçu des éléments complets, calculé correctement le déclencheur, produit la proposition prévue, obtenu l’autorisation, atteint un résultat de tentative établi et rapproché la position. Un échec à chaque étape a une signification différente. Une formule correcte n’établit pas la justesse de l’ensemble du processus.

Évaluez ensuite séparément la question économique : qu’a changé la réduction par rapport à l’alternative définie, après coûts et pour une même trajectoire du compte ? La réponse peut être favorable, défavorable ou non concluante. Le caractère interprétable de l’algorithme ne garantit pas sa valeur.

Un rapport utile peut donc indiquer que l’implémentation respectait la spécification alors que la stratégie n’a pas atteint son objectif de recherche. Il peut aussi identifier un défaut opérationnel avant toute affirmation économique. Distinguer ces conclusions oriente les améliorations vers l’étape effectivement mise en cause par les éléments probants.

Conserver un exemple complet pour les modifications futures

Conservez la séquence de cotations de cinquante, cinquante-deux, cinquante et un et cinquante-quatre utilisée dans l’exemple, avec son calcul attendu de 5,88 % et les cas d’admissibilité associés. Ajoutez les enregistrements de proposition, d’autorisation, de tentative et de rapprochement issus d’une exécution contrôlée. Cela crée une référence compacte pour les modifications ultérieures de l’implémentation.

Cette référence doit inclure les résultats sans action aussi bien que le parcours réussi. Les versions futures peuvent être vérifiées au regard des différences souhaitées, tout en préservant les frontières qui doivent rester stables. Un examen de non-régression est surtout utile lorsqu’il vérifie un comportement significatif plutôt que de simplement reproduire la dernière implémentation.

Un algorithme de trading sur Solana peut être examiné lorsque toute sa chaîne est explicite. Une règle simple suffit à illustrer cette rigueur : les éléments observés alimentent un calcul fixe, l’admissibilité en limite l’usage, les droits d’action encadrent l’opération et le rapprochement du compte en établit la conséquence. La même clarté reste précieuse lorsque l’algorithme final est plus complexe.