פיתוח בוט מסחר בחוזים עתידיים לבורסות קריפטו

מדוע בוט מסחר בחוזים עתידיים מאבד רווחיות בשוק האמיתי

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות התגובה ובקרת הסיכון

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

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

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

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

מצבי עבודה: אותות, חצי-אוטומטי, אוטומציה מלאה

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

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

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

שלבי העבודה: מביקורת האסטרטגיה ועד מסירה לתפעול

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

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

מה נשאר אצלכם: קוד, תצורות, תיעוד, נהלים

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

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

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

מקרה בוחן: בוט חוזים עתידיים בבורסה עם תנועות מחיר חדות

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

מה היה לפני העיבוד מחדש

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

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

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

מה השתנה

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

מה לעשות אם בוט עצמאי כבר פועל בבורסה?

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

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

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

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

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

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

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

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

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

האם אפשר לחבר את הבוט לכמה בורסות בבת אחת?

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

מה יקרה לפוזיציות פתוחות אם עוצרים את הבוט?

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

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

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

נדון במשימה שלכם ונחזור עם הערכה ותוכנית

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

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

מה כדאי לצרף לתיאור כדי שהשיחה תהיה עניינית:

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

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