פיתוח פלטפורמת חיסכון בקריפטו עם ERC-4626

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

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

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

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

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

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

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

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

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

אוטומציה של צבירת תשואה: התשואה מגיעה לפי לוח זמנים

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

זמן משיכת כספים: מחזור צפוי

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

אמינות רישום היתרות

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

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

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

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

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

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

שלבי הטמעה: מביקורת המכניקה ועד מסירת הפלטפורמה

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

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

קונפיגורציות, סכימות ותקנות: מה נשאר אצל המזמין

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

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

מקרה בוחן: גידול פי שלושה בפיקדונות בלי גידול בפעולות ידניות

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

מה הוחלף ברישום

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

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

מה מחזיק את זה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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