בוט מסחר עבור Kraken: nonce, WebSocket ומגבלות קצב

אינטגרציה של Kraken API: היכן נשבר בוט מסחר

כל עוד הבוט שולח בקשות בודדות, האינטגרציה עם Kraken API נראית כמו חילופי «בקשה — תגובה». תחת עומס ובתנועות חדות בשוק מופיעים ארבעה סוגי כשלים: אי-התאמה בין החתימה למספר הסידורי של הבקשה, הפעלת מגבלות קצב, ניתוק ערוץ קבוע ופער בין המצב המקומי לזה שבבורסה.

היקר ביותר הוא אובדן הזמנות. התגובה להזמנה שנשלחה לא הגיעה בגלל חריגת זמן, הבוט חוזר על הבקשה — ובבורסה מופיעה הזמנה שנייה במקום אחת. תרחיש הפוך: הבוט מחשיב את ההזמנה כלא-מבוצעת ומבטל אותה, אף שהעסקה כבר עברה. הפוזיציה והסיכון אינם תואמים למציאות, ובלוגים נשארת פעולה «מוצלחת».

חיבור לא יציב לבורסה שובר בשקט: הערוץ הקבוע מפסיק לדבר בלי שגיאה מפורשת, זרם העסקאות וספר ההזמנות מפסיק להתעדכן, והבוט ממשיך לסחור לפי נתונים מיושנים. הזמנות תקועות — לא מבוטלות ולא מבוצעות — תלויות עד התערבות ידנית ומעוותות את הערכת הפוזיציה.

לכן את הביקורת של מערך המסחר מתחילים לא מהקוד, אלא מהיומנים: משווים את היסטוריית ההזמנות והעסקאות, משחזרים ניתוקי ערוץ, בוחנים טיפול בכשלים ובחזרות. בהמשך נפרק כיצד נסגר כל סוג של כשל בבוט המסחר — ברמת סכמת העבודה, ולא טלאים נקודתיים.

מה נותנת אינטגרציה מנוהלת: מהירות ויציבות

מערך החילופין עם Kraken עובד מחדש כך שלכל כשל תהיה תוצאה צפויה. הפרדנו בין מינויים לשוק לפעולות מסחר: פרץ עומס בזרם הציטוטים כבר לא מעכב שליחת הזמנות, וניתוק חיבור לא משאיר את הבוט במצב לא ידוע. להלן חמישה אפקטים שנמדדים, ולא מורגשים.

• ביצוע הזמנות. המספר הסידורי של הבקשה (nonce) מנוהל באופן עוקב בהחלט ומשוחזר לאחר הפעלה מחדש — תגובות «חתימה שגויה» ו«בקשה מיושנת» נעלמות לחלוטין מהסטטיסטיקה.
• תגובה לכשל. ניתוק ערוץ מזוהה בשניות, מינוי מחדש והשוואת מצב מתבצעים אוטומטית; ההתאוששות אורכת דקות במקום שעות של ניתוח לוגים ידני.
• סוג כשל שנעלם. קצב הבקשות נשמר מתחת למגבלות הבורסה עם מרווח: במקום תגובות «יותר מדי פעמים» פועלת תור עם הפחתת תדירות הדרגתית.
• היעדר כפילויות. לכל הזמנה יש מזהה לקוח משלה, לכן חזרה לאחר חריגת זמן לא הופכת לעסקה שנייה — גם אם תגובת הבורסה לא הגיעה.
• בקרת פוזיציות. המרשם המקומי מושווה למצב בבורסה לאחר כל ניתוק ובאופן מתוזמן: הפער נראה לפני שהוא הופך להפסד.

בתנועות חדות בשוק ההתנהגות נשארת זהה: הבוט לא מדביק את המחיר בסדרת בקשות ולא פותח פוזיציה פעמיים. היציבות של בוט המסחר כאן אינה תכונה של הקוד, אלא תוצאה של כך שלכל ערוץ, מגבלה ומזהה יש כלל התנהגות מפורש.

מצבי חיבור: זרם ציטוטים, תשאול ותבנית היברידית

הבורסה מספקת נתוני שוק ומקבלת הזמנות דרך כמה ממשקים, ובחירת מצב החיבור קובעת עד כמה האסטרטגיה רגישה לעיכובים וכמה מהר היא נתקלת במגבלות תדירות הפניות.

זרם הציטוטים מגיע באמצעות מינוי: ספר ההזמנות וסרט העסקאות מתעדכנים עם השינוי, העיכוב מינימלי, אך החיבור נקטע בתקלות רשת ובעבודות תחזוקה בצד הבורסה, ולכן תמיד משלימים אותו בערוץ תקשורת גיבוי.

תשאול תקופתי צפוי, קל לניפוי שגיאות ואינו דורש החזקת חיבור קבוע — אבל כל בקשה מנצלת את מונה הפניות הכללי. באסטרטגיות שמחשבות מחדש אות לפי כמה מכשירים, המונה הזה מתכלה בשניות, והבוט מתחיל לקבל סירובים במקום נתונים.

תבנית היברידית פותרת את הסתירה הזו: נתוני שוק מגיעים בזרם, והבקשות נשארות רק לשליחת הזמנות, השוואת פוזיציות ושחזור מצב לאחר ניתוק.

אנחנו בוחרים מצב לפי תדירות החלטות האסטרטגיה, ולא לפי נוחות המימוש, — אז מגבלות תדירות הפניות נשארות משאב עבודה, ולא סיבת סירובים. בהמשך נפרק כיצד נספרות המגבלות וכיצד בנוי החיבור מחדש.

שלבי הטמעה: מביקורת ועד מסירה לניהול

הטמעת בוט מסחר אינה הפעלת סקריפט, אלא רצף שבו כל שלב נשען על התוצאה של הקודם. מתחילים בביקורת של המערך הנוכחי ומסיימים במסירה לניהול עם נהלים — כדי שהמערכת תישאר צפויה גם לאחר עזיבתנו.

1. ביקורת אינטגרציה. מפרקים כיצד בנויה הגישה אל Kraken: היכן נשמרים המפתחות, מי משתמש בהם וכיצד, כיצד מטופלות שגיאות וחזרות על בקשות.
2. סכמת חילופין. מקבעים את מודל העבודה: זרמי ציטוטים, סדר שליחת הזמנות, טיפול ב-nonce, מגבלות תדירות בקשות והתנהגות בעת ניתוק חיבור.
3. התאמה למשימה. כללי כניסה ויציאה, מגבלות על גודל הפוזיציה והסיכון היומי, תיעוד יומן של כל עסקה וכל אות.
4. בדיקה על נתונים היסטוריים. הרצת האסטרטגיה על ציטוטים ארכיוניים תוך התחשבות בעמלות, החלקת מחיר ועיכובים — רואים כיצד הלוגיקה מתנהגת במצבי שוק שונים.
5. מערך בדיקות. עבודה בחשבון אמיתי בנפח מינימלי: משווים תגובות בפועל, ביצוע הזמנות והתאוששות לאחר ניתוקים.
6. מסירה לניהול. נהלי הפעלה ועצירה, ניטור והתראות, הוראות לצוות שלכם — בתוספת תקופת ליווי מוסכמת.

כל שלב מסתיים בארטיפקט: סכמת חילופין, קונפיגורציה, דוח על ההרצה. לפיהם נראה מה בדיוק נבדק ועל אילו נתונים — זהו הבסיס למסור את הבוט לתפעול.

ארטיפקטים של הטמעה: סכמות, מפתחות גישה, נהלים

לאחר מסירת העבודה נשארת אצל המזמין ערכה שלפיה ניתן לפתח ולתחזק את האינטגרציה עם צוות משלו, בלי לפנות למחברים. להלן סט מינימלי של ארטיפקטים לכל אינטגרציה של Kraken API: לא מצגות, אלא מסמכי עבודה עם גרסאות ובעלים.

• סכמות חילופי נתונים: רצף בקשות ותגובות, נקודות מינוי לזרמי שוק, לוגיקת שליחה חוזרת לאחר ניתוק חיבור וסימן לבקשה מיושנת.
• קונפיגורציה של סביבות: פרמטרים של מערכי בדיקה ועבודה, מגבלות תדירות פניות, חריגות זמן, הגבלות על גודל פוזיציה וסימון מה משתנה לפי המשימה ומה קבוע.
• מדיניות גישה: מטריצת «תפקיד — פעולה», הפרדת מפתחות לקריאה ומסחר, איסור משיכת כספים במפתח מסחר, סדר מתן ושלילת הרשאות.
• נוהל רוטציית מפתחות: תדירות החלפה, מי יוזם, כיצד ההחלפה מתבצעת בלי לעצור את הבוט ומה לעשות בחשד לדליפה.
• תיעוד האינטגרציה: תיאור מודולים, פורמטי הודעות, פירוק שגיאות הבורסה, מגבלות ידועות ופתרונות עוקפים שהתקבלו.
• יומנים והוראות למשמרת תורנית: אילו אירועים נרשמים, כיצד להבדיל בין תקלת רשת לשגיאת לוגיקה, סדר הפעולות בעת עצירת מסחר.
• תוכנית נסיגה: כיצד להחזיר קונפיגורציה קודמת, היכן נשמרים צילומי מצב ובכמה זמן הבוט חוזר למצב עבודה.

מקרה בוחן: כיצד הבוט הפסיק לאבד הזמנות בתנועות חדות

מקרה בוחן של בוט מסחר שהציב וביטל הזמנות ב-Kraken. בתנועות חדות הוא איבד הזמנות: חלק מהבקשות החתומות נדחו בגלל חוסר סנכרון של מונה ה-nonce, חלק מהביטולים לא הספיקו לפני שהמחיר ברח, ובעת ניתוק זרם הציטוטים הבוט נותר עד שתי דקות בלי ספר הזמנות מעודכן.

במהלך סשן של 8–10 שעות עד 14% מההזמנות לא הגיעו לבורסה, וההתאוששות לאחר כשל ארכה בממוצע 90 שניות — בשוק תנודתי זה מספיק כדי להיכנס במחיר לא משתלם.

התחלנו מתיעוד: כל פעולה יוצאת, תגובת הבורסה והעיכוב ביניהן נרשמים ביומן. התברר שמונה החתימות הוגדל באופן מקומי, ובתהליכונים מקבילים חלק מהבקשות יצאו עם ערך שכבר נוצל. גם הטיפול במגבלות היה תגובתי: הבוט קיבל סירוב וחזר על הבקשה, במקום לפזר את הבקשות לאורך זמן.

מה שינו

הצבנו מנהל בקשות יוצאות אחיד — הוא מחזיק תור חתימות, מנפיק nonce באופן עוקב בהחלט ומרסן מראש את הקצב לפי מגבלות הבורסה.

את זרם הציטוטים העברנו לחיבור קבוע עם חיבור-מחדש אוטומטי והשלמת עדכוני ספר הזמנות שהוחמצו, והביטולים קיבלו עדיפות על כניסות חדשות: קודם מסירים סיכון, אחר כך מחפשים נקודת כניסה.

מה השתנה

שיעור ההזמנות שלא הגיעו לבורסה ירד מ-14% ל-0.3%, זמן התאוששות הקשר לאחר ניתוק — מ-90 ל-3–5 שניות, סירובים בגלל מגבלות פחתו בערך פי 40. העיקר: התנהגות הבוט הפסיקה להיות תלויה במצב השוק — בשיאים העיכוב של החתימה והשליחה נשמר בשברירי שנייה.

מה לעשות אם הבוט כבר סוחר ב-Kraken ומשגה בגלל nonce?

שגיאת nonce — כמעט תמיד אינה שגיאת אסטרטגיה, אלא חוסר סנכרון של המונה. Kraken מקבל עבור מפתח אחד רק nonce שגדל באופן מונוטוני: אם לצד הבוט חי תהליך שני או מופע גיבוי על אותו מפתח, המונה מתפצל וחלק מההזמנות נדחות. המסוכן אינו הביטול, אלא התוצאה — בקשה שנדחתה יכלה להתבצע לפני שהתגובה הגיעה לבוט.

הפירוק מתחיל מהיומן, ולא מעצירת המסחר: משווים לפי זמן בקשות יוצאות עם nonce ומזהה לקוח, תגובות הבורסה ורשימת ההזמנות שלנו.

יציבות נותנת אידמפוטנטיות של פעולות: לכל הזמנה יש מזהה לקוח משלה, ושליחה חוזרת מתבצעת רק איתו — כפילות מחזירה את התוצאה המקורית, ולא יוצרת עסקה שנייה. nonce במקרה זה מונפק על ידי מונה מונוטוני אחד עם כתיבה לדיסק, אחרת סערת חזרות נתקלת מהר במגבלת תדירות הבקשות.

אבחון מתבצע בלי לעצור את המסחר: מופע צל על מפתח נפרד, השמעת היומן, השוואה עם תמונת הבורסה לפני הפעלת המערך הראשי. צוואר הבקבוק בדרך כלל אחד — תגובה שאבדה להזמנה שבוצעה בהצלחה; לאחר סגירתו הסירובים מפסיקים, וההזמנות התקועות מפסיקות להצטבר.

ספקות טכניים נפוצים לפני ההתחלה

הצד הטכני של המזמין לפני ההתחלה בודק לא את האסטרטגיה, אלא את יציבות המערך: היכן נמצאים המפתחות, מה הבוט עושה בעת ניתוק חיבור וכיצד הוא מסתדר עם מגבלות. להלן תשובות לשאלות הנשאלות בתדירות הגבוהה ביותר.

מה קורה בעת ניתוק חיבור?

הבוט עובר למצב השוואה ואינו שולח הזמנות עד להתאוששות הקשר. ערוץ נתוני השוק מתחבר מחדש עם השהיה גדלה, ואז הפוזיציות וההזמנות הפתוחות מושוות לבורסה. לכל הזמנה מוקצה מזהה לקוח משלה, לכן שליחה חוזרת אינה יוצרת כפילות. על ניתוק ארוך מהסף שנקבע התורן מקבל התראה.

אפשר להוסיף בורסה שנייה לאותו מערך?

מחבר לכל פלטפורמה — מתאם נפרד תחת ממשק משותף: הזמנות, יתרה, הבאת טיקרים וצעד מחיר לצורה אחידה. ליבת לוגיקת המסחר לא משתנה. חתימת הבקשות והמספר הסידורי שונים בין הבורסות — זה נפתר בתוך המתאם, ולא באסטרטגיה.

כיצד אתם נשמרים במגבלות הפניות?

אנחנו סופרים את משקל הבקשות, ולא את מספרן: במתודות פרטיות וציבוריות הוא שונה. על כל מחבר שמים מגביל קצב, עדיפות ניתנת לביטול ולשליחת הזמנות, אנליטיקה ודיווח עוברים לזרם רקע. זרם הנתונים עובר דרך WebSocket, ולא בתשאול, — זה מסיר את העומס העיקרי על המגבלות.

נדון במשימה: מה להכין להערכה ולתוכנית

כדי לחזור עם הערכה ותוכנית עבודה, ולא עם שאלות הבהרה בעוד שבוע, די בנתוני מקור בארבעה צירים: מה כבר כתוב, כיצד סוחר, תחת איזה עומס ומי נותן הרשאות גישה.

להלן סט מינימלי שמכסה כמעט את כל החסרים; אם משהו חסר, זו גם תשובה מועילה: לפי החסרים רואים אילו בלוקים נחשבים מאפס ואילו נעשה בהם שימוש חוזר.

• קוד נוכחי או תיאורו: שפה, ספריות, מה עובד מקומית ומה כבר רץ על השרת — לפי זה רואים אם אנחנו משלימים או כותבים מחדש.
• לוגיקת האסטרטגיה בכל צורה קריאה: כללי כניסה ויציאה, חישוב גודל הפוזיציה, תנאי סטופ.
• מפתחות נפרדים עם הפרדת הרשאות: מסחר, קריאת יתרה, משיכה — בזוגות נפרדים, כדי שמשיכה לא תשב בקוד שסוחר.
• יומני עבודה ליממה-שתיים: שגיאות nonce, הזמנות שנדחו, ניתוקי חיבור, שיעור ניסיונות חוזרים.
• סכמת המערך: היכן חי הבוט, היכן נשמר מצב הפוזיציות, האם יש צומת גיבוי וכיצד הפוזיציה משוחזרת לאחר נפילת תהליך.
• ציפיות לעומס: כמה זוגות מסחר, כמה אותות בדקה, האם נדרש זרם ציטוטים בזמן אמת או שמספיק תשאול תקופתי.
• הרשאות גישה לביקורת: מפתח בדיקה, חשבון עם הרשאות מצומצמות וארגז חול — בהיקף שמספיק לבדיקת השערות בלי סיכון לכספים.
• דרישות לבקרה: מגבלות על פוזיציה, מי וכיצד עוצר את הבוט, אילו אירועים צריכים להיכנס להתראות.

תארו את משימת האינטגרציה בצורה חופשית — נחזור עם הערכת היקף ותוכנית עבודה: שלבים, מה אנחנו עושים, מה נשאר בצד שלכם, היכן נקודות הקבלה וכיצד בודקים את התוצאה במערך בדיקות.