הגנת DeFi מפני rug pull: ניטור on-chain ו-off-chain

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1375
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1349
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    794
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1087
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1032
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1129

מדוע הגנת rug pull לא עובדת לאחר פריסת הטוקן

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

הרשאות הנפקה והבעלות על הבריכה נשארות בכתובת אחת. כל בדיקה חד-פעמית מתעדת תמונה לרגע: אפשר לא לקרוא לפונקציית ההטבעה הנוספת, אבל להשאיר אותה בחוזה; לא לשרוף LP-טוקנים, אלא להחזיק אותם בארנק הבעלים; לא לנעול נזילות ב-time lock. rug pull נסתר של הבריכה מכינים מראש: התנאי מופעל מאוחר יותר, כשמצטבר נפח בבריכה.

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

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

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

מה נותן גילוי מוקדם של משיכת נזילות

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

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

ערכות חוקים מוכנות מזרזות את ההתחלה: רשת גלאים Forta מחזירה התראות כאירועים שנותר להירשם אליהם בשער ההתראות שלכם.

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

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

מצבי בקרה: מבדיקות פנימיות ועד בריכות ביטוח

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

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

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

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

הטמעה: מביקורת חוזים ועד כוננות מבצעית

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

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

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

מה נשאר לכם לאחר הטמעת ההגנה

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

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

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

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

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

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

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

מה השתנה

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

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

במה ניטור on-chain שונה מניתוח off-chain?

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

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

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

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

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

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

ספקות טכניים: התראות שווא וגבולות הבקרה

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

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

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

כמה התראות שווא נותן הניטור בחודשים הראשונים?

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

מה לעשות עם חוזה שכבר נפרס?

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

האם אתם צריכים מפתחות פרטיים כדי להגן על הפרוטוקול?

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

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

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

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

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