Polymarket Bot Tutorial · Kabanata 6 ng 32

Polymarket bot authentication at wallet setup: proxy wallets vs EOA, API key generation sa pamamagitan ng SDK, sigType 2 para sa Gnosis Safe, key storage best practices, at ang Magic-to-Privy migration.

Ni Harley Young, pangunahing manunulat sa Polymarkets.co.il. Huling rebyu: Mayo 2026.

Ano ang sinasaklaw ng kabanatang ito

Ang wallet model ng Polymarket ay may tatlong moving parts: externally owned account (EOA) na nag-sign ng orders, smart-contract proxy na may hawak ng funds, at ang Polymarket CLOB API key na nag-authenticate ng HTTP requests. Ang pagkakaroon ng tatlo na maayos na naka-wired ay ang pinakakaraniwang Day 1 failure para sa bagong builders, at naging mas nakakalito pagkatapos ng Agosto 2025 Magic Labs hanggang Privy migration. Ang kabanatang ito ay naglalakad sa bawat piraso sa setup order, gamit ang specific environment variables at signature-type flag na kailangan ng production code.

  • Proxy wallet vs EOA: kung saan i-bot
  • Pag-generate ng API key (SDK steps)
  • sigType 2 at POLY_FUNDER_ADDRESS (Gnosis Safe)
  • Key storage: .env, vault, KMS
  • Ang Magic Labs hanggang Privy migration
  • Pag-approve ng USDC/pUSD spending
  • Wallet recovery at backup

Proxy wallet vs EOA: kung saan i-bot

Gumagamit ang Polymarket ng smart-contract proxy wallet pattern. Ang iyong EOA - ang address na naka-tie sa iyong private key - ay nag-sign ng transactions at orders. Ang Gnosis Safe na deployed sa deterministic address ay may hawak ng aktwal na pUSD at outcome shares. Ang proxy address ang lumalabas sa "wallet" panel ng Polymarket UI; ang EOA ang nag-sign.

Para sa bots, palagi kang nag-sign gamit ang EOA (PRIVATE_KEY sa env) at i-reference ang proxy address bilang POLY_FUNDER_ADDRESS sa CLOB client config. Ang pagpapadala ng orders gamit ang EOA bilang funder ay gumagawa ng "insufficient balance" errors kahit funded ang proxy.

Hindi ka maaaring mag-bot gamit ang EOA lamang - laging gumagawa ang Polymarket web flow ng proxy sa signup. Kumpirmahin ang parehong addresses sa polymarket wallet show mula sa CLI, o basahin ang proxy address mula sa Polymarket UI settings.

Pag-generate ng API key (SDK steps)

Nangangailangan ang CLOB API ng tatlong credentials: key, secret, passphrase. Hindi ito ang iyong wallet private key - ito ay HMAC-style credential set na naka-bind sa iyong wallet, ginagamit para sa HTTP request authentication lamang.

I-generate ang mga ito nang isang beses gamit ang 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)

I-store ang output sa JSON file at i-load sa bawat bot start; huwag mag-regenerate per session - nag-cache ang API server ng credential set, at ang madalas na rotating ay maaaring mag-trip sa rate-limit logic. Hindi nag-eexpire ang credentials automatically. Mag-rotate lamang kung naghihinala kang may leak.

sigType 2 at POLY_FUNDER_ADDRESS (Gnosis Safe)

Kinokontrol ng signature_type argument kung paano nag-validate ang CLOB ng iyong order signatures. Tatlong values ang umiiral; dalawa ang totoo:

  • 0 / EOA: ang EOA ay parehong signer at funder. Ginagamit para sa unusual setups kung saan na-import ng users ang private key nang direkta.
  • 1 / POLY_PROXY: legacy Magic Labs proxy contract. Karamihan ng pre-2025 accounts.
  • 2 / POLY_GNOSIS_SAFE: kasalukuyang standard. Funds sa Gnosis Safe, EOA nag-sign.

Gamitin ang signature_type=2 para sa anumang account na ginawa pagkatapos ng Agosto 2025 (ang Privy migration) o anumang account kung saan nakikita mo ang Gnosis Safe address sa Polymarket UI. Ang POLY_FUNDER_ADDRESS env var ay dapat ang Safe address, hindi ang EOA. Ang mismatched signature_type laban sa funder type ay tahimik na gumagawa ng order rejections na mukhang "insufficient allowance" o "balance: 0" - ang error message ay misleading.

Key storage: .env, vault, KMS

Tatlong makatuwirang storage tiers para sa EOA private key.

  1. .env file (single-machine development). Ang file ay nakatira sa VPS, binabasa ng bot sa start, hindi kailanman umaalis ang key sa host. Sapat para sa <$1k wallets. chmod 600 .env at siguraduhing ineexclude ito ng .gitignore ng iyong repo.
  2. Self-hosted vault (HashiCorp Vault, age-encrypted file, o systemd-creds). Nagdadagdag ng unlock step sa bot start. Sulit para sa wallets sa $1k-$10k range.
  3. Cloud KMS (AWS KMS, GCP KMS). Tinatawag ng bot ang KMS para i-decrypt ang key sa memory; hindi kailanman tumatama ang key sa disk. Sulit ang operational complexity sa itaas ng $10k o para sa multi-bot fleets.

Kung ano ang huwag gagawin: mag-commit ng private key sa git, mag-paste nito sa chat, mag-store nito sa password manager na nag-sync sa cloud services nang walang local-only mode. Ang on-chain blast radius ng Polymarket EOA leak ay ang iyong buong pUSD balance at outcome share inventory.

Ang Magic Labs hanggang Privy migration

Noong Agosto 2025 ay nag-migrate ang Polymarket ng kanilang primary embedded-wallet provider mula Magic Labs sa Privy. Ang bot-facing effect ay maliit pero specific.

Ang pre-migration accounts (ginawa sa pamamagitan ng Magic) ay karaniwang gumagamit ng signature_type=1 (POLY_PROXY). Ang post-migration accounts ay gumagamit ng signature_type=2 (POLY_GNOSIS_SAFE). Ang ilang users ay nag-migrate ng kanilang lumang account; ang iba ay nanatili sa original. Walang paraan upang malaman mula sa public API kung anong type ang ginagamit ng iyong account - i-check sa pamamagitan ng pagsubok mag-sign ng order at pagmamasid sa rejection.

Ang migration ay nagbago rin kung paano ipinapakita ng UI ang funder address. Ang mas matandang Polymarket UI flows ay ipinapakita ang proxy address sa dashboard; ang kasalukuyang flow ay nag-bury nito sa account settings. Ang CLI command polymarket wallet show ang pinakamalinis na paraan upang kumpirmahin ang parehong values, anuman ang panahon ng paggawa ng account.

Pag-approve ng USDC/pUSD spending

Para makapag-move ang CLOB ng iyong pUSD sa order match, dapat ay na-approve ng proxy ang Polymarket exchange contracts bilang spenders. Itinakda ng Polymarket UI ang approvals na ito sa unang deposit. Para sa bots na nag-fund ng proxy nang direkta, kailangan mong itakda ang mga ito manually.

Tatlong approvals na itakda, isang beses kada wallet:

  1. pUSD (ERC-20) → exchange contract
  2. Conditional Tokens (ERC-1155) → exchange contract (para sa pagbebenta ng shares)
  3. Conditional Tokens (ERC-1155) → NegRisk exchange contract (para sa pagbebenta ng NegRisk shares)

Mag-run ng polymarket approve mula sa CLI sa unang setup. Ang transaction ay gumagastos ng ilang sentimo sa MATIC gas. I-verify gamit ang polymarket approve check - lahat ng tatlo ay dapat magrurn ng "approved." Ang pinakakaraniwang silent bug para sa bagong builders ay ang pagkawala ng NegRisk approval, na nabigo lamang kapag nagbebenta ng shares mula sa multi-outcome markets at mukhang balance error.

Wallet recovery at backup

Ang wallet ng bot ay may dalawang recoverable elements: ang EOA private key, at ang Polymarket account password (na nag-gate ng access sa pamamagitan ng web UI pero hindi sa pamamagitan ng SDK).

Ang EOA private key ang tanging bagay na mahalaga para sa bot. Pagkawala = pagkawala ng lahat sa proxy. Cold backup: isulat sa papel, sealed sa envelope, store offsite. Hot backup: encrypted USB stick. Huwag kailanman i-email ito sa iyong sarili; huwag kailanman i-store nang unencrypted sa cloud storage.

Ang Polymarket account password ay recoverable sa pamamagitan ng Magic Labs / Privy email recovery hangga't kinokontrol mo pa rin ang original signup email. Hindi ito nag-gate ng bot access - gumagamit ang bot ng EOA private key nang direkta.

Kung naghihinala kang may key leak: kaagad mag-withdraw ng pUSD at outcome tokens sa bagong wallet, mag-generate ng bagong EOA, mag-redeploy ng bot gamit ang bagong key. Ang leaked key ay hindi maaaring i-revoke; maaari lang itong i-drain.

Mga madalas na tanong

Kailangan ko ba ng hiwalay na wallet para sa aking bot?
Malakas na inirerekomenda na oo. Gumamit ng sariwang EOA o sariwang email-account-derived proxy wallet na may hawak lamang ng capital na inilaan mo sa bot. Kung mag-leak ang bot key, ang bot funds lamang ang nasa panganib - ang main holdings mo ay mananatiling ligtas.
Ano ang sigType 2 sa Polymarket API?
Ang sigType 2 ay nagpapahiwatig ng Gnosis Safe (proxy wallet) signature, ginagamit kapag nag-log in ka gamit ang email/Google at gumagawa ang Polymarket ng proxy para sa iyo. Para sa sigType 2, ang POLY_FUNDER_ADDRESS environment variable ay dapat ang PROXY address (ang ipinapakita sa Polymarket UI), hindi ang underlying EOA. Ito ay karaniwang configuration bug.
Paano ko mag-generate ng Polymarket API key?
Gamitin ang SDK. Sa Python: ApiCreds na ibinalik ng client.create_api_key() pagkatapos mong ma-authenticate sa iyong wallet. Sa Node.js: katulad sa pamamagitan ng @polymarket/clob-client-v2 client.createApiKey(). I-save ang returned key/secret/passphrase sa iyong .env (huwag kailanman i-commit sa git).
Maaari bang i-revoke ang Polymarket API keys?
Oo. Maaari kang mag-derive ng bagong keys anumang oras sa pamamagitan ng SDK; ang mga lumang keys ay mananatiling valid hanggang sa explicit na i-revoke sa pamamagitan ng client.deleteApiKey(creds). Best practice ay mag-rotate ng keys periodically at i-revoke ang anumang key na nakagat ng compromised machine.
Ano ang nagbago nang nag-migrate ang Polymarket mula Magic Labs sa Privy?
Ang login OTP codes ay napunta mula sa 3 digits (mahina sa brute force, na-exploit sa December 2025 hack) sa mas mahabang codes plus device binding sa pamamagitan ng Privy. Para sa bots, ang practical change ay ang auth ceremony - ang SDK ay nag-aabstract ng karamihan nito. Kung ang iyong bot ay hard-coded sa Magic Labs API endpoints (bihira), i-update sa Privy flow.
Dapat ko bang i-store ang keys sa .env file?
Para sa single-VPS bot - oo, na may tamang file permissions (chmod 600 .env, owned ng bot user). Para sa multi-machine setups o production-grade ops - lumipat sa secrets manager (AWS Secrets Manager, Vault, doppler.com). Huwag kailanman i-commit ang .env sa git, kailanman.