פיתוח בוט מסחר ל-DEX על Arbitrum: אסטרטגיות והגנה מפני MEV

מדוע בוט מסחר על Arbitrum מפסיד רווח ב-DEX

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

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

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

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

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

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

תוצאה מדידה: רווח לעסקה ועמידות בתקלות

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

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

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

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

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

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

אפשרויות אסטרטגיה: ארביטראז', עשיית שוק, סנייפינג

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

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

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

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

שלבי העבודה: אבחון התרחיש, סכמה, הפעלה, פיקוח

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

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

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

מה אנחנו מוסרים: קוד מקור, סכמות, מפתחות, תקנונים

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

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

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

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

מה היה לפני

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

מה שינינו

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

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

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

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

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

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

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

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

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

ספקות טכניים: נזילות, עמלות, השבתות

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

היכן נשמרים המפתחות ולמי יש גישה אליהם?

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

מה קורה אחרי תקלה או הפעלה מחדש?

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

כיצד אתם מגבילים החלקה?

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

מה מגן מפני הקדמת עסקאות בתור?

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

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

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

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

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

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