Mergi pe Dexalot fără fricțiune — un SDK unificat, orientat spre asincron (async-first), care abstractizează complexitatea on-chain și oferă acces perfect, de nivel producție, la tranzacționare, swap-uri și administrarea portofoliului, într-un singur client.
April 10, 2026 |
Wenn Sie jemals versucht haben, einen Trading-Bot zu bauen oder sich in einen On-Chain-DEX einzubinden, wissen Sie, wie mühsam das ist. 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 konzentrieren können, was wirklich zählt: Ihre Trading-Logik.
Heute stellen wir es der Community als Open Source bereit — sowohl in Python als auch in TypeScript.
Dexalot ist eine dezentrale Börse, die ein zentrales Limit-Order-Book (CLOB) On-Chain betreibt. Im Gegensatz zu AMM-basierten DEXs, bei denen Sie gegen einen Liquiditätspool tauschen, matched Dexalot Käufer und Verkäufer so, wie es traditionelle Börsen tun — mit Bids, Asks und einem echten Order Book. Das bringt Tradern engere Spreads, mehr Kontrolle über die Ausführung und ein vertrautes Nutzererlebnis.
Doch die programmatische Interaktion mit einem On-Chain-CLOB war in der Vergangenheit oft schwierig. 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, musste im Grunde dieselbe technische Basis komplett neu aufsetzen.
Das Dexalot SDK bündelt all das in einem einzigen, sauberen Client. Einmal installieren. 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 Method-Calls. Das SDK übernimmt im Hintergrund das Signieren der On-Chain-Transaktion, das Nonce-Management und die Gas-Schätzung. Außerdem unterstützt es Batch-Operationen: Platzieren Sie mehrere Orders in einer einzigen Transaktion, stornieren Sie eine Liste auf einmal oder führen Sie ein atomisches Cancel-and-Replace durch, bei dem Ihre alten Orders entfernt und neue in einem Schritt eingereicht werden. Für Market Maker und aktive Trader bedeutet das weniger Round-Trips und geringere 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 „soft quote“, um die indikativen Preise zu prüfen, fixieren Sie dann eine verbindliche Quote mit einem 30-Sekunden-Expiry-Fenster und führen Sie den Swap aus — drei Schritte, ohne dass ein Order-Book-Management erforderlich ist. Das ist ideal für einzelne Trades oder Anwendungen, die eine einfache „Swap Token A gegen Token B“-Schnittstelle brauchen.
Portfolio und Transfers. Prüfen Sie Ihre Guthaben über Ihr Portfolio und verbundene Chain-Wallets hinweg. Deponieren Sie Tokens aus unterstützten Chains in Ihr Dexalot-Portfolio, ziehen Sie sie wieder zurück und verwalten Sie das Gas — alles programmgesteuert. Wenn Sie ein Dashboard, einen Portfolio-Tracker oder ein automatisiertes Rebalancing-System bauen, geben Ihnen diese Methoden alles, was Sie dafür benötigen.
Während DeFi reift, liegt die echte Chance dort, wo die Lücke zwischen „Ich kann auf einem DEX manuell traden“ und „Ich kann Produktionssysteme auf einem DEX bauen“ ist. Bots, Aggregatoren, Portfolio-Manager, Analytics-Plattformen — sie alle brauchen zuverlässigen programmatischen Zugriff. Genau das liefert dieses SDK.
Wir liefern native SDKs für Python und TypeScript — die beiden Sprachen, die die Krypto-Entwicklung dominieren. Python ist dort zu Hause, wo quantitative Trader, Data Scientists und Bot-Builder arbeiten. TypeScript treibt die Web-Frontends, Node.js-Services und serverless-Funktionen an, auf denen ein Großteil des Ökosystems läuft. Beide SDKs teilen die gleiche Design-Philosophie: async-first, integrierte Fehlerbehandlung, Typsicherheit und Defaults auf Produktionsniveau. Egal, ob du einen FastAPI-Trading-Service oder ein Next.js-Portfolio-Dashboard schreibst — du bekommst einen erstklassigen Client — nicht nur einen dünnen Wrapper um eine REST-API.
Wir haben nicht einfach ein paar API-Endpoints ummantelt und es dabei belassen. Das SDK wurde für Produktions-Workloads entwickelt, und ein paar der architektonischen Entscheidungen sind es wert, 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, keine blockierenden Calls, die irgendwo im Hintergrund versteckt sind. Das bedeutet, dass das SDK problemlos mit modernen Async-Frameworks zusammenspielt und parallele Operationen ohne Überraschungen bewältigt. Wenn du einen Trading-Service betreibst, der mehrere Paare überwacht und dabei Orders verwaltet, ist Async nicht optional — es ist essenziell.
Smartes Caching, das dich nicht ausbremst. Das SDK verwendet ein Caching-System mit vier Ebenen, das sich an die Art und Weise anpasst, wie Exchange-Daten tatsächlich funktionieren. Statische Daten wie Deployment-Konfigurationen werden für eine Stunde gecached, weil sie sich nahezu 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 jedes TTL an deinen Use Case anpassen — oder das Caching für die Entwicklung komplett ausschalten. Unter der Haube enthält der Cache einen Schutz gegen Stampede: Wenn zehn parallele Requests zur gleichen Zeit die gleichen nicht gecachten Daten anfordern, holt nur eine Anfrage die Daten wirklich. Der Rest wartet auf dieses eine Ergebnis. So wird das Problem des "thundering herd" verhindert, das APIs bei Cache-Misses stark belasten kann.
Automatische Retries und Rate Limiting. Netzwerkprobleme passieren. RPC-Provider gehen offline. Das SDK enthält konfigurierbare Retry-Logik mit exponentiellem Backoff — es gibt bei dem ersten Fehler nicht auf, aber es wird auch keinen angeschlagenen Endpoint mit Anfragen zuspammen. Auch Rate Limiting ist integriert, und zwar mit einem Token-Bucket-Ansatz, der dich innerhalb der serverseitigen Limits hält, ohne dass du darüber nachdenken musst.
RPC-Provider-Failover. Wenn dein primärer RPC-Endpoint anfängt zu scheitern, schaltet das SDK automatisch auf einen Backup um. Du kannst mehrere Provider pro Chain konfigurieren, Fehler-Schwellenwerte festlegen und Cooldown-Zeiten definieren. Wenn alle Provider ausfallen, greift 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 standardmäßig. Private Keys werden aus dem Konfigurationsobjekt sofort entfernt, nachdem das Wallet-Konto erstellt wurde. Das SDK verwirft nicht verschlüsselte HTTP-RPC-Endpoints, sofern du diesen Schutz nicht explizit überschreibst. Fehlermeldungen werden bereinigt, bevor sie deine Anwendung erreichen: Dabei werden Dateipfade, RPC-URLs und Stack Traces entfernt, die Infrastrukturdetails preisgeben könnten. Außerdem gibt es sogar einen verschlüsselten Secrets-Vault zum lokalen Speichern sensibler Werte — deine Keys werden im Ruhezustand mit Fernet-Verschlüsselung verschlüsselt, und nur die Key-Namen sind in der Vault-Datei sichtbar.
Eine Designentscheidung, die hervorgehoben werden sollte, ist, wie das SDK mit Fehlern umgeht. Anstatt bei erwarteten Fehlschlägen Ausnahmen auszulösen — ein Netzwerk-Timeout, eine abgelehnte Order, ein On-Chain-Revert — 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, befindet sich eine menschenlesbare Fehlermeldung in .error.
Das mag sich wie eine kleine Sache anhören, macht in der Praxis aber einen großen Unterschied. Fehlerbehandlung per Exceptions in asynchronem Code kann knifflig und schwer nachzuvollziehen 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 durch einen Netzwerk-„Blip“ ab — er sieht ein fehlgeschlagenes Result und macht dann das, was deine Logik dazu vorsieht.
Für Anwendungen, die Live-Marktdaten benötigen, enthält das SDK einen optionalen WebSocket-Manager. Abonniere Updates des Orderbooks für bestimmte Handelspaare und erhalte Events über asynchrone Callbacks. Die Verbindung übernimmt das automatische Reconnect, und die Callbacks lassen sich nahtlos in deine asynchrone Laufzeit integrieren — egal ob das asyncio in Python oder die Node.js-Event-Loop in TypeScript ist. Das ist besonders nützlich für Market-Making-Bots, die in Echtzeit auf Änderungen im Orderbook reagieren müssen.
Das Python-SDK ist auf PyPI verfügbar, das TypeScript-SDK auf npm. Installiere eines davon, setze ein paar Umgebungsvariablen, und schon liest du Orderbooks. Wenn du traden willst, füge deinen Signier-Schlüssel hinzu — entweder über die verschlüsselte Secrets-Vault oder indem du direkt ein Signer-Objekt übergibst (wir empfehlen Letzteres, damit dein Rohschlüssel niemals eine Config-Datei berührt).
Die Dokumentation enthält eine Anwenderanleitung mit Copy-Paste-Beispielen für jeden wichtigen Workflow, einen Architekturüberblick für Mitwirkende, die die internen Details verstehen möchten, sowie eine Caching-Anleitung zur Optimierung der Performance. Wenn du das Gesamtbild willst, starte dort. Wenn du direkt zum Code springen willst, deckt das Getting-Started-Tutorial das Setup bis hin zu deinem ersten Trade ab.
Das SDK ist keine eigenständige Insel. Es ist so konzipiert, sich in das breitere Tooling-Ökosystem einzufügen, das Entwickler ohnehin bereits nutzen. Die „async-first“-Architektur bedeutet, dass es sich sauber in Frameworks wie FastAPI und Express integriert. Die strukturierte JSON-Logging-Option gibt ein Event pro Zeile aus, inklusive Zeitstempeln und Metadaten-Feldern — bereit für Datadog, Loki, Grafana oder den Log-Aggregator, den euer Team betreibt. Die Konfiguration läuft über Umgebungsvariablen, .env-Dateien oder Konstruktorargumente, sodass es auf die gleiche Weise funktioniert, egal ob du lokal, in Docker oder auf Kubernetes ausführst.
Für Teams, die über mehrere Umgebungen hinweg 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 die Daten des jeweils anderen nicht „verunreinigen“. Wechsle zwischen Umgebungen, indem du genau einen Konfigurationswert änderst.
Diese Veröffentlichung deckt die Kern-Operationen fürs Trading, Swaps und das Portfolio ab. Wir arbeiten aktiv daran, das SDK auf Basis von Community-Feedback zu erweitern. Wenn es eine Funktion gibt, die du gerne sehen würdest, eröffne ein Issue im Repo — oder noch besser, öffne einen Pull Request.
Wir haben Dexalot gebaut, um die Performance und Präzision traditioneller Exchange-Infrastruktur in DeFi zu bringen. Die Python- und TypeScript-SDKs machen das für jeden Entwickler zugänglich — mit einem Terminal und einer Idee.
Beide, das Dexalot Python SDK und das TypeScript SDK, sind Open Source. Schau in die Repositories für die vollständige Dokumentation, Beispiele und Beitragshinweise.
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
Gutes Trading.
