Polymarket Bot Tutorial · Rozdział 6 z 32

Autoryzacja Polymarket bot i konfiguracja walleta: proxy wallets vs EOA, generowanie API key przez SDK, sigType 2 dla Gnosis Safe, najlepsze praktyki przechowywania kluczy oraz migracja z Magic do Privy.

Harley Young, główna redaktorka w Polymarkets.co.il. Ostatnia recenzja: maj 2026.

Co obejmuje ten rozdział

Model walleta w Polymarket ma trzy ruchome elementy: externally owned account (EOA), który podpisuje orders, smart-contract proxy, który trzyma środki, oraz Polymarket CLOB API key, który uwierzytelnia HTTP requests. Poprawne połączenie wszystkich trzech to zdecydowanie najczęstszy błąd Day 1 u nowych builderów, a po migracji z Magic Labs do Privy w sierpniu 2025 stało się to jeszcze bardziej mylące. Ten rozdział prowadzi przez każdy element w kolejności konfiguracji, wraz z konkretnymi environment variables i flagą signature-type, których potrzebuje production code.

To jest rozdział 6 z naszej 32-częściowej serii o budowie Polymarket trading bot. Temat omawiamy szczegółowo w sekcjach poniżej. Treść główna dla każdej sekcji jest pisana i publikowana rozdział po rozdziale; odpowiedzi w FAQ i referencje są już kompletne i odzwierciedlają produkcyjne doświadczenie z działania naszego własnego tradera.

  • Proxy wallet vs EOA: z czym botować
  • Generowanie API key (kroki SDK]
  • sigType 2 i POLY_FUNDER_ADDRESS (Gnosis Safe)
  • Przechowywanie kluczy: .env, vault, KMS
  • Migracja z Magic Labs do Privy
  • Approving USDC/pUSD spending
  • Odzyskiwanie i backup walleta

Proxy wallet vs EOA: z czym botować

Polymarket używa wzorca smart-contract proxy wallet. Twój EOA — address powiązany z twoim private key — podpisuje transactions i orders. Gnosis Safe wdrożony pod deterministycznym adresem przechowuje rzeczywiste pUSD i outcome shares. Adres proxy to ten, który widzisz w panelu „wallet” w UI Polymarket; EOA to ten, który podpisuje.

W przypadku botów zawsze podpisujesz za pomocą EOA (PRIVATE_KEY w env) i podajesz adres proxy jako POLY_FUNDER_ADDRESS w konfiguracji CLOB client. Wysyłanie orders z EOA jako funderem powoduje błędy „insufficient balance”, nawet jeśli proxy jest zasilony.

Nie da się botować wyłącznie z EOA — web flow Polymarket zawsze tworzy proxy przy signup. Potwierdź oba adresy za pomocą polymarket wallet show z CLI albo odczytaj adres proxy z ustawień w UI Polymarket.

Generowanie API key (kroki SDK]

CLOB API wymaga trzech credentials: key, secret, passphrase. To nie jest twój wallet private key — to zestaw credentials w stylu HMAC, powiązany z twoim wallet, używany wyłącznie do uwierzytelniania HTTP requests.

Wygeneruj je raz za pomocą 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)

Zapisz wynik do pliku JSON i ładuj go przy każdym starcie bota; nie generuj go ponownie dla każdej sesji — API server cache'uje zestaw credentials, a częsta rotacja może uruchomić logikę rate-limit. Credentials nigdy nie wygasają automatycznie. Rotuj je tylko wtedy, gdy podejrzewasz wyciek.

sigType 2 i POLY_FUNDER_ADDRESS (Gnosis Safe)

Argument signature_type kontroluje, jak CLOB weryfikuje podpisy twoich orders. Istnieją trzy wartości; dwie są rzeczywiste:

  • 0 / EOA: EOA jest zarówno signerem, jak i funderem. Używane w nietypowych setupach, gdzie użytkownicy importowali private key bezpośrednio.
  • 1 / POLY_PROXY: legacy Magic Labs proxy contract. Większość kont utworzonych przed 2025 rokiem.
  • 2 / POLY_GNOSIS_SAFE: obecny standard. Środki w Gnosis Safe, EOA podpisuje.

Używaj signature_type=2 dla każdego konta utworzonego po sierpniu 2025 (migracja do Privy) lub każdego konta, w którym w UI Polymarket widzisz adres Gnosis Safe. Zmienna env POLY_FUNDER_ADDRESS musi zawierać adres Safe, a nie EOA. Niezgodny signature_type względem typu fundera powoduje ciche odrzucenie orders, które wyglądają jak „insufficient allowance” albo „balance: 0” — komunikat błędu jest mylący.

Przechowywanie kluczy: .env, vault, KMS

Trzy sensowne poziomy przechowywania EOA private key.

  1. Plik .env (development na jednej maszynie). Plik znajduje się na VPS, bot odczytuje go przy starcie, key nigdy nie opuszcza hosta. Wystarczające dla walletów <$1k. chmod 600 .env i upewnij się, że .gitignore w repozytorium go wyklucza.
  2. Self-hosted vault (HashiCorp Vault, plik szyfrowany age albo systemd-creds). Dodaje krok odblokowania przy starcie bota. Warto dla walletów w zakresie $1k-$10k.
  3. Cloud KMS (AWS KMS, GCP KMS). Bot wywołuje KMS, aby odszyfrować key w pamięci; key nigdy nie trafia na dysk. Opłacalne przy tej złożoności operacyjnej dopiero powyżej $10k lub dla wielu botów.

Czego nigdy nie robić: nie commitować private key do git, nie wklejać go na czacie, nie przechowywać w password managerze, który synchronizuje się z cloud services bez trybu lokalnego. Zakres strat on-chain przy wycieku Polymarket EOA to całe saldo pUSD i cały inventory outcome shares.

Migracja z Magic Labs do Privy

W sierpniu 2025 Polymarket przeniósł głównego dostawcę embedded-wallet z Magic Labs do Privy. Efekt dla botów jest niewielki, ale konkretny.

Konta sprzed migracji (utworzone przez Magic) zwykle używają signature_type=1 (POLY_PROXY). Konta po migracji używają signature_type=2 (POLY_GNOSIS_SAFE). Część użytkowników zmigrowała stare konto; część zachowała oryginał. Nie ma sposobu, by z public API sprawdzić, jakiego typu używa twoje konto — trzeba to zweryfikować, próbując podpisać order i obserwując odrzucenie.

Migracja zmieniła też sposób, w jaki UI pokazuje adres fundera. Starsze flow UI Polymarket pokazywały adres proxy w dashboardzie; obecny flow ukrywa go w ustawieniach konta. Komenda CLI polymarket wallet show to najczystszy sposób potwierdzenia obu wartości, niezależnie od tego, kiedy konto zostało utworzone.

Approving USDC/pUSD spending

Aby CLOB mógł przenieść twoje pUSD przy matching order, proxy musi wcześniej zatwierdzić kontrakty exchange Polymarket jako spenders. UI Polymarket ustawia te approvals podczas pierwszego deposit. Dla botów, które zasilają proxy bezpośrednio, trzeba ustawić je ręcznie.

Trzy approvals do ustawienia, raz na wallet:

  1. pUSD (ERC-20) → exchange contract
  2. Conditional Tokens (ERC-1155) → exchange contract (do sprzedawania shares)
  3. Conditional Tokens (ERC-1155) → NegRisk exchange contract (do sprzedawania NegRisk shares)

Uruchom polymarket approve z CLI przy pierwszej konfiguracji. Transaction kosztuje kilka centów w gas MATIC. Sprawdź za pomocą polymarket approve check — wszystkie trzy powinny zwrócić „approved.” Najczęstszy cichy bug u nowych builderów to brak approval dla NegRisk, który ujawnia się dopiero przy sprzedawaniu shares z marketów wielowynikowych i wygląda jak błąd salda.

Odzyskiwanie i backup walleta

Wallet bota ma dwa elementy, które można odzyskać: EOA private key oraz password konta Polymarket (który blokuje dostęp przez web UI, ale nie przez SDK).

EOA private key to jedyna rzecz, która ma znaczenie dla bota. Utrata = utrata wszystkiego w proxy. Cold backup: zapisz go na papierze, zapieczętuj w kopercie, przechowuj poza miejscem użytkowania. Hot backup: zaszyfrowany pendrive USB. Nigdy nie wysyłaj go do siebie e-mailem; nigdy nie przechowuj nieszyfrowanego w cloud storage.

Password konta Polymarket można odzyskać przez Magic Labs / Privy email recovery, o ile nadal kontrolujesz oryginalny email użyty przy signup. Nie blokuje on dostępu bota — bot używa bezpośrednio EOA private key.

Jeśli podejrzewasz wyciek key: natychmiast wypłać pUSD i outcome tokens do nowego walleta, wygeneruj nowe EOA, wdroż bota ponownie z nowym kluczem. Wycieku nie da się unieważnić; można go tylko opróżnić.

Najczęściej zadawane pytania

Czy potrzebuję osobnego walleta dla bota?
Zdecydowanie tak. Użyj świeżego EOA albo świeżego proxy walleta utworzonego z email-account, który trzyma tylko kapitał przypisany do bota. Jeśli key bota wycieknie, zagrożone są tylko środki bota - twoje główne holdings pozostają bezpieczne.
Co to jest sigType 2 w API Polymarkets?
sigType 2 oznacza podpis Gnosis Safe (proxy wallet), używany, gdy logujesz się przez email/Google, a Polymarket tworzy proxy za ciebie. Dla sigType 2 zmienna środowiskowa POLY_FUNDER_ADDRESS musi być adresem PROXY (tym widocznym w UI Polymarket), a nie bazowym EOA. To częsty błąd konfiguracji.
Jak wygenerować Polymarket API key?
Użyj SDK. W Pythonie: ApiCreds zwracane przez client.create_api_key() po uwierzytelnieniu za pomocą walleta. W Node.js: podobnie przez @polymarket/clob-client-v2 client.createApiKey(). Zapisz zwrócony key/secret/passphrase do .env (nigdy nie commituj do git).
Czy Polymarket API keys można unieważnić?
Tak. Możesz w dowolnym momencie wygenerować nowe keys przez SDK; stare keys pozostają ważne aż do ręcznego unieważnienia przez client.deleteApiKey(creds). Dobra praktyka to okresowa rotacja keys i unieważnianie każdego key, który miał kontakt ze skompromitowaną maszyną.
Co zmieniło się po migracji Polymarket z Magic Labs do Privy?
Kody OTP do logowania przeszły z 3 cyfr (podatne na brute force, wykorzystane w hacku z grudnia 2025) na dłuższe kody plus device binding przez Privy. Dla botów praktyczna zmiana to ceremonia auth - SDK abstrahuje większość tego procesu. Jeśli twój bot był na sztywno ustawiony na endpointy API Magic Labs (rzadkie), zaktualizuj go do flow Privy.
Czy powinienem przechowywać keys w pliku .env?
Dla bota na jednym VPS - tak, z odpowiednimi permissions pliku (chmod 600 .env, właściciel: użytkownik bota). Dla setupów wielomaszynowych albo produkcyjnych - przejdź na secrets manager (AWS Secrets Manager, Vault, doppler.com). Nigdy, przenigdy nie commituj .env do git.