Trading-Bots haben einen schlechten Ruf – zu Recht, denn die meisten sind entweder Scams oder funktionieren in der Praxis nicht. Trotzdem habe ich mir einen gebaut. Nicht weil ich glaube, den Markt systematisch schlagen zu können, sondern weil es ein außergewöhnlich lehrreiches Projekt ist: API-Design, Fehlerbehandlung, Datenbankmodellierung und Risikomanagement in einem.
Was dabei entstanden ist: Ein schlanker Python-Bot, der auf der Kraken-Börse mit Leverage tradet, alle Trades in SQLite protokolliert und ohne mein Eingreifen läuft. Dieser Artikel erklärt die technische Umsetzung – keine Handelsempfehlungen, keine Versprechen über Renditen.
Die Kraken REST API
Kraken bietet eine gut dokumentierte REST API mit Authentifizierung über API-Key und HMAC-Signatur. Jeder Request wird mit einem Nonce (Zeitstempel) und einer signierten Prüfsumme versehen:
import urllib.request
import urllib.parse
import hashlib
import hmac
import base64
import time
def kraken_request(url_path, data, api_key, api_secret):
data["nonce"] = str(int(time.time() * 1000))
post_data = urllib.parse.urlencode(data)
message = (data["nonce"] + post_data).encode()
mac = hmac.new(
base64.b64decode(api_secret),
url_path.encode() + hashlib.sha256(message).digest(),
hashlib.sha512
)
sig = base64.b64encode(mac.digest()).decode()
headers = {"API-Key": api_key, "API-Sign": sig}
req = urllib.request.Request(
"https://api.kraken.com" + url_path,
data=post_data.encode(),
headers=headers
)
return urllib.request.urlopen(req).read()Strategie und Risikomanagement
Die Handelsstrategie ist bewusst simpel – je komplexer die Logik, desto mehr Möglichkeiten für Bugs in produktivem Code, der echtes Geld bewegt. Der Bot arbeitet mit festen Regeln:
- Positionsgröße: Maximal X% des Kontos pro Trade – fest kodiert, nicht konfigurierbar zur Laufzeit
- Stop-Loss: Jede Position bekommt beim Öffnen sofort einen Stop-Loss-Order
- Maximale offene Positionen: Harter Grenzwert im Code verhindert Doppelkäufe bei API-Fehlern
- Kühlphase nach Verlust: Nach einem Stop-Loss wartet der Bot eine definierte Zeit
Leverage bedeutet: Gewinne werden verstärkt – aber Verluste ebenfalls. Das Risikomanagement ist deshalb der kritischste Teil des gesamten Projekts.
Datenbankstruktur
Alle Trades werden in SQLite protokolliert. Das ermöglicht nachträgliche Analyse und stellt sicher, dass der Bot nach einem Neustart seinen Zustand rekonstruieren kann:
CREATE TABLE trades (
id INTEGER PRIMARY KEY,
timestamp DATETIME NOT NULL,
pair TEXT NOT NULL,
direction TEXT NOT NULL,
volume REAL NOT NULL,
price REAL NOT NULL,
leverage INTEGER NOT NULL,
order_id TEXT UNIQUE NOT NULL,
status TEXT NOT NULL,
pnl REAL,
fee REAL
);Deployment
Der Bot läuft auf einem dedizierten Server unter einem eigenen unprivilegierten User. Die Trennung von anderen Diensten ist bewusst: Wenn der Bot abstürzt oder sich falsch verhält, hat das keinen Einfluss auf andere Systeme.
Der Prozess startet als systemd-Service und wird bei Absturz automatisch neu gestartet. Die SQLite-Datenbankdatei wird nightly per sqlite3-Backup-API gesichert – nicht einfaches rsync, da die Datei aktiv beschrieben wird:
import sqlite3
# Konsistenter Snapshot ohne Locking-Probleme
source = sqlite3.connect("/opt/bot/trades.db")
backup = sqlite3.connect("/tmp/trades_backup.db")
source.backup(backup)
backup.close()
source.close()Was ich gelernt habe
- API-Fehler sind der Normalfall: Timeouts, Rate-Limits, temporäre Fehler – der Bot muss mit all dem umgehen, ohne in einen inkonsistenten Zustand zu geraten
- Idempotenz ist entscheidend: Jede Operation muss sicher wiederholbar sein – ein doppelt ausgeführter Kauf wäre teuer
- Logging ist keine Option: Ohne vollständiges Protokoll ist Fehlersuche in einem Produktionssystem unmöglich
- Papier-Trading zuerst: Den Bot sechs Wochen mit Fake-Trades laufen lassen, bevor echtes Kapital eingesetzt wird
Wenn du Fragen zur technischen Umsetzung hast, erreichst du mich über das Kontaktformular.