Polymarket Bot Tutorial · Hoofdstuk 6 van 32

Polymarket bot-authenticatie en wallet-setup: proxy wallets vs EOA, API key generatie via SDK, sigType 2 voor Gnosis Safe, best practices voor key storage en de Magic-naar-Privy migratie.

Door Harley Young, hoofdredacteur bij Polymarkets.co.il. Laatst beoordeeld: mei 2026.

Wat dit hoofdstuk behandelt

Polymarkets wallet-model heeft drie bewegende delen: een externally owned account (EOA) die orders tekent, een smart-contract proxy die fondsen vasthoudt en de Polymarket CLOB API-key die HTTP-requests authenticeert. Alle drie correct bedraad krijgen is de meest voorkomende Day 1-failure voor nieuwe builders, en het werd verwarrender na de Magic Labs naar Privy migratie van augustus 2025. Dit hoofdstuk wandelt door elk stuk in setup-volgorde, met de specifieke environment-variabelen en signature-type flag die productie-code nodig heeft.

Dit is hoofdstuk 6 van onze 32-delige serie over het bouwen van een Polymarket trading bot. We behandelen het onderwerp in detail in de secties hieronder. De body content voor elke sectie wordt geschreven en hoofdstuk-per-hoofdstuk uitgerold; FAQ-antwoorden en referenties zijn al compleet en weerspiegelen production-ervaring van het draaien van onze eigen trader.

  • Proxy wallet vs EOA: waarmee te botten
  • Een API-key genereren (SDK-stappen)
  • sigType 2 en POLY_FUNDER_ADDRESS (Gnosis Safe)
  • Key storage: .env, vault, KMS
  • De Magic Labs naar Privy migratie
  • USDC/pUSD spending approven
  • Wallet recovery en backup

Proxy wallet vs EOA: waarmee te botten

Polymarket gebruikt een smart-contract proxy wallet patroon. Je EOA — het address gekoppeld aan je private key — tekent transacties en orders. Een Gnosis Safe gedeployed op een deterministisch adres houdt de daadwerkelijke pUSD en outcome shares vast. Het proxy-adres is wat te zien is in Polymarkets UI "wallet" paneel; de EOA is wat tekent.

Voor bots teken je altijd met de EOA (PRIVATE_KEY in env) en refereer je het proxy-adres als POLY_FUNDER_ADDRESS in de CLOB client config. Orders verzenden met de EOA als funder produceert "insufficient balance" errors zelfs als de proxy gefund is.

Je kunt niet botten met alleen de EOA — Polymarkets web flow creëert altijd een proxy bij signup. Bevestig beide adressen met polymarket wallet show vanaf de CLI, of lees het proxy-adres uit de Polymarket UI-instellingen.

Een API-key genereren (SDK-stappen)

De CLOB API vereist drie credentials: key, secret, passphrase. Deze zijn niet je wallet private key — het is een HMAC-stijl credential set gebonden aan je wallet, alleen gebruikt voor HTTP-request authenticatie.

Genereer ze eenmalig met de 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)

Sla de output op in een JSON-file en laad hem op elke bot-start; regenereer niet per sessie — de API-server cachet de credential set, en frequent roteren kan rate-limit logica triggeren. De credentials verlopen nooit automatisch. Roteer alleen als je een leak vermoedt.

sigType 2 en POLY_FUNDER_ADDRESS (Gnosis Safe)

Het signature_type argument bepaalt hoe de CLOB je order-handtekeningen valideert. Drie waarden bestaan; twee zijn echt:

  • 0 / EOA: de EOA is zowel signer als funder. Gebruikt voor ongewone setups waar gebruikers een private key direct importeerden.
  • 1 / POLY_PROXY: legacy Magic Labs proxy contract. De meeste pre-2025 accounts.
  • 2 / POLY_GNOSIS_SAFE: huidige standaard. Fondsen in een Gnosis Safe, EOA tekent.

Gebruik signature_type=2 voor elke account aangemaakt na augustus 2025 (de Privy-migratie) of elke account waar je een Gnosis Safe-adres in de Polymarket UI kunt zien. De POLY_FUNDER_ADDRESS env-var moet het Safe-adres zijn, niet de EOA. Mismatched signature_type tegen het funder-type produceert stil order-rejections die eruitzien als "insufficient allowance" of "balance: 0" — de error-melding is misleidend.

Key storage: .env, vault, KMS

Drie redelijke storage-tiers voor de EOA private key.

  1. .env file (single-machine ontwikkeling). De file leeft op de VPS, de bot leest hem op start, de key verlaat de host nooit. Adequaat voor <1k $ wallets. chmod 600 .env en zorg dat de .gitignore van je repo hem uitsluit.
  2. Self-hosted vault (HashiCorp Vault, age-encrypted file of systemd-creds). Voegt een unlock-stap toe bij bot-start. De moeite waard voor wallets in de 1k-10k $ range.
  3. Cloud KMS (AWS KMS, GCP KMS). De bot roept KMS aan om de key in geheugen te decrypten; de key raakt nooit disk. De operationele complexiteit waard alleen boven 10k $ of voor multi-bot fleets.

Wat nooit te doen: een private key committen naar git, hem plakken in een chat, opslaan in een password manager die synct naar cloud-services zonder local-only mode. De on-chain blast radius van een Polymarket EOA-leak is je hele pUSD-balance en outcome-share inventory.

De Magic Labs naar Privy migratie

In augustus 2025 migreerde Polymarket hun primaire embedded-wallet provider van Magic Labs naar Privy. Het bot-facing effect is klein maar specifiek.

Pre-migratie accounts (gemaakt via Magic) gebruiken typisch signature_type=1 (POLY_PROXY). Post-migratie accounts gebruiken signature_type=2 (POLY_GNOSIS_SAFE). Sommige gebruikers migreerden hun oude account; sommigen hielden het origineel. Er is geen manier om vanaf de publieke API te zien welk type je account gebruikt — je checkt door een order te proberen tekenen en de rejection te observeren.

De migratie veranderde ook hoe de UI het funder-adres exposeert. Oudere Polymarket UI-flows toonden het proxy-adres in het dashboard; de huidige flow begraaft het in account-settings. Het CLI-commando polymarket wallet show is de cleanste manier om beide waarden te bevestigen, ongeacht wanneer het account is gemaakt.

USDC/pUSD spending approven

Voor de CLOB om je pUSD te bewegen bij order match, moet de proxy de Polymarket exchange-contracten goedgekeurd hebben als spenders. De Polymarket UI zet deze approvals tijdens de eerste storting. Voor bots die de proxy direct funden, moet je ze handmatig zetten.

Drie approvals te zetten, eenmaal per wallet:

  1. pUSD (ERC-20) → exchange contract
  2. Conditional Tokens (ERC-1155) → exchange contract (voor het verkopen van shares)
  3. Conditional Tokens (ERC-1155) → NegRisk exchange contract (voor het verkopen van NegRisk shares)

Run polymarket approve vanaf de CLI bij de eerste setup. De transactie kost een paar cent in MATIC gas. Verifieer met polymarket approve check — alle drie moeten "approved" teruggeven. De meest voorkomende stille bug voor nieuwe builders is het missen van de NegRisk approval, wat alleen faalt bij het verkopen van shares uit multi-outcome markten en eruitziet als een balance error.

Wallet recovery en backup

De wallet van de bot heeft twee herstelbare elementen: de EOA private key en het Polymarket account-wachtwoord (dat toegang via de web UI poort maar niet via de SDK).

De EOA private key is het enige wat telt voor de bot. Verlies = verlies van alles in de proxy. Koude backup: schrijf hem op papier, verzegel in een envelop, bewaar offsite. Hete backup: encrypted USB-stick. E-mail hem nooit naar jezelf; sla nooit unencrypted op in cloud-opslag.

Het Polymarket account-wachtwoord is herstelbaar via Magic Labs / Privy email recovery zolang je de originele signup-email nog beheert. Het gate't geen bot-toegang — de bot gebruikt de EOA private key direct.

Als je een key-leak vermoedt: direct pUSD en outcome tokens uittrekken naar een nieuwe wallet, een nieuwe EOA genereren, de bot redeployen met de nieuwe key. De gelekte key kan niet worden ingetrokken; hij kan alleen leeggehaald worden.

Veelgestelde vragen

Heb ik een aparte wallet nodig voor mijn bot?
Sterk aanbevolen ja. Gebruik een verse EOA of een verse email-account-derived proxy wallet die alleen het kapitaal vasthoudt dat je hebt toegewezen aan de bot. Als de bot-key lekt, lopen alleen de bot-fondsen risico — je main holdings blijven veilig.
Wat is sigType 2 in Polymarkets API?
sigType 2 indiceert een Gnosis Safe (proxy wallet) handtekening, gebruikt wanneer je inlogt met email/Google en Polymarket de proxy voor je maakt. Voor sigType 2 moet de POLY_FUNDER_ADDRESS environment-variabele het PROXY adres zijn (degene getoond in de Polymarket UI), niet de onderliggende EOA. Dit is een veelvoorkomende configuratie-bug.
Hoe genereer ik een Polymarket API-key?
Gebruik de SDK. In Python: ApiCreds teruggegeven door client.create_api_key() zodra je hebt geauthenticeerd met je wallet. In Node.js: vergelijkbaar via @polymarket/clob-client-v2 client.createApiKey(). Sla de teruggegeven key/secret/passphrase op in je .env (commit nooit naar git).
Zijn Polymarket API-keys revocable?
Ja. Je kunt te allen tijde nieuwe keys deriven via de SDK; oude keys blijven geldig totdat ze expliciet worden ingetrokken via client.deleteApiKey(creds). Best practice is keys periodiek roteren en elke key intrekken die een gecompromitteerde machine heeft aangeraakt.
Wat veranderde toen Polymarket migreerde van Magic Labs naar Privy?
Login OTP-codes gingen van 3 cijfers (kwetsbaar voor brute force, geëxploiteerd in de december 2025 hack) naar langere codes plus device binding via Privy. Voor bots is de praktische verandering de auth-ceremonie — de SDK abstraheert het meeste ervan. Als je bot hard-coded was naar Magic Labs API-endpoints (zeldzaam), update naar de Privy flow.
Moet ik keys opslaan in een .env file?
Voor een single-VPS bot — ja, met juiste file-permissies (chmod 600 .env, eigendom van de bot-user). Voor multi-machine setups of production-grade ops — verhuis naar een secrets manager (AWS Secrets Manager, Vault, doppler.com). Commit .env nooit naar git, ooit.