Polymarket Bot Tutorial · Kapitel 6 von 32

Polymarket bot authentication and wallet setup: proxy wallets vs EOA, API key generation via SDK, sigType 2 for Gnosis Safe, key storage best practices, and the Magic-to-Privy migration.

Von Harley Young, Chefredakteurin bei Polymarkets.co.il. Zuletzt überprüft: Mai 2026.

Was dieses Kapitel abdeckt

Polymarkets Wallet-Modell hat drei bewegliche Teile: ein externally owned account (EOA), das Orders signiert, einen Smart-Contract-Proxy, der Funds hält, und den Polymarket CLOB API key, der HTTP requests authentifiziert. Alle drei korrekt zu verdrahten, ist der mit Abstand häufigste Day-1-Fehler für neue Builder, und es wurde nach der Migration von Magic Labs zu Privy im August 2025 noch verwirrender. Dieses Kapitel geht jedes Teil in der Reihenfolge des Setups durch, mit den konkreten environment variables und dem Signature-Type-Flag, das Production-Code benötigt.

  • Proxy wallet vs EOA: womit man botten sollte
  • Generieren eines API key (SDK steps)
  • sigType 2 und POLY_FUNDER_ADDRESS (Gnosis Safe)
  • Key storage: .env, vault, KMS
  • Die Migration von Magic Labs zu Privy
  • USDC/pUSD spending genehmigen
  • Wallet recovery und backup

Proxy wallet vs EOA: womit man botten sollte

Polymarket verwendet ein smart-contract proxy wallet pattern. Dein EOA - die Adresse, die mit deinem private key verknüpft ist - signiert transactions und orders. Ein Gnosis Safe, das an einer deterministischen Adresse deployed wurde, hält das tatsächliche pUSD und die outcome shares. Die Proxy-Adresse ist das, was im Polymarket-UI-Panel „wallet“ angezeigt wird; das EOA ist das, was signiert.

Für Bots signierst du immer mit dem EOA (PRIVATE_KEY in env) und referenzierst die Proxy-Adresse als POLY_FUNDER_ADDRESS in der CLOB client config. Orders mit dem EOA als funder zu senden, erzeugt „insufficient balance“-Fehler, selbst wenn der Proxy gefunded ist.

Du kannst nicht nur mit dem EOA botten - der Web-Flow von Polymarket erstellt bei der Registrierung immer einen Proxy. Bestätige beide Adressen mit polymarket wallet show aus der CLI, oder lies die Proxy-Adresse aus den settings in der Polymarket UI aus.

Generieren eines API key (SDK steps)

Die CLOB API benötigt drei credentials: key, secret, passphrase. Das ist nicht dein wallet private key - es ist ein HMAC-artiges credential set, das an deine wallet gebunden ist und nur für die HTTP request authentication verwendet wird.

Generiere sie einmal mit dem SDK:

# Python
from py_clob_client.client import ClobClient
c = ClobClient(host="https://clob.polymarket.com", chain_id=137,
               key="<PRIVATE_KEY>", signature_type=2,
               funder="<PROXY_ADDRESS>")
creds = c.create_or_derive_api_creds()
print(creds.api_key, creds.api_secret, creds.api_passphrase)

Speichere die Ausgabe in einer JSON-Datei und lade sie bei jedem Bot-Start; nicht pro Session neu generieren - der API server cached das credential set, und häufiges Rotieren kann rate-limit logic auslösen. Die credentials laufen nicht automatisch ab. Rotieren solltest du sie nur, wenn du einen Leak vermutest.

sigType 2 und POLY_FUNDER_ADDRESS (Gnosis Safe)

Das signature_type-Argument steuert, wie die CLOB deine order signatures validiert. Es gibt drei Werte; zwei sind echt:

  • 0 / EOA: Das EOA ist sowohl Signer als auch funder. Verwendet für ungewöhnliche Setups, bei denen Nutzer einen private key direkt importiert haben.
  • 1 / POLY_PROXY: Legacy Magic Labs proxy contract. Die meisten Accounts vor 2025.
  • 2 / POLY_GNOSIS_SAFE: Aktueller Standard. Funds liegen in einem Gnosis Safe, das EOA signiert.

Verwende signature_type=2 für jedes Konto, das nach August 2025 erstellt wurde (der Privy migration) oder für jedes Konto, bei dem du in der Polymarket UI eine Gnosis Safe-Adresse siehst. Die env var POLY_FUNDER_ADDRESS muss die Safe-Adresse sein, nicht das EOA. Ein nicht passendes signature_type im Verhältnis zum funder-Typ führt stillschweigend zu order rejections, die wie „insufficient allowance“ oder „balance: 0“ aussehen - die Fehlermeldung ist irreführend.

Key storage: .env, vault, KMS

Drei sinnvolle Storage-Tiers für den EOA private key.

  1. .env file (Single-Machine-Development). Die Datei liegt auf dem VPS, der Bot liest sie beim Start, der Key verlässt den Host nie. Ausreichend für Wallets unter <$1k. chmod 600 .env und sicherstellen, dass die .gitignore deines Repos sie ausschließt.
  2. Self-hosted vault (HashiCorp Vault, age-encrypted file oder systemd-creds). Fügt beim Bot-Start einen Unlock-Schritt hinzu. Lohnt sich für Wallets im Bereich von $1k-$10k.
  3. Cloud KMS (AWS KMS, GCP KMS). Der Bot ruft KMS auf, um den Key im memory zu entschlüsseln; der Key berührt nie die disk. Die operative Komplexität lohnt sich nur über $10k oder für multi-bot fleets.

Was du niemals tun solltest: einen private key in git committen, ihn in einen chat einfügen, ihn in einem password manager speichern, der ohne local-only mode mit cloud services synchronisiert. Der on-chain blast radius eines Polymarket EOA-Leaks ist dein gesamter pUSD-Bestand und dein inventory an outcome shares.

Die Migration von Magic Labs zu Privy

Im August 2025 migrierte Polymarket seinen primären eingebetteten wallet provider von Magic Labs zu Privy. Der für Bots sichtbare Effekt ist klein, aber konkret.

Konten vor der Migration (erstellt über Magic) verwenden typischerweise signature_type=1 (POLY_PROXY). Konten nach der Migration verwenden signature_type=2 (POLY_GNOSIS_SAFE). Einige Nutzer migrierten ihr altes Konto; andere behielten das ursprüngliche. Es gibt keine Möglichkeit, über die public API zu erkennen, welchen Typ dein Konto verwendet - du prüfst es, indem du versuchst, eine order zu signieren und die rejection beobachtest.

Die Migration änderte auch, wie die UI die funder address anzeigt. Ältere Polymarket-UI-Flows zeigten die Proxy-Adresse im Dashboard; der aktuelle Flow versteckt sie in den account settings. Der CLI-Befehl polymarket wallet show ist der sauberste Weg, beide Werte zu bestätigen, unabhängig davon, wann das Konto erstellt wurde.

USDC/pUSD spending genehmigen

Damit die CLOB dein pUSD bei einem order match bewegen kann, muss der Proxy die Polymarket exchange contracts als spenders genehmigt haben. Die Polymarket UI setzt diese approvals während der ersten Einzahlung. Für Bots, die den Proxy direkt funden, musst du sie manuell setzen.

Drei approvals, einmal pro wallet zu setzen:

  1. pUSD (ERC-20) → exchange contract
  2. Conditional Tokens (ERC-1155) → exchange contract (zum Verkauf von shares)
  3. Conditional Tokens (ERC-1155) → NegRisk exchange contract (zum Verkauf von NegRisk shares)

Führe bei der ersten Einrichtung polymarket approve aus der CLI aus. Die transaction kostet ein paar Cent an MATIC gas. Mit polymarket approve check verifizieren - alle drei sollten „approved“ zurückgeben. Der häufigste stille Bug für neue Builder ist eine fehlende NegRisk approval, die nur beim Verkauf von shares aus multi-outcome markets fehlschlägt und wie ein balance-Fehler aussieht.

Wallet recovery und backup

Die Wallet des Bots hat zwei wiederherstellbare Elemente: den EOA private key und das Polymarket account password (das den Zugriff über die Web UI steuert, nicht aber über das SDK).

Der EOA private key ist das einzige, was für den Bot zählt. Verlust = Verlust von allem im Proxy. Cold backup: auf Papier schreiben, in einem Umschlag versiegeln, extern lagern. Hot backup: verschlüsselter USB-Stick. Niemals per E-Mail an dich selbst schicken; niemals unverschlüsselt in cloud storage speichern.

Das Polymarket account password ist über die Magic Labs / Privy email recovery wiederherstellbar, solange du noch die ursprüngliche Signup-E-Mail kontrollierst. Es steuert den Bot-Zugriff nicht - der Bot verwendet direkt den EOA private key.

Wenn du einen key leak vermutest: sofort pUSD und outcome tokens auf eine neue wallet abheben, ein neues EOA generieren, den Bot mit dem neuen key neu deployen. Der geleakte key kann nicht revokiert werden; er kann nur geleert werden.

Häufig gestellte Fragen

Brauche ich für meinen Bot eine separate Wallet?
Dringend empfohlen: ja. Verwende ein frisches EOA oder eine frische, aus dem E-Mail-Account abgeleitete Proxy-Wallet, die nur das Kapital hält, das du dem Bot zugewiesen hast. Wenn der Bot-Key leakt, sind nur die Bot-Funds gefährdet - deine Hauptbestände bleiben sicher.
Was ist sigType 2 in der Polymarket API?
sigType 2 weist auf eine Gnosis Safe (proxy wallet) signature hin, die verwendet wird, wenn du dich mit E-Mail/Google anmeldest und Polymarket den Proxy für dich erstellt. Bei sigType 2 muss die Environment Variable POLY_FUNDER_ADDRESS die PROXY-Adresse sein (die in der Polymarket UI angezeigt wird), nicht das zugrunde liegende EOA. Das ist ein häufiger Konfigurationsfehler.
Wie generiere ich einen Polymarket API key?
Verwende das SDK. In Python: ApiCreds, zurückgegeben von client.create_api_key(), nachdem du dich mit deiner Wallet authentifiziert hast. In Node.js: ähnlich über @polymarket/clob-client-v2 client.createApiKey(). Speichere den zurückgegebenen key/secret/passphrase in deiner .env (niemals in git committen).
Sind Polymarket API keys widerrufbar?
Ja. Du kannst jederzeit über das SDK neue keys ableiten; alte keys bleiben gültig, bis sie explizit über client.deleteApiKey(creds) widerrufen werden. Best Practice ist, keys regelmäßig zu rotieren und jeden key zu widerrufen, der einen kompromittierten Rechner berührt hat.
Was änderte sich, als Polymarket von Magic Labs zu Privy migrierte?
Login-OTP-Codes wechselten von 3 Ziffern (anfällig für brute force, ausgenutzt beim Hack im Dezember 2025) zu längeren Codes plus device binding über Privy. Für Bots ist die praktische Änderung der auth ceremony - das SDK abstrahiert den Großteil davon. Wenn dein Bot hart auf Magic-Labs-API-Endpunkte verdrahtet war (selten), auf den Privy flow aktualisieren.
Sollte ich keys in einer .env file speichern?
Für einen Bot auf einem einzelnen VPS - ja, mit korrekten file permissions (chmod 600 .env, dem Bot-User gehörend). Für Multi-Machine-Setups oder Production-Grade-Ops - auf einen secrets manager umsteigen (AWS Secrets Manager, Vault, doppler.com). .env niemals in git committen, wirklich niemals.