למה מערכת קיבוע השער נשברת בשוק תנודתי
מערכת קיבוע השער מבטיחה דבר אחד: הלקוח מאשר קיבוע שער ההמרה ומקבל בדיוק את המחיר שראה על המסך. כל עוד השוק רגוע, ההבטחה מחזיקה. ברגע שהמחיר מתחיל לזוז בתוך דקה, השרשרת "מקור מחיר, חישוב, אישור, ביצוע" נקרעת בכמה מקומות בבת אחת.
הראשון — פער בין קוטציות ממקורות שונים. בורסה, מאגר נזילות ואגרגטור נותנים ערכים שונים, וחלון הממוצע מוסיף השהיה: עד רגע החישוב המספר כבר לא תואם את השוק. ככל שהפיזור בין הפלטפורמות רחב יותר, הפער בין הקוטציות גדול יותר, ולעתים קרובות יותר המערכת מכניסה מחיר שכבר אינו קיים בשוק.
השני — עיכוב באישור. בין אישור העסקה לבין הכנסתה לבלוק עובר זמן, ובשוק תנודתי זה שווה אחוזים מהתנועה. מכאן נובעת החלקת מחיר: הלקוח מקבל ביצוע גרוע מהמחיר שנקבע, ואם הפער עולה על סף ההגנה, מופעל ביטול העסקה.
הדבר הכואב ביותר הוא דווקא ביטול העסקה בשיא התנועה. הלקוח רואה סירוב בדיוק כשהמחיר נע לטובתו, ועובר למי שביצע. גרוע יותר אם הסירוב מגיע באיחור: הנזילות שמורה, השער קבוע, והעסקה לא נסגרת — יתרת החישוב לא מתאזנת, וצריך לטפל בזה ידנית.
אנחנו מפרקים איך השרשרת הזו נסגרת.
מה נותן מחיר עסקה נשלט: אפקט בזמנים ובשיעורים
קוטציה חתומה היא התחייבות, לא תמונה על המסך. מקור השער (Chainlink) מוסר ערך יחד עם תו זמן ותוקף, וחוזה ההמרה מקבל רק הזמנות שהחתימה שלהן תואמת והחלון שלהן לא פג. אם הבדיקה לא עברה — ההמרה לא נוצרת כלל: המשתמש רואה שגיאה ברורה במקום עסקה שבוצעה חלקית במחיר שזז.
זמן אישור העסקה מתקצר, כי להזמנה יש מסלול דטרמיניסטי אחד: בדיקת חתימה, שריון אמצעים, חישוב. אין המתנה להתאמת שער חיצונית ואין חישובים חוזרים — מחיר העסקה הצפוי ידוע לפני השליחה.
החלון מרגע הלחיצה ועד האישור מצטמצם מעשרות שניות ליחידות בודדות, וזו הבטחה שנקבעת לפי תוקף הקוטציה, לא ממוצע לפי עומס.
שיעור ההזמנות המבוטלות יורד מסיבה אחרת: הלקוח כבר לא קורע עסקה בגלל תנועת שוק בין הצגת המחיר לאישור. הביטול נשאר פעולה מודעת, וקוטציה שפגה לא הורגת את ההזמנה אלא מחזירה אותה לחישוב מחדש לפי שער עדכני. המרות שלא הושלמו פוחתות פי כמה, וכל הזמנה מאושרת מגיעה לחישוב.
טיפולים ידניים בפניות עוברים לאוטומציה. לקוטציה יש מזהה, כל החתימות ומעברי הסטטוסים נכתבים ביומן, ולכן עסקה שנויה במחלוקת משוחזרת לפי היומן תוך דקות, ולא משתחזרת מהתכתבות. פניות בסגנון "לאן נעלם המחיר" נעלמות בשגרה, והתמיכה עוסקת בתקלות אמיתיות.
שלושה מדדים — זמן, שיעור ביטולים, טיפולים ידניים — מוצגים בלוח ניטור, כך שהאפקט של מחיר נשלט נראה במספרים, לא במילים.
מצבי החזקת מחיר: קשיח, מתגלגל ומותנה
מצב ההחזקה קובע מי נוטל על עצמו את הסיכון בתנועת השער בין חישוב המחיר לביצוע ההמרה. במערכת הוא מוגדר בשני פרמטרים: חלון החזקת המחיר — כמה זמן הערך הקבוע חי, ומגבלת עסקה — איזה נפח אפשר לסגור במחיר הזה בלי חישוב מחדש. להלן שלושה מצבים והגבולות שמעבר להם כל אחד מהם מפסיק לעבוד לטובה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| החזקת מחיר קשיחה | הסכום לקבלה ידוע מראש: תשלומים, חישובים עם מכסה קבועה, פעולות עם סבילות נמוכה לסטייה | סיכון תנועת השוק כולו בצד הפלטפורמה, ולכן החלון קצר ומגבלת העסקה נמוכה משאר המצבים |
| החזקת מחיר מתגלגלת | נפחים גדולים ותקופות תנודתיות, שבהן חשוב יותר לבצע את העסקה מאשר להחזיק ערך מסוים | הסכום הסופי אינו מובטח: המחיר עוקב אחרי השוק בתוך מסדרון הגנה, ומעבר לגבולו העסקה נעצרת ודורשת אישור |
| החזקת מחיר מותנית | קיבוע לפי אירוע: הגעה לסף, זמן מוגדר, סטטוס של צד נגדי או שלב בחישובים | נדרש מקור נתונים חיצוני ולוגיקת ביטול מפורשת — אם התנאי אינו זמין, ההזמנה פגה ולא מבוצעת לפי המחיר האחרון |
המצבים אינם סותרים זה את זה: הליבה מפעילה החזקת מחיר קשיחה על הזמנות טיפוסיות, מתגלגלת — על גדולות, ומותנית עובדת כביטוח בתרחישים עם חישוב נדחה. המעבר מוגדר בכלל ברמת העסקה, ולכן אותה אינטגרציה מכסה סכמות המרה שונות בלי לכתוב מחדש את הלוגיקה.
לפני העלאה לפעולה אנחנו מריצים בסטנד פקיעת חלון, פיצול הזמנה לפי מגבלה וחוסר זמינות של מקור מחיר — שלושת המקרים האלה בדיוק יוצרים פערים בהתחשבנות.
סדר היישום: מביקורת זרימת הזמנות ועד מסירה
מתחילים בביקורת של זרימת ההזמנות: בודקים איך הקוטציה עוברת מהמקור ללקוח, היכן השער נקבע בפועל ובאיזה רגע הוא יכול להשתנות בלי שאף אחד מהצדדים ישים לב. התוצאה של השלב — מפת צווארי בקבוק ורשימת תרחישים שבהם הלקוח מקבל שער גרוע מהמוצהר.
- ביקורת זרימת הזמנות — מפרקים יומנים ותורים, מחשבים את שיעור ההזמנות עם פער בשער, מתעדים את העיכוב בין האישור לבין ההחזקה בפועל.
- סכמת חישוב השער — מתארים את מקורות הקוטציות, המשקל שלהם, הספרד וחלון העדכניות; כלל הפסילה של ערכים מיושנים מפורמל במפרט עם דוגמאות.
- הגדרת כללי החזקה — קובעים חלון קיבוע, מגבלות נפח, תנאי ביצוע חלקי וביטול, והתנהגות המערכת בעת ניתוק בזרם הקוטציות.
- בדיקה בעומס — משחזרים פרופיל תעבורה אמיתי עם קפיצות, מודדים זמן מהגשת ההזמנה ועד הקיבוע ומוודאים שכללי ההחזקה לא מדרדרים בשיא.
- נהלים — מתארים לתמיכה ולמשמרת תורנות איך לקרוא יומני פערים, מה לעשות כשמקור נעצר ואיך לתעד מקרים שנויים במחלוקת.
- מסירה — מוסרים קונפיגורציות, סכמת פריסה, תרחישי בדיקה ותיעוד, מאמנים את הצוות ונשארים בקשר לתקופת הליווי.
כל שלב נסגר בארטיפקט שאתם מקבלים: מפת זרימה, מפרט חישוב, סט כללים, דוח עומס, נהלים, חבילת תיעוד. כך התוצאה נבדקת לפני העלאה לייצור, ולא אחרי.
חבילת האספקה: הגדרות, סכמות ונהלי חישוב
אי אפשר להחשיב את מערכת קיבוע השער ככזו שנמסרה אם אפשר רק להפעיל אותה אבל לא להגדיר אותה מחדש. לכן החבילה כוללת ארטיפקטים שלפיהם צוות הלקוח משנה פרמטרים בעצמו, וקבלן חיצוני מתמצא בהם בלי הנדסה לאחור.
- קבצי הגדרות — מקורות קוטציות, חלון החזקת שער, סטייה מותרת, מגבלות נפח עסקה. נערכים בקונפיגורציה, בלי שינוי לוגיקה ובלי פריסה מחדש.
- סכמות של זרימות הזמנות — המסלול מהגשה ועד ביצוע: היכן נבדקים התנאים, היכן משוריין הכיסוי, היכן נקבע השער ומה קורה בסירוב.
- תיעוד החישוב — נוסחאות שער הביצוע והעמלות, סדר העיגול, כללי התאמת מקורות וסימנים לעסקה שאינה ניתנת לביצוע.
- כללי גישה — תפקידי מפעילים, מנהלים ומערכות חיצוניות, מטריצת הרשאות, סדר הנפקה ושלילה של מפתחות, מגבלות חתימה על פעולות.
- נוהל טיפול בעסקאות שנויות במחלוקת — מועדי פנייה, הרכב בסיס הראיות, התאמה ליומן האירועים, תרחיש סגירה של הזמנה תקועה.
- נוהל עדכון וחזרה לאחור — איך מוציאים גרסה חדשה, מי מאשר אותה ובאיזה זמן המערכת חוזרת להגדרות הקודמות.
בנפרד אנחנו מוסרים הוראות פריסה בסביבה שלכם: שינויים נבדקים על עותק לפני העלאה לסביבת העבודה, ולכן הגדרות ונהלים נשארים מסמכי עבודה, לא נספח לדוח.
מקרה בוחן: איך צמצמנו פי שלושה את שיעור העסקאות השנויות במחלוקת
מה היה בקלט
שירות המרה בגודל בינוני: הלקוח לחץ "קבע שער", האפליקציה זכרה את המספר, והביצוע עבר בבקשה נפרדת למקור קוטציות חיצוני. בתנועת שוק חדה החלון בין הקיבוע לאישור נמתח, והשער בעסקה סטה מהשער ברגע החיוב.
עסקאות שנויות במחלוקת הצטברו ל-4.8% מהנפח, כל פנייה טופלה 2-3 ימים — התמיכה השוותה ידנית קבצי יצוא מבורסה, מטמון פנימי ונתוני CoinGecko. עד 11% מההזמנות הלקוחות ביטלו בעצמם בלי להמתין לאישור.
מה שינינו
את קיבוע השער העברנו לחישוב בשרת: ברגע הבקשה נוצרת תמונת שער חתומה עם תו זמן, ואישור העסקה מחושב לפי אותה תמונה, לא לפי בקשה חדשה למקור. ההזמנה הפכה לאידמפוטנטית — מזהה ייחודי מגן מפני חיוב כפול במקרה של ניסיון חוזר בחיבור לקוי.
הוספנו סף סטייה מותרת: אם השער זז מעבר לו, העסקה לא מאושרת אוטומטית אלא עוברת לתור טיפול יחד עם הקשר מוכן.
מה נהיה
שיעור העסקאות השנויות במחלוקת — 4.8% → 1.6%. טיפול בפנייה — מיומיים ל-40 דקות: למהנדס מספיק לפתוח את היומן, שבו נשמרים תמונת השער, תו הזמן ומקור החישוב. מספר ההזמנות המבוטלות ירד מ-11% ל-3%.
פער בין הקיבוע לאישור מופיע ב-0.1% מהעסקאות ותמיד ניתן להסבר לפי היומן — יציבות החישוב הפסיקה להיות תלויה במי ובאיזו שנייה לחץ על הכפתור.
איך מחושב מחדש השער בביצוע חלקי של הזמנה
המחיר המוחזק קשור לא להזמנה כולה, אלא לנפח שעבורו שוריין הכיסוי. כשמגיע ביצוע חלקי של ההזמנה, החוזה קובע את המחיר והנפח של הביצוע הזה ברשומה נפרדת, והשריון משתחרר באופן יחסי: על 40% מהנפח שנסגר יוצאים 40% מהחסימה. יתרת ההזמנה ממשיכה להתקיים כישות עצמאית עם הנפח שלה ותקופת ההחזקה שלה.
לאחר מכן נכנס כלל חישוב השער מחדש. המודל "קוטציה אחת להזמנה" מחזיק את המחיר המקורי עד סוף תקופת ההחזקה — היתרה מבוצעת באותו מחיר כמו החלק הראשון.
המודל "קוטציה לביצוע" מעריך מחדש את היתרה אחרי כל ביצוע חלקי, ונוטל מחיר מהמצב העדכני של המקור: זהו אורקל מאומת כמו Chainlink, ולא מודול חישוב עצמאי.
הבחירה במודל היא פשרה. מחיר קבוע היטב צפוי ללקוח, אבל בתנועת שוק חדה היתרה הופכת למטרה נוחה לארביטראז': את ההזמנה משלימים בכוונה בחלקים, כל עוד הקוטציה הישנה חיה. הערכה מחדש מסירה את הסיכון הזה, אבל מוסיפה להזמנה אי-ודאות — לא ידוע מראש לפי איזה שער ייסגר הזנב.
לכן היתרה מקבלת החזקת מחיר חוזרת עם גבולות מפורשים. אם הסטייה מהשער המקורי עולה על הסף שהוגדר, היתרה לא מבוצעת: המערכת מבטלת אותה ומחזירה את הכיסוי המשוריין, ולא סוגרת לפי מחיר מיושן. כל קריאה קשורה למזהה ההזמנה ולמספר הביצוע, ולכן עיבוד חוזר של אותו אירוע לא מכפיל את השריון.
החוצה זה יוצא כיומן עקבי: כמה בוצע ובאיזה מחיר, כמה נותר, באיזה מחיר מוחזקת היתרה ועד מתי. יומן כזה נותן התאמה חד-משמעית — פער בין דוח הפלטפורמה למצב ההזמנה נראה בשלב מסוים, ולא נעלם בתוך מצרף.
שאלות טכניות נפוצות על החישוב וההגנה מפני פערים
חמש שאלות נשאלות לפני תחילת העבודה: מהאופן שבו בנויה התשובה תלויים ארכיטקטורת החישוב וסט הבדיקות. להלן תשובות קצרות בצורה שבה אנחנו נותנים אותן: בלי ניסוח "נעשה אמין", אלא עם מכניקה קונקרטית.
מאיפה מגיע השער — ממקור אחד או מכמה?
נוטלים מדגם של ספקים בלתי תלויים ומחשבים חציון, לא ממוצע: חריג בודד לא מזיז את התוצאה. אם הפער בין הקוטציות במקורות עולה על הסבילות שהוגדרה, הערך נפסל ולא ממוצע.
מה בדיוק נכנס ליומן החישובים?
כל קיבוע כותב רשומה בלתי ניתנת לשינוי: קוטציות קלט עם תווי זמן, הסבילות שהוחלה, השער הסופי, מזהה הבקשה. היומן רק מתווסף, ותיקון נרשם כרשומת תיקון נפרדת עם הפניה למקור.
איך בנויה ההגנה מפני מניפולציות בשוק דק?
השער מחושב לפי חלון זמן, לא לפי נקודה אחת: רכישה קצרת טווח של נפח לא מזיזה את התוצאה. עבור זוגות עם נזילות נמוכה סף הסטייה מתרחב, והזמנה גדולה עוברת לאישור.
עד כמה הנתונים צריכים להיות עדכניים ברגע הקיבוע?
לחישוב נכנס ערך שאינו ישן מהמרווח שהוגדר — קוטציה מיושנת מסומנת ונפסלת. בעת ניתוק הזרם המערכת עוברת למקור גיבוי ומתעדת את עצם המעבר ביומן.
אפשר לבדוק את החישוב בדיעבד?
כן. לפי רשומת היומן החישוב משוחזר: אותם נתוני קלט נותנים אותו שער. זה מאפשר לנתח מקרה שנוי במחלוקת בלי גישה ללוגיקה הפנימית של השירות.
נדון במשימה: מה צריך כדי להתחיל עבודה
כדי לחזור עם הערכה ותוכנית עבודה, ולא עם ניסוחים כלליים, אנחנו צריכים נתוני מקור על תרחיש הקיבוע שלכם. להלן מה שמסיר את עיקר אי-הוודאות; חלק מהסעיפים נסגור ישירות בשיחה.
- מקורות שער: פנימיים או חיצוניים, כמה זרמים בלתי תלויים, איך נפתר הפער ביניהם.
- לוגיקת קיבוע: מי יוזם, לכמה זמן, מה קורה עם פקיעתה והאם אפשר להאריך.
- התנהגות בסטיית שוק: מסדרון מותר, ביטול אוטומטי, אישור ידני של מפעיל.
- תפקידים והרשאות: מי קובע, מאשר ומבטל קיבוע, אילו מגבלות חלות על המפעיל.
- היכן מחושבת התוצאה: סביבה מבודדת, התחשבנות קסטודיאלית או סכמה היברידית.
- התחשבנות ודיווח: קבצי יצוא להתאמה, יומן של כל הפעולות, דרישות לשמירת היסטוריה.
- עומס: כמה קיבועים ביום וכמה בו-זמנית בשיא.
- מה כבר קיים: חוזים, אינטגרציות, עמדות בדיקה, מגבלות של התשתית שלכם.
לפי הנתונים האלה אנחנו מרכיבים הערכה ותוכנית עבודה: מחלקים לשלבים, קובעים נקודות בקרה ומועדי יישום. בנפרד מחשבים את סביבת הקיבוע, האינטגרציות ועמידות לתקלות — כך אפשר לעלות לאוויר בחלקים, בלי להמתין לכל הנפח. תארו את המשימה בצורה חופשית, ואת השאר נדייק בשאלות.