מדריך פולימרקט Bot · פרק 6 מתוך 32

אימות בוט של פולימרקט והגדרת wallet: proxy wallets מול EOA, יצירת API key באמצעות SDK, sigType 2 עבור Gnosis Safe, שיטות מומלצות לאחסון מפתחות, והמעבר מ-Magic ל-Privy.

מאת הארלי יאנג, כותבת ראשית ב־Polymarkets.co.il. עודכן לאחרונה: מאי 2026.

מה הפרק הזה מכסה

מודל ה-wallet של פולימרקט כולל שלושה חלקים נעים: חשבון בבעלות חיצונית (EOA) שחותם על orders, proxy של חוזה חכם שמחזיק את הכספים, ופולימרקט CLOB API key שמבצע אימות לבקשות HTTP. חיבור נכון של כל השלושה הוא הכשל הנפוץ ביותר ביום הראשון אצל בונים חדשים, וזה נעשה מבלבל עוד יותר אחרי המיגרציה מ-Magic Labs ל-Privy באוגוסט 2025. הפרק הזה עובר על כל רכיב לפי סדר ההגדרה, כולל משתני הסביבה הספציפיים ו-flag סוג החתימה שנדרשים בקוד ייצור.

  • Proxy wallet מול EOA: עם מה כדאי לבוט
  • יצירת API key (שלבי SDK)
  • sigType 2 ו-POLY_FUNDER_ADDRESS (Gnosis Safe)
  • אחסון מפתחות: .env, vault, KMS
  • המיגרציה מ-Magic Labs ל-Privy
  • אישור הוצאת USDC/pUSD
  • שחזור wallet וגיבוי

Proxy wallet מול EOA: עם מה כדאי לבוט

פולימרקט משתמשת בתבנית של smart-contract proxy wallet. ה-EOA שלכם - הכתובת שמקושרת למפתח הפרטי - חותמת על טרנזקציות ו-orders. Gnosis Safe שנפרס בכתובת דטרמיניסטית מחזיק את ה-pUSD ואת ה-outcome shares בפועל. כתובת ה-proxy היא מה שמופיע בלשונית "wallet" בממשק של פולימרקט; ה-EOA היא מה שחותם.

עבור בוטים, תמיד חותמים עם ה-EOA (PRIVATE_KEY ב-env) ומפנים לכתובת ה-proxy כ-POLY_FUNDER_ADDRESS בהגדרת ה-CLOB client. שליחת orders עם ה-EOA כ-funder תייצר שגיאות "insufficient balance" גם כשה-proxy ממומן.

לא ניתן לבטח רק עם ה-EOA - זרימת ה-web של פולימרקט תמיד יוצרת proxy בעת ההרשמה. אפשר לאמת את שתי הכתובות עם polymarket wallet show מה-CLI, או לקרוא את כתובת ה-proxy מתוך ההגדרות בממשק של פולימרקט.

יצירת API key (שלבי SDK)

ה-CLOB API דורש שלושה פרטי גישה: key, secret, passphrase. אלה אינם המפתח הפרטי של ה-wallet שלכם - אלא סט credentials מסוג HMAC שמקושר ל-wallet, ומשמש רק לאימות בקשות HTTP.

יוצרים אותם פעם אחת באמצעות ה-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)

שמרו את הפלט בקובץ JSON וטעינו אותו בכל הפעלה של הבוט; אל תיצרו מחדש בכל session - שרת ה-API שומר cache לסט ה-credentials, והחלפה תכופה יכולה להפעיל לוגיקת rate-limit. ה-credentials לא פגים אוטומטית. החליפו אותם רק אם יש חשד לדליפה.

sigType 2 ו-POLY_FUNDER_ADDRESS (Gnosis Safe)

הארגומנט signature_type קובע כיצד ה-CLOB מאמת את חתימות ה-order שלכם. קיימים שלושה ערכים; שניים מהם אמיתיים:

  • 0 / EOA: ה-EOA הוא גם החותם וגם המממן. משמש להגדרות חריגות שבהן משתמשים ייבאו מפתח פרטי ישירות.
  • 1 / POLY_PROXY: חוזה proxy ישן של Magic Labs. רוב החשבונות שנפתחו לפני 2025.
  • 2 / POLY_GNOSIS_SAFE: הסטנדרט הנוכחי. הכספים ב-Gnosis Safe, וה-EOA חותם.

יש להשתמש ב-signature_type=2 עבור כל חשבון שנוצר אחרי אוגוסט 2025 (מיגרציית Privy) או כל חשבון שבו רואים כתובת Gnosis Safe בממשק של פולימרקט. משתנה ה-env POLY_FUNDER_ADDRESS חייב להיות כתובת ה-Safe, לא ה-EOA. חוסר התאמה בין signature_type לסוג ה-funder יוצר בשקט דחיות של orders שנראות כמו "insufficient allowance" או "balance: 0" - הודעת השגיאה מטעה.

אחסון מפתחות: .env, vault, KMS

שלוש רמות אחסון סבירות למפתח הפרטי של ה-EOA.

  1. קובץ .env (פיתוח על מכונה אחת). הקובץ נמצא על ה-VPS, הבוט קורא אותו בעת ההפעלה, והמפתח לא יוצא מה-host. מתאים מספיק ל-wallets של פחות מ-< $1k. ודאו עם chmod 600 .env ש-.gitignore של הריפו שלכם לא כולל אותו.
  2. vault מתארח-עצמית (HashiCorp Vault, קובץ מוצפן ב-age, או systemd-creds). מוסיף שלב פתיחה בעת הפעלת הבוט. שווה את זה עבור wallets בטווח של $1k-$10k.
  3. Cloud KMS (AWS KMS, GCP KMS). הבוט פונה ל-KMS כדי לפענח את המפתח בזיכרון; המפתח לעולם לא נוגע בדיסק. שווה את המורכבות התפעולית רק מעל $10k או עבור fleets של כמה בוטים.

מה אסור לעשות: לבצע commit למפתח פרטי ל-git, להדביק אותו בצ'אט, לאחסן אותו ב-password manager שמסנכרן ל-cloud services בלי מצב local-only. רדיוס הפיצוץ on-chain של דליפת EOA בפולימרקט הוא כל יתרת ה-pUSD שלכם וכל מלאי ה-outcome shares.

המיגרציה מ-Magic Labs ל-Privy

באוגוסט 2025 פולימרקט עברה מספקת ה-embedded wallet הראשי שלה מ-Magic Labs ל-Privy. ההשפעה על הבוט קטנה אבל ספציפית.

חשבונות שלפני המיגרציה (שנוצרו דרך Magic) משתמשים בדרך כלל ב-signature_type=1 (POLY_PROXY). חשבונות שאחרי המיגרציה משתמשים ב-signature_type=2 (POLY_GNOSIS_SAFE). חלק מהמשתמשים העבירו את החשבון הישן שלהם; אחרים שמרו על המקורי. אין דרך לדעת דרך ה-API הציבורי איזה סוג החשבון שלכם משתמש - בודקים זאת על ידי ניסיון לחתום על order ולצפות בדחייה.

המיגרציה גם שינתה את הדרך שבה ה-UI מציג את כתובת ה-funder. בזרימות ישנות של פולימרקט הוצגה כתובת ה-proxy בדשבורד; בזרימה הנוכחית היא מוסתרת בהגדרות החשבון. פקודת ה-CLI polymarket wallet show היא הדרך הנקייה ביותר לאמת את שני הערכים, בלי קשר למועד יצירת החשבון.

אישור הוצאת USDC/pUSD

כדי שה-CLOB יעביר את ה-pUSD שלכם בעת התאמת order, ה-proxy חייב לאשר לחוזי ה-exchange של פולימרקט לפעול כ-spenders. ה-UI של פולימרקט מגדיר את האישורים האלה במהלך ההפקדה הראשונה. עבור בוטים שמממנים את ה-proxy ישירות, צריך להגדיר אותם ידנית.

שלושה אישורים להגדרה, פעם אחת לכל wallet:

  1. pUSD (ERC-20) → חוזה exchange
  2. Conditional Tokens (ERC-1155) → חוזה exchange (למכירת shares)
  3. Conditional Tokens (ERC-1155) → חוזה NegRisk exchange (למכירת shares של NegRisk)

הריצו polymarket approve מה-CLI בהגדרה הראשונה. הטרנזקציה עולה כמה סנטים ב-gas של MATIC. אימות עושים עם polymarket approve check - שלושתן צריכות להחזיר "approved." הבאג השקט הנפוץ ביותר אצל בונים חדשים הוא היעדר אישור ל-NegRisk, שנכשל רק בעת מכירת shares ב-markets מרובי תוצאות ונראה כמו שגיאת יתרה.

שחזור wallet וגיבוי

ל-wallet של הבוט יש שני רכיבים שניתן לשחזר: המפתח הפרטי של ה-EOA, וסיסמת חשבון פולימרקט (ששולטת בגישה דרך ה-web UI אבל לא דרך ה-SDK).

המפתח הפרטי של ה-EOA הוא הדבר היחיד שבאמת חשוב לבוט. אובדן = אובדן של כל מה שב-proxy. גיבוי קר: כתבו אותו על נייר, סגרו במעטפה, ואחסנו מחוץ לאתר. גיבוי חם: כונן USB מוצפן. לעולם אל תשלחו אותו לעצמכם במייל; לעולם אל תאחסנו לא מוצפן באחסון ענן.

סיסמת חשבון פולימרקט ניתנת לשחזור דרך Magic Labs / Privy email recovery כל עוד יש לכם שליטה על כתובת האימייל המקורית ששימשה בהרשמה. היא לא חוסמת גישה לבוט - הבוט משתמש ישירות במפתח הפרטי של ה-EOA.

אם יש חשד לדליפת מפתח: מיד משכו את ה-pUSD ואת ה-outcome tokens ל-wallet חדש, צרו EOA חדש, ופרסו מחדש את הבוט עם המפתח החדש. אי אפשר לבטל מפתח שדלף; אפשר רק לרוקן אותו.

שאלות נפוצות

האם אני צריך wallet נפרד עבור הבוט שלי?
מומלץ מאוד שכן. השתמשו ב-EOA חדש או ב-proxy wallet חדש שנגזר מחשבון אימייל, שמכיל רק את ההון שהקצתם לבוט. אם מפתח הבוט דולף, רק כספי הבוט נמצאים בסיכון - ההחזקות העיקריות שלכם נשארות בטוחות.
מהו sigType 2 ב-API של פולימרקט?
sigType 2 מציין חתימה של Gnosis Safe (proxy wallet), ומשמש כאשר מתחברים עם אימייל/Google ופולימרקט יוצרת עבורכם את ה-proxy. עבור sigType 2, משתנה הסביבה POLY_FUNDER_ADDRESS חייב להיות כתובת ה-PROXY (הכתובת שמופיעה בממשק של פולימרקט), ולא ה-EOA הבסיסי. זהו באג תצורה נפוץ.
איך יוצרים פולימרקט API key?
משתמשים ב-SDK. ב-Python: ApiCreds מוחזר מ-client.create_api_key() לאחר שאומתתם עם ה-wallet שלכם. ב-Node.js: דומה דרך @polymarket/clob-client-v2 client.createApiKey(). שומרים את ה-key/secret/passphrase שהוחזרו ב-.env שלכם (לעולם לא ב-git).
האם אפשר לבטל פולימרקט API keys?
כן. אפשר לגזור מפתחות חדשים בכל עת דרך ה-SDK; מפתחות ישנים נשארים תקפים עד שמבטלים אותם במפורש דרך client.deleteApiKey(creds). שיטה מומלצת היא לרענן מפתחות תקופתית ולבטל כל מפתח שנגע במכונה שנפגעה.
מה השתנה כשפולימרקט עברה מ-Magic Labs ל-Privy?
קודי OTP של login עברו מ-3 ספרות (פגיעים ל-brute force, והיו חלק מהניצול בהאק של דצמבר 2025) לקודים ארוכים יותר בתוספת קשירת מכשיר דרך Privy. עבור בוטים, השינוי המעשי הוא טקס האימות - ה-SDK ממצה את רובו. אם הבוט שלכם היה מקודד קשיח ל-endpoints של Magic Labs API (נדיר), צריך לעדכן לזרימת Privy.
האם כדאי לאחסן מפתחות בקובץ .env?
עבור בוט על VPS יחיד - כן, עם הרשאות קובץ מתאימות (chmod 600 .env, בבעלות משתמש הבוט). עבור הגדרות מרובות מכונות או תפעול ברמת production - עברו ל-secrets manager (AWS Secrets Manager, Vault, doppler.com). לעולם אל תבצעו commit ל-.env ל-git, אף פעם.