אינטגרציה של 0x Protocol: Swap API, RFQ ו-Permit2 ל-DeFi

למה האינטגרציה של 0x Protocol נשברת בניתוב

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

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

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

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

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

מה נותן חיבור ישיר לאגרגטור נזילות

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

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

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

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

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

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

מצבי ביצוע דרך 0x Protocol: זרם הצעות מחיר ומאגרים

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

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

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

איך אנחנו מובילים את ההטמעה: מביקורת ההחלפה ועד המסירה

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

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

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

מה מקבלים לידיים: קונפיגורציות, תרשימים, תקנונים

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

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

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

מקרה בוחן: איך עלה שיעור ההחלפות המוצלחות וירדו הכישלונות

מה היה: מסלול שלא נבנה מחדש

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

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

מה שינו

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

מה קרה בסוף

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

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

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

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

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

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

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

ספקות טכניים: מגבלות, חתימות, דחיות ונזילות

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

כמה חיה הצעת מחיר ומה קורה לאחר פקיעתה?

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

איך בנויות הרשאות Permit2 והאם ניתן לבטלן?

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

איך מנוטרים הניתוב והגישה לפי תפקידים?

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

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

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

מה צריך מכם להתחלה:

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

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