Baue auf Dexalot auf – ohne Reibung: ein einheitliches, Async-First SDK, das On-Chain-Komplexität abstrahiert und nahtlosen, produktionsreifen Zugriff auf Trading, Swaps und Portfoliomanagement in einem einzigen Client liefert.
April 10, 2026 |
Wenn Sie schon einmal versucht haben, einen Trading-Bot zu bauen oder sich in einen On-Chain-Exchange einzuklinken, kennen Sie den Schmerz. Sie jonglieren mit RPC-Endpunkten, verwalten Nonces, signieren Transaktionen, parsen Order Books, kümmern sich um Retries — und das, bevor Sie überhaupt Ihre erste Order platzieren. Wir haben das Dexalot SDK gebaut, um Ihnen diese Last abzunehmen, damit Sie sich auf das Wesentliche konzentrieren können: Ihre Trading-Logik.
Heute stellen wir es der Community als Open Source zur Verfügung — sowohl in Python als auch in TypeScript.
Dexalot ist ein dezentraler Exchange, der ein zentrales Limit-Order-Book (CLOB) On-Chain betreibt. Im Gegensatz zu AMM-basierten DEXs, bei denen Sie gegen einen Liquidity Pool traden, matcht Dexalot Käufer und Verkäufer so, wie es traditionelle Exchanges tun — mit Bids, Asks und einem echten Order Book. Das sorgt für engere Spreads, mehr Kontrolle über die Ausführung und ein vertrautes Nutzererlebnis.
Doch die Interaktion mit einem On-Chain-CLOB programmgesteuert war in der Vergangenheit oft holprig. Sie müssen sich authentifizieren, Wallet-Nonces verwalten, um doppelte Transaktionen zu vermeiden, Ausfälle von RPC-Providern handhaben und mit blockchain-spezifischen Eigenheiten Schritt halten. Jeder Entwickler, der auf Dexalot aufbauen wollte, hat im Grunde dieselbe Infrastruktur immer wieder von Grund auf neu aufgebaut.
Das Dexalot SDK bündelt all das in einen einzigen, sauberen Client. Eine Installation. Ein Objekt. Voller Zugriff auf Trading, Swaps, Guthaben und Echtzeit-Marktdaten.
Das SDK deckt drei zentrale Bereiche des Dexalot-Protokolls ab, die alle über einen einheitlichen Client zugänglich sind.
Order-Book-Trading. Platzieren Sie Limit-Orders, stornieren Sie sie einzeln oder im Bulk, und fragen Sie Ihre offenen Positionen ab — alles über unkomplizierte Methodenaufrufe. Das SDK übernimmt im Hintergrund das Signieren der On-Chain-Transaktionen, das Nonce-Management und die Gas-Schätzung. Es unterstützt außerdem Batch-Operationen: mehrere Orders in einer einzigen Transaktion platzieren, eine Liste auf einmal stornieren oder einen atomaren Cancel-and-Replace durchführen, bei dem Ihre alten Orders entfernt und die neuen in einem Rutsch eingereicht werden. Für Market Maker und aktive Trader bedeutet das weniger Rundfahrten und niedrigere Latenz.
Simple Swaps. Nicht jeder Trade braucht eine Limit-Order. Das SDK enthält einen Request-for-Quote (RFQ)-Swap-Flow: Holen Sie sich eine unverbindliche Preisangabe, um die indikative Preisbildung zu prüfen, fixieren Sie dann ein verbindliches Quote mit einem 30-Sekunden-Expiry-Fenster und führen Sie es aus — drei Schritte, ohne Order-Book-Management. Das ist ideal für Einmal-Transaktionen oder Anwendungen, die eine einfache „Swap Token A für Token B“-Schnittstelle benötigen.
Portfolio und Transfers. Prüfen Sie Ihre Guthaben über Ihr Portfolio und die verbundenen Chain-Wallets hinweg. Hinterlegen Sie Tokens aus unterstützten Chains in Ihrem Dexalot-Portfolio, ziehen Sie sie wieder zurück und verwalten Sie Gas — alles programmgesteuert. Wenn Sie ein Dashboard, einen Portfolio-Tracker oder ein automatisiertes Rebalancing-System bauen, liefern diese Methoden alles, was Sie brauchen.
Während DeFi reift, liegt die echte Chance genau dort, wo die Lücke zwischen „Ich kann auf einem DEX manuell traden“ und „Ich kann auf einem DEX Produktionssysteme bauen“ aufreißt. Bots, Aggregatoren, Portfolio-Manager, Analytics-Plattformen — sie alle brauchen zuverlässigen programmatischen Zugriff. Genau das bietet dieses SDK.
Wir liefern native SDKs für Python und TypeScript — die beiden Sprachen, die die Krypto-Entwicklung dominieren. Python ist der Ort, an dem quantitative Trader, Data Scientists und Bot-Builder arbeiten. TypeScript treibt die Web-Frontends, Node.js-Services und serverless-Funktionen an, auf denen ein großer Teil des Ökosystems läuft. Beide SDKs teilen dieselbe Design-Philosophie: async-first, integrierte Fehlerbehandlung, Typsicherheit und produktionsreife Defaults. Egal, ob du einen FastAPI-Trading-Service schreibst oder ein Next.js-Portfolio-Dashboard — du erhältst einen erstklassigen Client — keine dünne Hülle um eine REST-API.
Wir haben nicht einfach ein paar API-Endpunkte umschlossen und es dabei belassen. Das SDK wurde mit Blick auf Produktions-Workloads entwickelt, und einige der architektonischen Entscheidungen verdienen es, hervorgehoben zu werden.
Async von Anfang an. Jede I/O-Operation ist asynchron. Das Python-SDK basiert auf asyncio; das TypeScript-SDK nutzt natives async/await und Promises. Es gibt keine Threads und keine blockierenden Calls, die im Hintergrund versteckt sind. Das bedeutet, dass das SDK hervorragend mit modernen Async-Frameworks zusammenspielt und parallele Operationen ohne Überraschungen abwickeln kann. Wenn du einen Trading-Service betreibst, der mehrere Paare überwacht und dabei Orders verwaltet, ist Async nicht optional — es ist entscheidend.
Intelligentes Caching, das dich nicht ausbremst. Das SDK verwendet ein Caching-System mit vier Ebenen, das dazu passt, wie sich Exchange-Daten in der Praxis verhalten. Statische Daten wie Deployment-Konfigurationen werden für eine Stunde gecached, weil sie sich praktisch nie ändern. Token- und Trading-Pair-Metadaten werden alle 15 Minuten aktualisiert. Balancedaten leben 10 Sekunden. Schnappschüsse des Orderbooks laufen nach nur einer Sekunde ab. Jede Ebene hat sinnvolle Defaults, aber du kannst jede TTL so anpassen, dass sie zu deinem Use Case passt — oder das Caching für die Entwicklung komplett ausschalten. Unter der Haube enthält der Cache Schutz vor „Stampede“: Wenn zehn parallele Requests zur selben Zeit nach demselben ungespeicherten Datensatz fragen, holt nur einer die Daten tatsächlich. Die anderen warten auf genau dieses eine Ergebnis. Das verhindert das Problem des „thundering herd“, das APIs bei Cache-Misses stark belasten kann.
Automatische Retries und Ratenbegrenzung. Netzwerkprobleme kommen vor. RPC-Provider gehen offline. Das SDK enthält konfigurierbare Retry-Logik mit exponentiellem Backoff — es gibt bei der ersten Panne nicht auf, aber es spamt auch keinen angeschlagenen Endpunkt. Auch die Ratenbegrenzung ist integriert, mit einem Token-Bucket-Ansatz, der dich innerhalb der serverseitigen Limits hält, ohne dass du darüber nachdenken musst.
Failover für RPC-Provider. Wenn dein primärer RPC-Endpunkt zu scheitern beginnt, wechselt das SDK automatisch zu einem Backup. Du kannst mehrere Provider pro Chain konfigurieren, Fehler-Schwellen festlegen und Cooldown-Zeiten definieren. Wenn alle Provider ausfallen, fällt es auf den zuletzt bekannten funktionierenden zurück. Für Produktionssysteme ist diese Art von Resilienz kein nice-to-have — sie ist eine Anforderung.
Sicherheit per Default. Private Keys werden aus dem Konfigurationsobjekt unmittelbar gelöscht, nachdem das Wallet-Konto erstellt wurde. Das SDK weist unverschlüsselte HTTP-RPC-Endpunkte zurück, außer du überschreibst diesen Schutz explizit. Fehlermeldungen werden bereinigt, bevor sie deine Anwendung erreichen: Dateipfade, RPC-URLs und Stack-Traces werden entfernt, die Infrastrukturdaten offenlegen könnten. Es gibt sogar einen verschlüsselten Secrets-Vault für das Speichern sensibler Werte lokal — deine Keys sind im Ruhezustand verschlüsselt, und zwar mit Fernet-Verschlüsselung, und nur die Key-Namen sind in der Vault-Datei sichtbar.
Eine Designentscheidung, die eine besondere Erwähnung verdient, ist, wie das SDK mit Fehlern umgeht. Anstatt bei erwarteten Fehlschlägen — einem Netzwerk-Timeout, einer abgelehnten Order, einem on-chain Revert — Exceptions auszulösen, gibt jede Operation ein Result-Objekt zurück. Du prüfst .success, und wenn es 'true' ist, sind deine Daten in .data. Wenn es 'false' ist, steckt eine menschenlesbare Fehlermeldung in .error.
Das mag wie eine kleine Sache klingen, aber in der Praxis macht es einen großen Unterschied. Ausnahmebasierte Fehlerbehandlung in asynchronem Code kann knifflig und schwer nachvollziehbar sein. Das Result-Muster macht Fehlschläge explizit und vorhersehbar. Dein Trading-Bot stürzt nicht um 3 Uhr morgens wegen einer nicht behandelten Exception aus einem Netzwerk-Glitch ab — er sieht ein fehlgeschlagenes Result und macht dann das, was deine Logik für diesen Fall vorsieht.
Für Anwendungen, die Live-Marktdaten benötigen, enthält das SDK einen optionalen WebSocket-Manager. Abonniere Order-Book-Updates für bestimmte Handelspaare und erhalte Events über asynchrone Callbacks. Die Verbindung behandelt Reconnects automatisch, und Callbacks integrieren sich auf natürliche Weise in deine asynchrone Laufzeit — ganz egal, ob das asyncio in Python ist oder die Node.js-Event-Loop in TypeScript. Das ist besonders nützlich für Market-Making-Bots, die in Echtzeit auf Änderungen im Order Book reagieren müssen.
Das Python-SDK ist auf PyPI verfügbar und das TypeScript-SDK auf npm. Installiere eines davon, setze ein paar Umgebungsvariablen, und du liest Order Books. Wenn du handeln willst, füge deinen Signing-Key hinzu — entweder über die verschlüsselte Secrets-Vault oder indem du direkt ein Signer-Objekt übergibst (wir empfehlen Letzteres, damit dein roher Key nie eine Konfigurationsdatei berührt).
Die Dokumentation enthält eine User-Guide mit Copy-Paste-Beispielen für jeden wichtigen Workflow, einen Architekturüberblick für Contributor, die die Interna verstehen möchten, sowie eine Caching-Anleitung zur Optimierung der Performance. Wenn du das Gesamtbild willst, fang dort an. Wenn du direkt zu Code springen willst, deckt das Tutorial zum Einstieg das Setup bis zu deinem ersten Trade ab.
Das SDK ist keine eigenständige Insel. Es ist so konzipiert, dass es sich in das breitere Tooling-Ökosystem einfügt, das Entwickler ohnehin schon nutzen. Die async-first-Architektur sorgt dafür, dass es sich sauber in Frameworks wie FastAPI und Express integrieren lässt. Die Option für strukturiertes JSON-Logging gibt pro Zeile ein Event mit Zeitstempeln und Metadatenfeldern aus — bereit für Datadog, Loki, Grafana oder welchen Log-Aggregator dein Team auch betreibt. Die Konfiguration läuft über Umgebungsvariablen, .env-Dateien oder Konstruktor-Argumente, sodass es auf die gleiche Weise funktioniert, egal ob du lokal, in Docker oder auf Kubernetes ausführst.
Für Teams, die in mehreren Umgebungen arbeiten, behandelt das SDK Testnet und Mainnet gleichzeitig innerhalb desselben Prozesses. Cache-Namespaces werden nach Endpoint getrennt, sodass ein Testnet-Client und ein Mainnet-Client sich gegenseitig nicht mit ihren Daten verunreinigen. Der Wechsel zwischen Umgebungen erfolgt durch das Ändern eines einzigen Konfigurationswerts.
Dieser Release umfasst die Kern-Operations für Trading, Swap und Portfolio. Wir arbeiten aktiv daran, das SDK auf Basis von Community-Feedback zu erweitern. Wenn es eine Funktion gibt, die du sehen möchtest, öffne ein Issue im Repo — oder noch besser: öffne einen Pull Request.
Wir haben Dexalot gebaut, um die Performance und Präzision klassischer Exchange-Infrastruktur zu DeFi zu bringen. Das Python- und TypeScript-SDK sind der Weg, wie wir das für jede:n Entwickler:in mit einem Terminal und einer Idee zugänglich machen.
Beide, das Dexalot Python SDK und das TypeScript SDK, sind Open Source. Schau in die Repositories für die vollständige Dokumentation, Beispiele und Contribution-Guidelines.
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
Viel Spaß beim Handeln.
