Créez sur Dexalot sans les frictions — un SDK unifié, axé sur l’asynchrone en priorité, qui abstrait la complexité on-chain et offre un accès fluide, prêt pour la production, au trading, aux swaps et à la gestion de portefeuille dans un seul client.
April 10, 2026 |
Si vous avez déjà essayé de construire un bot de trading ou d'intégrer une bourse décentralisée on-chain, vous connaissez la difficulté. Vous jonglez avec des points de terminaison RPC, vous gérez des nonces, vous signez des transactions, vous analysez des carnets d'ordres, vous gérez des tentatives — et tout cela avant même de passer votre premier ordre. Nous avons développé le SDK Dexalot pour alléger ce poids afin que vous puissiez vous concentrer sur l'essentiel : votre logique de trading.
Aujourd'hui, nous le mettons en open-source pour la communauté — en Python et en TypeScript.
Dexalot est une bourse décentralisée qui exécute sur la blockchain un carnet d'ordres à cours limite centralisé (CLOB). Contrairement aux DEX basées sur des AMM où vous échangez contre un pool de liquidité, Dexalot fait correspondre acheteurs et vendeurs comme le font les bourses traditionnelles — avec des offres (bids), des demandes (asks) et un vrai carnet d'ordres. Cela offre aux traders des spreads plus serrés, davantage de contrôle sur l'exécution et une expérience familière.
Mais interagir avec un programme CLOB on-chain de manière programmatique a historiquement été laborieux. Vous devez vous authentifier, gérer les nonces du portefeuille pour éviter les transactions dupliquées, gérer les pannes des fournisseurs RPC et suivre les particularités propres à chaque blockchain. Chaque développeur qui voulait construire sur Dexalot devait essentiellement reconstruire la même plomberie depuis zéro.
Le SDK Dexalot regroupe tout cela dans un client unique et propre. Une installation. Un objet. Un accès complet au trading, aux swaps, aux soldes et aux données de marché en temps réel.
Le SDK couvre trois domaines clés du protocole Dexalot, tous accessibles via un client unifié.
Trading via carnet d'ordres. Passez des ordres à cours limite, annulez-les individuellement ou en lot, et consultez vos positions ouvertes — le tout via des appels de méthode simples. Le SDK gère la signature des transactions on-chain, la gestion des nonces et l'estimation du gas en coulisses. Il prend également en charge des opérations par lot : passer plusieurs ordres dans une seule transaction, annuler une liste en une fois, ou effectuer un annuler-et-remplacer atomique où vos anciens ordres sont supprimés et de nouveaux soumis en une seule opération. Pour les teneurs de marché et les traders actifs, cela signifie moins d'aller-retour et une latence plus faible.
Swaps simples. Tous les trades n'ont pas besoin d'un ordre à cours limite. Le SDK inclut un flux de swap de type demande de cotation (RFQ) : obtenir une cotation indicative pour vérifier le prix, verrouiller une cotation ferme avec une fenêtre d'expiration de 30 secondes, puis exécuter — trois étapes, sans gestion du carnet d'ordres requise. C'est idéal pour les trades ponctuels ou les applications qui ont besoin d'une interface simple "échanger le token A contre le token B".
Portefeuille et transferts. Consultez vos soldes sur l'ensemble de votre portefeuille et les portefeuilles de chaîne connectés. Déposez des tokens depuis des chaînes prises en charge dans votre portefeuille Dexalot, retirez-les ensuite, et gérez le gas — le tout de manière programmatique. Si vous construisez un tableau de bord, un suivi de portefeuille ou un système automatisé de rééquilibrage, ces méthodes vous donnent tout ce dont vous avez besoin.
À mesure que la DeFi mûrit, l'écart entre "je peux trader sur un DEX manuellement" et "je peux construire des systèmes de production sur un DEX" est là où se trouve la vraie opportunité. Les bots, les agrégateurs, les gestionnaires de portefeuille, les plateformes d'analytics — ils ont tous besoin d'un accès programmatique fiable. C'est exactement ce que fournit ce SDK.
Nous mettons à disposition des SDK natifs pour Python et TypeScript — les deux langages qui dominent le développement crypto. Python est là où vivent les traders quantitatifs, les data scientists et les créateurs de bots. TypeScript alimente les frontends web, les services Node.js et les fonctions serverless sur lesquelles une grande partie de l’écosystème repose. Les deux SDK partagent la même philosophie de conception : async en premier, gestion d’erreurs intégrée, sécurité de type et paramètres par défaut prêts pour la production. Que vous écriviez un service de trading FastAPI ou un tableau de bord de portefeuille Next.js, vous obtenez un client de premier ordre — pas un simple wrapper léger autour d’une API REST.
Nous ne nous sommes pas contentés d’envelopper quelques endpoints d’API et d’en rester là. Le SDK a été conçu en pensant aux charges de travail en production, et certaines décisions d’architecture méritent d’être mises en avant.
Async dès le départ. Chaque opération d’E/S est asynchrone. Le SDK Python est construit sur asyncio ; le SDK TypeScript utilise l’async/await natif et les Promises. Il n’y a pas de threads, ni d’appels bloquants cachés sous le capot. Cela signifie que le SDK s’intègre parfaitement aux frameworks asynchrones modernes et peut gérer des opérations concurrentes sans surprise. Si vous exécutez un service de trading qui surveille plusieurs paires tout en gérant des ordres, l’asynchronisme n’est pas optionnel — il est essentiel.
Un cache intelligent qui ne vous gêne pas. Le SDK utilise un système de cache en quatre niveaux qui correspond à la manière dont les données d’une bourse se comportent réellement. Les données statiques comme les configurations de déploiement sont mises en cache pendant une heure car elles changent presque jamais. Les métadonnées des tokens et des paires de trading se rafraîchissent toutes les 15 minutes. Les données de solde durent 10 secondes. Les instantanés du carnet d’ordres expirent après seulement une seconde. Chaque niveau a des valeurs par défaut judicieuses, mais vous pouvez ajuster chaque TTL pour correspondre à votre cas d’usage — ou désactiver le cache complètement pendant le développement. En interne, le cache inclut une protection contre le “stampede” : si dix requêtes concurrentes demandent les mêmes données non mises en cache au même moment, une seule les récupère réellement. Le reste attend ce résultat unique. Cela évite le problème du « thundering herd » qui peut mettre à mal les API lors des cache misses.
Reprises automatiques et limitation de débit. Des accrocs réseau arrivent. Les fournisseurs RPC tombent en panne. Le SDK inclut une logique de retry configurable avec un backoff exponentiel — il ne lâche pas dès le premier échec, mais il ne va pas non plus spammer un endpoint en difficulté. La limitation de débit est intégrée aussi, via une approche de type token-bucket qui vous maintient dans les limites côté serveur sans que vous ayez à y penser.
Basculement des fournisseurs RPC. Si votre endpoint RPC principal commence à échouer, le SDK bascule automatiquement vers un secours. Vous pouvez configurer plusieurs fournisseurs par chaîne, définir des seuils d’échec et des périodes de refroidissement. Si tous les fournisseurs tombent, il revient au dernier fournisseur fonctionnel connu. Pour les systèmes de production, ce type de résilience n’est pas un « bonus » — c’est une exigence.
Sécurité par défaut. Les clés privées sont effacées de l’objet de configuration immédiatement après la création du compte wallet. Le SDK rejette les endpoints HTTP RPC non chiffrés, sauf si vous remplacez explicitement cette protection. Les messages d’erreur sont assainis avant d’atteindre votre application, en supprimant les chemins de fichiers, les URL RPC et les traces de pile qui pourraient révéler des détails d’infrastructure. Il existe même un coffre-fort chiffré de secrets pour stocker localement les valeurs sensibles — vos clés sont chiffrées au repos à l’aide du chiffrement Fernet, et seuls les noms de clés sont visibles dans le fichier du coffre.
Un choix de conception qui mérite d'être mis en avant est la façon dont le SDK gère les erreurs. Au lieu de lever des exceptions pour des échecs attendus — un timeout réseau, une commande refusée, un revert sur la blockchain — chaque opération renvoie un objet Result. Vous vérifiez .success, et si c'est le cas, vos données se trouvent dans .data. Si c'est faux, un message d'erreur lisible par un humain est dans .error.
Cela peut sembler être un détail, mais en pratique, cela fait une grande différence. La gestion des erreurs basée sur les exceptions dans du code asynchrone peut être délicate et difficile à comprendre. Le motif Result rend les échecs explicites et prévisibles. Votre bot de trading ne plantera pas à 3 h du matin à cause d'une exception non gérée provenant d'un petit incident réseau — il verra un résultat en échec et appliquera la logique que vous avez définie pour traiter ce cas.
Pour les applications qui ont besoin de données de marché en direct, le SDK inclut un gestionnaire WebSocket optionnel. Abonnez-vous aux mises à jour du carnet d'ordres pour des paires de trading spécifiques et recevez des événements via des rappels asynchrones. La connexion gère automatiquement la reconnexion, et les rappels s'intègrent naturellement à votre environnement d'exécution asynchrone — que ce soit asyncio en Python ou la boucle d'événements Node.js en TypeScript. C'est particulièrement utile pour les bots de market-making qui doivent réagir aux changements du carnet d'ordres en temps réel.
Le SDK Python est disponible sur PyPI et le SDK TypeScript sur npm. Installez l'un ou l'autre, définissez quelques variables d'environnement, et vous êtes en train de lire des carnets d'ordres. Si vous voulez trader, ajoutez votre clé de signature — soit via le coffre-fort de secrets chiffrés, soit en passant directement un objet de signataire (nous recommandons la seconde option pour que votre clé brute ne touche jamais un fichier de configuration).
La documentation inclut un guide utilisateur avec des exemples à copier-coller pour chaque workflow majeur, une vue d'ensemble de l'architecture pour les contributeurs qui veulent comprendre les mécanismes internes, et un guide de mise en cache pour optimiser les performances. Si vous voulez avoir la vue d'ensemble complète, commencez par là. Si vous voulez passer directement au code, le tutoriel de démarrage couvre la configuration jusqu'à votre première transaction.
Le SDK n'est pas une île autonome. Il est conçu pour s'intégrer à l'écosystème d'outillage plus large dans lequel les développeurs travaillent déjà. L'architecture pensée d'abord pour l'asynchrone signifie qu'elle s'intègre proprement à des frameworks comme FastAPI et Express. L'option de journalisation JSON structurée produit un événement par ligne avec des horodatages et des champs de métadonnées — prêt pour Datadog, Loki, Grafana, ou tout autre agrégateur de logs que votre équipe utilise. La configuration passe par des variables d'environnement, des fichiers .env, ou des arguments du constructeur, de sorte que le comportement est le même que vous exécutiez localement, dans Docker ou sur Kubernetes.
Pour les équipes qui opèrent sur plusieurs environnements, le SDK gère simultanément testnet et mainnet dans le même processus. Les espaces de noms du cache sont séparés par endpoint, de sorte qu'un client testnet et un client mainnet ne contamineront pas les données de l'autre. Passez d'un environnement à l'autre en modifiant une seule valeur de configuration.
Cette version couvre les opérations principales de trading, de swap et de portefeuille. Nous travaillons activement à l'extension du SDK à partir des retours de la communauté. S'il y a une fonctionnalité que vous aimeriez voir, ouvrez un ticket sur le dépôt — ou encore mieux, ouvrez une pull request.
Nous avons construit Dexalot pour apporter les performances et la précision de l'infrastructure d'échange traditionnelle à DeFi. Les SDK Python et TypeScript sont la façon dont nous rendons cela accessible à chaque développeur avec un terminal et une idée.
Les SDK Python Dexalot et le SDK TypeScript sont open source. Consultez les dépôts pour la documentation complète, des exemples et des consignes de contribution.
Python SDK | GitHub : github.com/Dexalot/dexalot-sdk-python
Python SDK | PyPi : pypi.org/project/dexalot-sdk
TypeScript SDK | GitHub : github.com/Dexalot/dexalot-sdk-typescript
TypeScript SDK | NPM : npmjs.com/package/@dexalot/dexalot-sdk
Bon trading.
