פרסינג שיעור מימון: API, סקריפטים, ארביטראז' בבורסות קריפטו

ניתוח funding rate: היכן נתוני הבורסות חלוקים

שיעור המימון (funding rate) של חוזי perpetual אינו גודל אחיד לכל השוק, אלא תוצאה של חישוב מקומי בכל פלטפורמה. חלון המיצוע ורגע הקיבוע שונים בין הבורסות: חלקן מחשבות פעם ב-8 שעות לפי מחיר ממוצע משוקלל על פני החלון, ואחרות — פעם ב-4 שעות או בכל שעה לפי snapshot של המדד. אין דוח אחיד של "שיעור לפי שוק".

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

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

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

מה נותן איסוף מסודר של שיעורי המימון

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

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

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

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

שיטות איסוף: polling לפי לוח זמנים, stream, snapshot לפי דרישה

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

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

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

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

כיצד נבנה הטמעת האיסוף: שלבי עבודת הנדסה

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

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

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

3. הגדרת האיסוף. מיישמים polling לפי לוח זמנים ומנויי stream, מוסיפים ניסיונות חוזרים עם השהיה, סינון כפילויות וכתיבת התשובות המקוריות — כדי שבכשל ניתן יהיה לבנות מחדש את ה-view ולא לאבד את המרווח.

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

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

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

מה הלקוח מקבל לידיו: סכימות, נהלים, ניטור

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

• סכימת נתונים ומילון שדות — טבלה עם תיאור כל שדה: בורסה, זוג מסחר, חתימת זמן ב-UTC, תקופת התשלום, שיעור, מקור. לצדה — כללי המרת טיפוסים, עיגול וטיפול בחסרים, כדי שנתונים ממקורות שונים יתחברו בלי עריכה ידנית.
• כללי נרמול של tickers — טבלת התאמה בין סימוני הזוגות בבורסות למזהה פנימי אחיד, כולל מקרים עם סיומות של חוזי settlement. ticker חדש מתווסף בשורה אחת, והלוגיקה של הפרסור אינה תלויה בו.
• מדיניות גישה לנתונים — הפרדה בין מפתחות קריאה וכתיבה, הגבלת הרשאות לפי שירותים, תוחלת חיים של מפתחות ונוהל rotation שלהם. המפתחות אינם נכנסים לקוד וללוגים, והגישה להיסטוריה ניתנת בנפרד מהגישה לאיסוף בזמן אמת.
• נוהל הפעלה מחדש של האיסוף — סדר פעולות שלב אחר שלב בעת כשל: כיצד לזהות את נקודת הפער, מאיזו חתימה לחדש את הטעינה, כיצד לבדוק את שלמות הקטע שהושלם ולוודא שכפילויות לא נכנסו למאגר.
• ניטור האיסוף — dashboard עם שיהוי לכל בורסה, שיעור בקשות מוצלחות, מספר המרווחים שהוחמצו ונפח השורות שנכתבו ביממה. ההתראות מוגדרות לסטייה מהקצב הרגיל, ולא לעובדת עצירת התהליך.
• מדריך לחיבור בורסה חדשה — תבנית adapter, תיאור הבדיקות המחייבות ודוגמת בקרה שמראה שהנתונים נקלטו כראוי.

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

מקרה בוחן: פער שיעורים בין פלטפורמות לפני ואחרי

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

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

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

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

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

Funding rate ידני: מה לעשות אם האיסוף כבר מסודר?

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

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

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

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

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

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

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

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

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

מה לעשות עם מגבלות הפלטפורמות על קצב הבקשות?

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

האם ניתן לשחזר את היסטוריית השיעורים בדיעבד?

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

מה קורה לאחר המסירה — מי אחראי לאיסוף?

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

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

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

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

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