בוט Telegram לניטור פוזיציות DeFi: מה נשבר
שליטה ידנית בפוזיציות נשענת על אדם שצופה במקדם הביטחונות בממשק הפרוטוקול וזוכר בראש את ספי הכניסה. בין «שמתי לב לסטייה» ל«הפקדתי תוספת בטחונות» מונחת שרשרת: לבדוק, לבחור רשת, להרכיב טרנזקציה, להמתין לאישור. בשוק רגוע היא בלתי נראית, בתנועה חדה — זו בדיוק נקודת הכשל.
הכשל היקר ביותר — אירוע שהוחמץ. הסף נחצה לא בהדרגה, אלא בעדכון אורקל אחד: המחיר זז, מקדם הביטחונות צנח מתחת לרמה המותרת, והפוזיציה נכנסת לליקווידציה לפני שהתורן בכלל פותח את האפליקציה. בלילה, בסופי שבוע, בזמן שיחת וידאו האדם נמצא פיזית מחוץ למעגל, והליקווידציה לא ממתינה.
הסוג השני — חוסר סנכרון של נתונים בין המקורות. השער בפלטפורמה אחת, ריבית ההלוואה בפרוטוקול, מצב הפוזיציה בממשק שלישי — כולם מתעדכנים בהשהיה שונה, וחישוב «בעין» מייצר שגיאה לכיוון המסוכן. המהנדס מקבל החלטה על סמך חתך מיושן וחושב שיש מרווח.
השלישי — השהיית התגובה. גם כשהאות הגיע, הפקדה ידנית אורכת דקות: לבחור רשת, להעריך עמלה, לחתום, להמתין לכלילה בבלוק. עד לרגע האישור התנאים כבר שונים, והסף עשוי היה לזוז.
בדיוק שלושת המצבים האלה — החמצת אירוע, חוסר סנכרון, השהיה — מגדירים את הדרישות מבוט Telegram לניטור DeFi: סקירת מקורות, ספים עם היסטרזיס, אסקלציה בהיעדר אישור. נבחן כיצד זה נסגר בארכיטקטורה.
בקרת בריאות פוזיציות: מה משתנה לאחר ההטמעה
לפני ההטמעה מצב הפוזיציות נבדק ידנית: נכנסים לממשק הפרוטוקול, משווים את מקדם הבריאות, מעריכים את המרווח עד לסף הליקווידציה.
לאחר ההטמעה הבוט סוקר את הפוזיציות לפי לוח זמנים ובמקביל מאזין לאירועי הפרוטוקול — הפער בין שני המקורות האלה הופך בעצמו לאות שהנתונים מיושנים או סותרים זה את זה.
מהירות התגובה לסיכון מפסיקה להיות תלויה במי שפתח ראשון את האפליקציה.
ברגע שמקדם הבריאות יורד מתחת לרמה שהוגדרה, ההודעה ב-Telegram מכילה את כתובת הפוזיציה, את הערך הנוכחי, את הסף ואת המרווח עד הליקווידציה — זה מספיק כדי לקבל החלטה בלי להעלות שירותים חיצוניים ובלי להשוות מספרים ידנית.
בדיקות ידניות הופכות לפחותות לא מפני שכיבו אותן, אלא מפני שמגיע רק מה שמהותי. הספים ותדירות ההתראות ניתנים להגדרה: בשוק רגוע אין הודעות, בתנועה חדה ההתראה עוברת לנושא נפרד בצ'אט, שם רואה אותה התורן ולא כל הצוות.
סוג הכשל שהוסר — החמצת חציית סף ברגע שבו השוק נע מהר מהאדם שמספיק להגיב. בעבר החמצה כזו הסתיימה בליקווידציה כפויה; כעת כל הפעלה נרשמת ביומן עם חותמת זמן, וממנה רואים כמה מרווח נותר לפעולה.
אל אותו מקום נסגרת גם השתיקה בעת תקלה: אם מקור המחיר אינו מגיב או מחזיר ערך ישן מהמותר, הבוט מדווח על הידרדרות הניטור, ולא מעמיד פנים שהפוזיציה תקינה.
מצבי התראה: השוואת גישות לבקרה
מצב הבקרה קובע כמה מהר הבוט מבחין בסיכון וכמה עולה התחזוקה שלו. אנחנו משלבים שלוש גישות — סף, מינוי לאירועי הרשת וסריקה מתוכננת: כל אחת פותרת את חלקה במשימות, ולכל אחת מגבלות שיש להתחשב בהן בעת ההגדרה.
התראת סף מחשבת מחדש את הפוזיציה לפי המחיר האחרון ומופעלת כאשר מקדם הביטחונות יורד מתחת לרמה שהוגדרה. המצב זול מבחינת עומס, אך שותק עד שהמחיר זז, ובשוק דק מייצר הפעלות שווא. מינוי לאירועי הרשת מגיב לשינוי במצב החוזים — ליקווידציות, סוואפים גדולים, שינוי בפרמטרים של הבריכה.
שערים נלקחים ממספר מקורות ומושווים ביניהם: DefiLlama כנקודת ייחוס עיקרית, ומקור גיבוי — למקרה של סתירה.
| מצב | מתי מתאים | מגבלות המצב |
|---|---|---|
| התראת סף | פוזיציה אחת או שתיים, נדרש אות מהיר לפי רמת הביטחונות | תלוי בתדירות ובאיכות מקור המחירים; ייתכנו הפעלות שווא |
| מינוי לאירועי הרשת | פוזיציות גדולות, שבהן כל בלוק חשוב | נדרש צומת יציב וטיפול בארגון מחדש של השרשרת; זרם ההתראות דורש מסנן רלוונטיות |
| סריקה מתוכננת | תיק של עשרות פוזיציות, סקירה ודיווח | בין סריקות האירוע נשאר בלתי מזוהה |
| מודל חישובי | נכסים עם תשואה משתנה, שבהם נדרש תחזית ולא מצב נוכחי | רגיש להנחות; שגיאה בפרמטרים מייצרת החמצה שיטתית |
בפועל הסריקה המתוכננת משמשת כבסיס, הסף נותן אות מהיר, והמינוי תופס את מה שנראה רק בחוזה עצמו. את המגבלות אנחנו סוגרים במפורש: מסנן רלוונטיות, מקור מחירים כפול, יומן הפעלות לניתוח הפעלות שווא — ההתראה נשארת סיבה לפעול, ולא רעש.
כיצד אנחנו בונים בקרת פוזיציות: שלבי העבודה
מתחילים במיפוי האופן שבו בקרת הפוזיציות בנויה כיום: היכן מנוהלים הרישומים, מי לומד על הסיכון ובאיזה ערוץ, כמה זמן חולף בין שינוי הפוזיציה להודעה בצ'אט. בשלב זה גם מבררים אילו הפעלות היו שווא ומדוע — לרוב הסיבה היא מקור נתונים יחיד או סף שמופעל בתנועה רגילה של השוק. לאחר מכן מרכיבים את סכמת חישוב הפוזיציה ובודקים אותה על תקופות עבר, לפני שמעמידים אותה בתורנות.
- ניתוח הבקרה הנוכחית. מתעדים את רשימת הפלטפורמות וסוגי הפוזיציות, ערוצי ההתראה, זמן התגובה והיסטוריית ההפעלות בתקופות עבר. בפלט — רשימת חסרים: היכן האות מגיע בהשהיה, והיכן הוא כלל לא קיים.
- סכמת חישוב הפוזיציה. מגדירים מקורות שערים, מבנה הבטחונות והחוב, התחשבנות בריביות ובעמלות, כלל בחירת הערך בעת סתירה בין מקורות. מחשבים את מרווח הביטחון של הפוזיציה עד לסף הליקווידציה ומציגים אותו בהודעה.
- כללי התראה וספים. מפרידים אירועים לפי רלוונטיות: התקרבות לסף, שינוי חד בערך, אי-זמינות של מקור. הבעלים והתורן מקבלים מערכי התראות שונים, ולכל אות יש סיבה וקישור לחישוב.
- בדיקה על נתונים היסטוריים. מריצים את הסכמה על תקופות עבר ומשווים לתנועות בפועל בפוזיציות. מודדים את שיעור אותות השווא וההחמצות, ומכווננים ספים כך שהרעש לא יסתיר אירועים מהותיים.
- יומן ושחזוריות. כל התראה נשמרת עם פרמטרי החישוב וגרסת הכללים — מהרשומה אפשר להבין מדוע האות הופעל ולחזור על החישוב.
- נוהל תורנות. מתארים את סדר האסקלציה, הוראות לתקלות אופייניות של מקור, חלונות בדיקה וזמן תגובה. התורן מקבל צ'ק-ליסט, ולא אוסף של סקריפטים מפוזרים.
- העברה והדרכת המשמרת. מקיימים ניתוח על דוגמאות חיות, מוסרים תיעוד של סכמת החישוב והכללים, ומתעדים מי וכיצד משנה את הספים בהמשך.
בסופו של דבר נשארת לצוות סכמת חישוב שחזורית, שנבדקה על ההיסטוריה, ונוהל תורנות — הספים והערוצים משתנים בלי לשכתב את הבוט.
מה נשאר אצלכם לאחר העברה לתפעול
העברה לתפעול אינה ארכיון עם קוד מקור, אלא סט של מסמכי עבודה שלפיהם הצוות שלכם עצמו משנה כללים, מנתח תקריות ומחבר מקורות נתונים חדשים. הכול מונח באותו מאגר שבו נמצא הקוד, ועובר את אותה בדיקה לפני שינוי — אחרת התיעוד מתנתק מהמציאות בתוך שבועות ספורים.
- קונפיגורציות של הבוט והניטור: פרמטרי חיבור, רשימת הארנקים והבריכות במעקב, מגבלות בקשות למקורות חיצוניים, מצבי ניסיונות חוזרים בעת אי-זמינות של צומת.
- כללי התראה: ספים לפי בריאות הפוזיציה, מקדם הליקווידציה, סטיית המחיר ועלות הגז; בנפרד מתואר אילו אירועים מושתקים כדי שהתורן לא יוצף בכפילויות וברעש.
- סכמת חישוב: כיצד מחושבת בריאות הפוזיציה, מהיכן נלקחים המחירים והריביות, מה קורה בעת סתירה בין מקורות ובאיזה שלב נכנסת הערכה שמרנית.
- הוראות למשמרת התורנות: תרחישים שלב-אחר-שלב לאירועים אופייניים — אי-זמינות של צומת, השהיית נתונים, הפעלה של סף קריטי, התראת שווא.
- נוהל תגובה: רמות חשיבות, זמן לאישור אירוע, סדר אסקלציה ותבניות הודעות, כדי שהמשמרת תפעל באותו אופן ללא תלות בהרכב.
- צפיות של הבוט עצמו: בדיקות זמינות, בקרת השהיית מסירת ההתראות ויומן הפעלות עם היסטוריה שממנה רואים אם היה אות או שהחמיצו אותו.
- נוהל שיפורים: כיצד להוסיף פרוטוקול או רשת חדשים, אילו בדיקות להריץ לפני שחרור ולאן להסתכל אם לאחר שינוי החישובים התעוותו.
מקרה בוחן: בקרת פוזיציות בתנועות חדות של השוק
לקוח ניהל פוזיציות נזילות במספר פרוטוקולי DeFi ופיקח עליהן ידנית: מהנדס תורן פתח את הפאנלים כל 30–40 דקות והשווה את מקדמי הביטחונות לספים. בתנועה חדה של השוק המרווח הזה לא הספיק — בין שתי סריקות המקדם פרץ את הסף, והפוזיציות נסגרו לפני שמישהו הספיק להתערב.
התגובה הממוצעת לאירוע סף הגיעה עד 40 דקות, וחלק מהאירועים כלל לא נכנסו לשדה הראייה: סריקה ידנית אינה מכסה את שעות הלילה ואת הקפיצות בשיא.
מה נבנה
הבוט נרשם לאירועי הפרוטוקולים ומחשב מחדש את המקדם עבור כל כתובת בשינויים מהותיים במצב. הספים מוגדרים בנפרד לכל פוזיציה ופועלים עם היסטרזיס — תנודות ממש על הגבול אינן הופכות לזרם של הודעות שווא.
התורן מקבל התראה ב-Telegram עם הכתובת, המקדם הנוכחי והמרווח עד לסף; אם ההתראה אינה מאושרת, האסקלציה עוברת לבא בתור במשמרת.
מדדים לפני ואחרי
- כיסוי אירועי סף: ידנית נעשה מעקב אחר כשני שלישים, הבקרה האוטומטית מתעדת את כולם.
- זמן תגובה: מ~40 דקות ל-2–3 דקות מרגע הפריצה.
- החמצות בשעות הלילה: סוג הכשל נעלם לחלוטין.
- הפעלות שווא: פחתו בערך פי שלושה לאחר כיוונון ההיסטרזיס והסף לפי המרווח.
- סגירות כפויות בגלל התערבות מאוחרת: ממקרים בודדים בחודש לאפס.
במה שונה התראת סף מבקרה חישובית?
התראת סף היא כלל מעל מספר אחד: המחיר ירד מתחת לסימון, שיעור הבטחונות ירד, הריבית עלתה. אפשר להגדיר אותה בדקות, העומס צפוי, ואין צורך לקרוא את מצב הפוזיציה במלואו. המגבלה היא שהסיכון של פוזיציה כמעט לעולם אינו מתבטא במספר אחד.
פוזיציה מורכבת מהיקף הבטחונות ומשקלם, מגוף החוב ומהריבית המצטברת, שבריבית משתנה גדלה בצורה לא אחידה. אותה רמת מחיר תחת חוב שונה משמעה קרבה שונה לליקווידציה. הסף או מופעל מוקדם מדי ושוקע בהודעות שווא שמפסיקים להגיב אליהן, או שותק עד שהמרווח כבר נגמר.
בקרה חישובית מחשבת מחדש את הפוזיציה: שולפת נתונים עדכניים על הבטחונות והחוב, מתחשבת בריבית המצטברת ובפרמטרי הנכסים, ומצמצמת הכול למדד אחד — מרווח הסיכון באחוזים. ההתראה מגיעה לא ברגע חציית המחיר, אלא כשהמרווח הזה יורד מתחת לרמה שהוגדרה, בתיקון לפי זמן התגובה. החישוב מחדש מופעל גם לפי אירוע וגם לפי לוח זמנים — קפיצת שוק אינה מקדימה את ההתראה.
ההשוואה בין הגישות נשענת על מחיר הטעות. סף מתאים לפוזיציה פשוטה: בטחונות אחד, שינויים נדירים, ריבית צפויה. חישוב נדרש כאשר יש כמה בטחונות, הריבית משתנה, וחשוב לא לקבוע עובדה בדיעבד אלא להספיק להגיב. בפועל משלבים ביניהם: הספים פועלים כמסנן גס, והחישוב מחדש מאשר את האירוע ומדייק את מרווח הסיכון.
ספקות טכניים לפני ההתחלה
לפני ההתחלה בודקים לא כיצד הבוט מצייר גרף, אלא כיצד הוא מתנהג כאשר הנתונים על פוזיציות DeFi מאחרים או נעלמים. נבחן ארבעה ספקות שעולים לעתים קרובות ביותר.
מהי ההשהיה בין אירוע ברשת לבין ההתראה?
הבוט נרשם לאירועי הרשת ולא סוקר ארנקים לפי לוח זמנים: ההתראה על יציאת מחיר מהגבול מגיעה 2-4 שניות לאחר האישור. הסקירה התקופתית נשארת כרשת ביטחון ותופסת את מה שהוחמץ אם המינוי נותק.
מה אם הנתונים הספיקו להתיישן?
לכל מספר יש חותמת זמן ומקור, והבוט אינו מציב בשקט את הערך הידוע האחרון. אם המחיר לא התעדכן, מגיעה הערה «הנתונים אינם עדכניים» עם מועד העדכון האחרון — את ההחלטה אתם מקבלים על בסיס עובדה, ולא על בסיס אשליה של נתונים טריים.
כיצד מופרדות הרשאות הגישה?
התפקידים מתוארים ברשימה: הבעלים רואה את כל הפוזיציות והספים, האנליסט — מדדים מצטברים בלי כתובות, והצופה — רק את הארנקים שלו. ההרשאות ניתנות לפי מזהה, נשללות בפקודה אחת ונרשמות ביומן.
מה קורה בעת תקלת תקשורת?
ההתראות נכנסות לתור ויוצאות עם ניסיונות חוזרים, והכפילויות מאוחדות — אירוע אחד אינו הופך לעשרה הודעות. כאשר המקור העיקרי אינו זמין, הבוט עובר לגיבוי, וכאשר שניהם כושלים מגיע «הנתונים אינם מגיעים» מפורש, ולא שתיקה שקל לפרש בטעות כשוק רגוע.
נדון במשימה שלכם: מה להכין
כדי לחזור עם הערכה ותוכנית לבוט ה-Telegram שלכם לניטור DeFi, ולא עם הנחות ממוצעות, די לשיחה הראשונה במה שכבר יש בהישג יד. להלן נתוני המוצא שמסירים מחצית מסבבי ההבהרה ומאפשרים למנות מיד את ארכיטקטורת הסקירה ואת סדר העבודות.
- דרך הבקרה הנוכחית: כיצד אתם יודעים כעת על ירידת בטחונות — ידנית عبر כמה חלונות, בטבלה בצ'אט, בסקריפט של מישהו על השרת שלכם, או בכלל לא.
- נתוני מוצא על הפוזיציות: רשתות ופרוטוקולים, סוגי בטחונות וחוב, באילו טוקנים, האם יש מינוף ומצב הלוואות רקורסיביות.
- ערכי סף: באיזה מקדם בריאות נדרש אות, ואיזה טווח נחשב לרעש שגרתי ואסור שיעיר את התורן בלילה.
- הרכב משמרת התורנות: מי מקבל התראות, באילו אזורי זמן, למי יש הרשאה לפעול על הפוזיציה ולמי — רק לקרוא את הסקירה.
- מהירות תגובה צפויה: כמה זמן לפני הליקווידציה צריך האות להגיע — מכך תלויים מרווחי הסקירה והאם נדרשת אסקלציה מהודעה לשיחה טלפונית.
- ערוצי מסירה ב-Telegram: צ'אט אישי, קבוצה משותפת עם נושאים, מסלולים נפרדים לאירועים קריטיים ואירועי מידע.
- הרשאות גישה: כתובות ארנקים לקריאה בלבד ומפתחות לקריאה בלבד — חתימת הטרנזקציות נשארת אצלכם, והבוט אינו מקבל הרשאות להזזת כספים.
תארו את המשימה בצורה חופשית, צרפו את מה שיש: נחזור עם הערכה ותוכנית ובה יפורטו השלבים, מרווחי הסקירה וסדר הקבלה. אם חלק מהנתונים עדיין אין, נתחיל ממה שיש ונסגור את החסרים במהלך הניתוח.