פיתוח מערכת ייצוב הצמדת סטייבלקוין

מדוע הצמדת הסטייבלקוין נשברת בתנודתיות

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

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

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

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

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

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

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

מה נותן מעגל הייצוב המבוקר

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

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

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

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

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

יציבות הפריטי מפסיקה להיות הבטחה והופכת לסט של מדדים: זמן מסטייה לתגובה, חלק הטווח שנשמר, מספר המגבלות שהופעלו, היעדר פעולות מחוץ לכללים. именно эти показатели показывают, что система работает, а не что нам повезло с рынком.

דרכים לשמירה על הצמדה: השוואת גישות

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

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

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

שלבי פיתוח מערכת ייצוב

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

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

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

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

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

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

ארטיפקטים: קונפיגורציות, סכמות, מדיניות גישה

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

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

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

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

מה היה לפני

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

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

מה שינו

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

מה נהיה

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

במה שונה ייצוב אלגוריתמי מייצוב מגובה

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

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

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

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

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

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

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

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

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

כיצד תתבצע ההגירה אם כבר יש לנו מעגל פעיל?

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

האם המערכת תעמוד בעומס שיא ובגידול בהיקף הפעולות?

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

מה עם הרשאות גישה ואבטחה בעת האינטגרציה?

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

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

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

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

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

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

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