אינטגרציה של STON.fi SDK: איפה המסחר נשבר ולמה
אינטגרציה של STON.fi SDK נראית ישרה: לקרוא את רזרבת הבריכה, לבנות הודעה, לשלוח לבלוקצ'יין. הכל נשבר בזמן — בין קריאת הציטוט לביצוע העסקה מצב הבריכה מספיק להשתנות.
אם הפלט המינימלי לא מחושב מחדש לפני השליחה, העסקה נופלת בבדיקה: העסקה לא בוצעה, העמלה נגבתה, ובלוגים — שגיאות מסחר בבוט, שקל לתלות ברשת או בצומת.
הפער השני — מרוץ על מצב הבריכה. מספר מופעים של הבוט, בקשות מקבילות ופעולות ידניות מהארנק קוראים את אותה רזרבה, אבל מיישמים אותה בזמנים שונים. בזמן שעסקה אחת מאושרת, השנייה נבנית על נתונים מיושנים — וה-slippage גדל לא בגלל תנודתיות השוק, אלא בגלל שהבוט פועל לפי תמונה מיושנת.
הקטע השלישי — השהיה באישור העסקה. הודעות קשורות מבוצעות לא באופן מיידי, ועד לסטטוס הסופי הבוט לא יודע אם העסקה עברה, נדחתה בגלל הגבלת פלט או נתקעה במצב ביניים.
בלי לנתח את המעברים האלה הבוט או משכפל ניסיונות, או מחשיב את העסקה כסגורה לפני הזמן — והאמינות של בוט המסחר נשענת בדיוק על הטיפול במצבים האלה.
כל שלושת הקטעים קשורים: שגיאה בציטוטים מגבירה את המרוץ, והמרוץ מתחזה לאישור ארוך. ננתח איך כל אחד מהם נסגר בקוד.
מה משתנה לאחר חיבור ישיר של הבוט לבורסה
כל עוד הבוט פונה לבורסה דרך חוליה מתווכת — אגרגטור, שירות חיצוני או אישור ידני — כל עסקה עוברת שלבים מיותרים. כל שלב מוסיף השהיה ונקודת כשל משלו. בשוק תנודתי, בזמן הזה הציטוט זז, וההזמנה מבוצעת במחיר שאף אחד לא לקח בחשבון בלוגיקה.
חיבור ישיר ל-STON.fi מסיר מתווכים: הבוט בעצמו קורא את מצב הבריכה, בעצמו יוצר וחותם על העסקה. שרשרת העסקה מתקצרת ל"קרא — חישב — שלח", לכן מהירות הביצוע מפסיקה להיות תלויה בשירות זר והופכת צפויה במידה שהרשת עצמה צפויה.
השליטה בעומק ספר ההזמנות מגיעה מאותו מקור נתונים. רזרבות הבריכה גלויות לפני שליחת ההזמנה, לכן ה-slippage מחושב מראש, והזמנה גדולה מפוצלת לחלקים לפי סף מוגדר. התוצאה ההנדסית: העסקה לא "אוכלת" מהתחתית יותר ממה שמוגדר בכללי האסטרטגיה.
העמידות של הבוט בעומס נשענת על תור בקשות, ניסיונות חוזרים בעת תקלת רשת ושליחה אידמפוטנטית — ניסיון חוזר לא יוצר עסקה שנייה. בד בבד מוסר סוג שלם של כשלים הקשור לאובדן תגובת המתווך: המצב תמיד נלקח מהשרשרת, ולא ממטמון זר. בהמשך ננתח איך זה נבנה למעגל עובד.
אפשרויות חיבור: שירות עצמאי, אגרגטור, שכבת פרוקסי
בחירת אופן החיבור קובעת מי אחראי על מסלול המסחר ומה יקרה כשחלק מהבריכות לא יהיו זמינות. אינטגרציה של STON.fi דרך סט ספריות מוכן — דרך מובנת מאליה, אבל לא היחידה: למשימה מתאימות שלוש סכמות, וכל אחת מעבירה את המורכבות למקום אחר.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| עבודה ישירה עם חוזים | נדרש שליטה מלאה על מסלול המסחר, כללי retry משלכם ומספר מינימלי של מתווכים בשרשרת | אתם בעצמכם עוקבים אחרי שינויים בממשקי הבורסה ובמצבי הבריכות: שינוי בצד החוזים שובר את הבוט לפני שנגיב לו |
| אגרגטור נזילות | חשוב המחיר הטוב ביותר על פני כמה בריכות, והלוגיקה של המסחר אינה החלק התחרותי שלכם | את המסלול בוחרת לוגיקה זרה, חלק מהעמלה עובר למתווך, הרכב הבריכות וכללי הניתוב משתנים בלי התראה |
| שכבת פרוקסי לבקשות | צריך לסגור את הבוט מפני פניות ישירות לרשת, להחליק את תדירות הבקשות ולהחזיק חוצץ ציטוטים | מוסיפה השהיה ועוד נקודת כשל: כשהפרוקסי לא זמין, הבוט מאבד קשר עם הבורסה ועובד לפי נתונים מיושנים |
המגבלות לא נעלמות כשמחליפים אפשרות — הן עוברות לשכבה אחרת. לכן קונפיגורציות עובדות הן כמעט תמיד היברידיות: עבודה ישירה עם חוזים בפעולות קריטיות, פרוקסי לקריאה ולניטור, אגרגטור כמסלול גיבוי כשבריכה דקה.
איך עובר המימוש: מביקורת לוגיקה ועד השקה
אנחנו מתחילים לא בקוד, אלא בניתוח של איך הבוט מקבל החלטות. ביקורת לוגיקת מסחר לאינטגרציה של STON.fi SDK מראה היכן חישוב המחיר והנפח סוטה מהביצוע בפועל בבורסה, ומגדירה רשימה של מה שנכתוב מחדש.
- ביקורת לוגיקת מסחר. מנתחים את כללי הכניסה והיציאה, חישוב הנפח, התחשבות בעמלת הרשת וב-slippage. בפלט — מפת ההחלטות של הבוט ורשימת מקומות שסותרים את ההתנהגות בפועל של הבורסה.
- סכמת המסחר עם הבורסה. מתעדים אילו בקשות נשלחות, אילו אישורים מחכים, מה עושים בביצוע חלקי ובעסקה שנדחתה. את הסכמה מאשרים לפני הקוד — תיקונים בשלב הזה הם הזולים ביותר.
- אחסון מפתחות. מפתחות לא נכנסים לקוד, לקונפיגים או ליומנים: החתימה מוצאת לתהליך נפרד, הגישה מוגבלת לפי תפקידים, ומשיכת כספים — רק באישור ידני.
- הגדרה ובנייה. סביבות נפרדות, הגבלות על תדירות הפניות, ניסיונות חוזרים בעת תקלות ויומן עסקאות מפורט — ניתוח תקלה לוקח דקות, לא שעות.
- בדיקת עסקאות. הרצה על עסקאות אמיתיות בנפח קטן: משווים מחיר ונפח צפויים מול בפועל. בנפרד בודקים ניתוק קשר והפעלה מחדש של הבוט ברגע של פוזיציה פתוחה.
- מסירת הפתרון. מוסרים גישות, תיעוד של סכמת המסחר, יומנים והוראות לתקלות אופייניות — הצוות שלכם מתחזק את הבוט בעצמו.
אחרי השלב השישי יש בידיים אינטגרציה עובדת, סכמת מסחר מתועדת ויומנים, ולא אוסף תיקונים בלי תיעוד.
מה נשאר אצל הצוות: קונפיגורציות, סכמות, נהלים
אינטגרציה נחשבת למסורה רק כאשר הלקוח מסוגל להפעיל, לשנות ולתקן אותה בלעדינו. לכן בקבלה נכלל לא בוט עובד אחד, אלא חבילת ארטיפקטים למשימה מסוימת — אינטגרציה של STON.fi SDK עם בוט מסחר: קונפיגורציות, סכמות, מדיניות גישה ונהלים שלפיהם מהנדס תורן פועל בעצמו.
- קונפיגורציית הבוט. הפרמטרים מוצאים מהקוד: רשימת זוגות, ספי הפעלה, מגבלות על נפח העסקה, כתובות צמתי הרשת ומקורות ציטוטים חלופיים. הערכים משתנים בלי בנייה מחדש, עם בדיקת תקינות בהפעלה.
- סכמות אינטגרציה. דיאגרמות זרימה: מסלול קבלת המחיר, סדר החתימה ושליחת העסקה, התנהגות בעת כשל של בריכת נזילות וניסיון חוזר.
- מדיניות גישה. תפקידים והרשאות, הפרדה בין מפתחות חתימה למפתחות קריאה, מגבלות נפח, רשימת כתובות מורשות, מעגל נפרד לעצירה ידנית של הבוט.
- נוהל תחזוקה. מה לנטר, אילו התראות קריטיות, איך לעדכן קונפיגורציה, היכן נקודות שחזור ואיך לחזור למצב עבודה קודם.
- תיעוד. תיאור משתני סביבה, הוראות הפעלה מקומית, סדר פריסה, מילון מונחים וטבלת קודי שגיאה עם פירוש.
- סט בדיקות. תרחישי כשל: חוסר נזילות, ציטוט מיושן, ניתוק קשר עם הצומת, שליחה חוזרת של עסקה.
- ניהול סודות. היכן נשמרים המפתחות, איך מסובבים אותם, מי הבעלים ומה קורה כשמחליפים אחראי.
הכל מועבר למאגר של הלקוח עם הרשאות בעלים. אפשר להשאיר את התחזוקה אצלנו או לנהל אותה בכוחות עצמכם — הנהלים מיועדים למהנדס שלא השתתף בפיתוח.
מקרה בוחן: בוט בבורסה, איך נעלמו הכשלים והעיכובים בעסקאות
הלקוח הגיע עם בוט מסחר בבורסה מבוזרת ברשת TON. האותות עבדו, אבל הביצוע אכזב: המחיר שהבוט חישב לפי מצב הבריכה האחרון שנקרא התיישן עד לרגע שליחת ההזמנה. חלק מהעסקאות נדחו בגלל slippage, וביצועים שלא תאמו נותחו ידנית לפי דוחות.
הניתוח הראה שתי סיבות. בקשות ל-STON.fi נשלחו באופן סדרתי, כל אחת חיכתה לתגובה של הקודמת, לכן התור צבר השהיה, ומצב הבריכה נקרא לעתים רחוקות יותר מאשר השתנה.
כתבנו מחדש את מעגל הביצוע: במקום סקרים תקופתיים — מנוי לאירועי הבריכה, במקום הזמנות בודדות — תור עם זמן חיים משותף, במקום השוואה ידנית — התאמה אוטומטית של העסקה מול הביצוע בפועל וניסיון חוזר בעת דחייה בגלל מחיר.
מדדים לפני ואחרי
| פרמטר | לפני | אחרי |
|---|---|---|
| שיעור עסקאות לא מוצלחות | כל חמישית | אחוזים בודדים |
| זמן תגובת הבוט | עשרות שניות | 1–2 שניות |
| פער בין הציטוט לביצוע | קבוע | בתוך סטייה מוגדרת |
| התאמת עסקאות | דוחות ידניים פעם ביום | אוטומטית, ניתוח רק של חריגים |
העמידות נשענת לא על פרמטר אחד, אלא על שילוב: גבול זמן חותך עסקאות מיושנות מראש, ניסיון חוזר מופעל רק בחריגה מגבול המחיר, ויומן ההתאמה מראה היכן הציפייה והמציאות נפרדו. המעגל מועבר לזוגות ולבוטים אחרים — הספים משתנים, הלוגיקה נשארת.
במה עבודה דרך SDK שונה מקריאות דרך אגרגטור?
עבודה ישירה דרך STON.fi SDK נותנת שליטה על כל עסקה: הבוט בעצמו קורא את מצב הבריכות, מחשב מסלול, קובע פלט מינימלי וזמן חיים של העסקה. ה-slippage מפסיק להיות הפתעה, וההתנהגות בתנועת מחיר חדה — צפויה.
המחיר לכך — תחזוקה בצד שלכם. כתובות הבריכות משתנות, עבור זוג לא סטנדרטי יש לבנות את שרשרת ההחלפות ידנית, וטעות בחישוב מתגלגלת לדחיית העסקה ולאובדן עמלת הרשת. ככל שהבוט משרת יותר זוגות, כך יותר לוגיקה חיה בתוכו.
אגרגטור עובד אחרת: שירות חיצוני בעצמו עובר על הבריכות, מדביק מסלול מכמה החלפות ומוסר פרמטרים מוכנים של העסקה. פחות קוד, כיסוי זוגות רחב יותר, אבל מופיעה תלות — השהיית תגובה, מגבלות על תדירות בקשות, התנהגות זרה בעומס והיעדר ערובה שהמסלול יישאר הטוב ביותר עד לרגע הביצוע.
אגרגטור מוצדק כשהנזילות מפוזרת על פני בריכות קטנות רבות או כשהזוגות משתנים מעסקה לעסקה. אם הבוט עובד עם שניים-שלושה זוגות עיקריים, קריאות ישירות לחוזים גם מהירות יותר וגם עמידות יותר.
בפועל בוחרים בסכמה היברידית: זוגות מפתח — בקריאות ישירות דרך SDK, מסלולים נדירים — דרך אגרגטור, אבל עם בדיקת רזרבות ומגבלות בצד שלנו. הזרימה העיקרית לא תלויה בשירות זר, והזנב הארוך של הזוגות מכוסה בלי ניתוב עצמאי.
ספקות טכניים שכדאי להסיר לפני ההתחלה
חלק מהשאלות צפות כבר בשלב ההערכה — לפני שורת הקוד הראשונה. מוטב להסיר אותן מיד, כדי לא להניח הנחות שגויות בתוכנית. להלן ארבעה נושאים שאנחנו עוברים לרוב לפני תחילת העבודה על אינטגרציה של STON.fi SDK.
איך נשמרים מפתחות הארנק של הבוט?
המפתח הפרטי לא נכנס למאגר וגם לא לקונפיגים — רק למאגר סודות, שממנו קורא אותו תהליך החתימה. הבוט עובד עם ארנק נפרד ומגבלה על היתרה: גם במקרה של פגיעה, היקף ההפסדים מוגבל ואינו שווה לכל המחזור. הגישה לסוד ניתנת לפי תפקידים, המפתח מסובב לפי נוהל, והיסטוריית החתימות נשארת ביומן.
אפשר לחבר כמה בורסות בו-זמנית?
כן, ובדרך כלל גם כדאי לעשות זאת. מעל הבריכות מוצבת שכבת ניתוב: לפני העסקה משווים ציטוטים, ההזמנה נשלחת למקום שבו המחיר והעומק טובים יותר בהתחשב בעמלת ההעברה. אם פלטפורמה אחת לא זמינה או נותנת slippage מעל הסף, הלוגיקה עוברת לשנייה בלי שהבוט יעמוד מלכת.
מה קורה כשהבורסה מעדכנת חוזים?
כתובות הבריכות ופורמט הקריאות משתנים, וערכים שמוטבעים קשיח הופכים לכשל. לכן כתובות ופרמטרים אנחנו מחזיקים במרשם אחד, ולא מפזרים אותם בקוד, ומעת לעת משווים אותו לנתונים ציבוריים של הרשת. לפני העלאה מריצים תרחישי מסחר במעגל בדיקות — העדכון מגיע בלי לעצור את הבוט.
איך לעקוף מגבלות בקשות לבורסה?
המגבלות נמדדות לפי תדירות הפניות, לכן ציטוטים נשמרים במטמון לזמן קצר, ובקשות מאותו סוג מאוחדות לחבילה. התור לשירות החיצוני מוגבל במהירות, ובמקרי כשל — ניסיונות חוזרים עם השהיה גדלה. פעולות דחופות (חתימה ושליחת עסקה) עוברות בערוץ נפרד ולא מתחרות בסקרים ברקע.
נדבר על המשימה: מה צריך לתוכנית עבודה והערכה
כדי לחזור עם תוכנית מימוש והערכה, ולא עם נוסחים כלליים, אנחנו צריכים סט נתוני קלט על הבוט שלכם ועל תרחישי העבודה עם STON.fi. ככל שנתוני הקלט מדויקים יותר, כך מדויקים יותר הרכב העבודה וסדר השלבים — מבדיקות ברשת בדיקות ועד להשקה תעשייתית. להלן מה שאנחנו בדרך כלל מבקשים בשיחה הראשונה.
- תרחישי הבוט: מסחר לפי שוק, הזמנות לימיט, הוספה ומשיכה של נזילות, העברות — מה צריך בהתחלה ומה עובר לשלב שני.
- מודל גישה לארנק: סכמה לא-משמורתית עם חתימה בצד המשתמש או ארנק שירותי; היכן נשמרים המפתחות ומי אחראי על סבב החלפתם.
- זוגות וטוקנים: רשימת נכסים, בריכות מועדפות, slippage מותר וגודל עסקה מינימלי.
- מגבלות והגנה: סכום פעולה מקסימלי, מספר פניות בדקה, כללי עצירה באנומליות והתנהגות כשצומת הרשת לא זמין.
- ממשק והתראות: היכן חי הבוט, אילו תפקידי משתמשים, אילו אירועים נשלחים לצ'אט ואילו נכתבים רק ליומן.
- סביבות וגישות: רשת בדיקות, גישה לצמתים, מאגר עם בנייה, מתקן לבדיקות עומס.
- דיווח: אילו מדדים חשובים — שיעור עסקאות מוצלחות, זמן אישור פעולה, מספר כשלים והסיבות.
לפי הנתונים האלה נתעד את הרכב העבודה, נחלק אותה לשלבים ונמנה לוחות זמנים לכל אחד. תארו את המשימה — נחזור עם תוכנית מימוש והערכה.