האנטומיה של חסימת USDT: כיצד Tether מקפיאה טוקנים

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

מאז 2017 יזמה Tether חסימה של כ-8,000 כתובות בלוקצ'יין בשווי כולל של יותר מ-4 מיליארד דולר.

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

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

כיצד עובדת העברת USDT רגילה

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

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

TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

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

באופן מפושט, התהליך נראה כך:

1. המשתמש יוזם העברת USDT;
2. העסקה קוראת לחוזה החכם של USDT;
3. החוזה מאמת את תנאי ההעברה;
4. אם אין הגבלות, יתרת השולח פוחתת ויתרת הנמען גדלה;
5. אירוע Transfer נרשם on-chain.

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

מנגנוני בקרה בחוזה החכם של USDT

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

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

• AddedBlackList — הוספת כתובת לרשימה השחורה;
• RemovedBlackList — הסרת כתובת מהרשימה השחורה;
• DestroyedBlackFunds — שריפת כספים בכתובת חסומה.

באופן מפושט, הלוגיקה נראית כך:

1. Tether מוסיפה כתובת ל-BlackList;
2. החוזה החכם מתחיל לזהות כתובת זו כחסומה;
3. כאשר מתבצע ניסיון להעברה יוצאת, החוזה בודק את מצב הכתובת;
4. אם הכתובת נמצאת ב-BlackList, ההעברה נדחית;
5. אם הכתובת אינה ב-BlackList, ההעברה יכולה להתבצע.

מ-preban ל-ban: כיצד החסימה מופיעה on-chain

חסימת USDT ב-TRON נרשמת לא כשלב אחד אלא כשני שלבים on-chain קשורים: תחילה נוצרת פעולה ב-MultisigWallet של Tether; לאחר מכן פעולה זו מבוצעת ומובילה להוספת הכתובת ל-BlackList.

ניתן לחלק רצף זה באופן מותנה לשני אירועים:

1. Preban — יצירת הפעולה ב-MultisigWallet של Tether.
2. Ban — הביצוע בפועל של הפעולה, שלאחריו הכתובת נכנסת ל-BlackList.

Preban: יצירת הפעולה ב-MultisigWallet של Tether

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

פרמטרים מרכזיים של עסקת preban:

ב-event logs של עסקת ה-preban נרשמים אירועי חוזה ה-multisig. TransactionId הוא המזהה הפנימי של הפעולה ב-MultisigWallet של Tether שתבוצע מאוחר יותר.

היכן מוסתרת הכתובת שתיחסם

הכתובת שתיחסם אינה מוצגת ישירות ב-event logs של עסקת ה-preban. היא מוסתרת בתוך הפרמטר Data, אותו יש לפענח על פי כללי Solidity ABI.

אם הפעולה מכינה קריאה לפונקציית blacklist, מבנה הנתונים נראה כך:

0xecb93c0 + 32-byte address argument
(<function selector> + <ABI-encoded arguments>)

4 הבתים הראשונים הם ה-function selector. השאר הוא הארגומנט המקודד ב-ABI. כדי לחלץ את הכתובת, קחו את 20 הבתים האחרונים של הארגומנט ופענחו אותם.

ב-TRON, כתובות יכולות להיות מוצגות בשתי צורות:

• פורמט Hex — מתחיל בקידומת 41;
• פורמט Base58Check — קריא לאדם, מתחיל ב-T.

Ban: ההוספה בפועל של הכתובת ל-BlackList

החסימה בפועל מתרחשת מאוחר יותר, כאשר פעולת ה-multisig שנוצרה מבוצעת. בעסקת ה-ban, לוגי החוזה של USDT מציגים:

AddedBlackList(address target)

אירוע זה הוא האישור on-chain לכך שהכתובת התווספה ל-BlackList.

חלון ההזדמנויות: הזמן מ-preban ל-ban

בין preban ל-ban קיים מרווח זמן. לפני שאירוע AddedBlackList מופיע, הכתובת עדיין אינה ב-BlackList ומבחינה טכנית שומרת על היכולת להשתמש ב-USDT. מרווח זה הוא מה שאנו מכנים חלון ההזדמנויות.

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

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

מה קורה לאחר ה-ban בפועל

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

מה שקורה בהמשך תלוי בעילות לחסימה:

• הכתובת עשויה להישאר ב-BlackList ללא הגבלת זמן;
• הכתובת עשויה להשתחרר דרך RemovedBlackList;
• הכספים עשויים להישרף דרך DestroyedBlackFunds, עם אפשרות להנפקה מחדש לכתובת חדשה.

לאחר ה-ban בפועל, העבודה עוברת למסלול המשפטי והאנליטי: זיהוי מקור הסיכון, הכנת אנליטיקה on-chain, אישור מקור הכספים, ותקשורת עם Tether ועם מבני המדינה שיזמו את החסימה — בשיתוף ייעוץ משפטי רלוונטי.

כיצד לזהות שהכתובת שלך נחסמה על ידי Tether

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

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

העברות USDT יוצאות נכשלות, בעוד שפעולות אחרות (שליחת טוקנים נטיביים, קבלת כספים נכנסים) עובדות כרגיל.

— הסימן העיקרי לחסימה

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

חשוב להבחין בין חסימה לבין בעיות טכניות רגילות:

• אין מספיק טוקן נטיבי (TRX, ETH) לתשלום עמלות;
• הארנק אינו שולח את העסקה (באג בממשק, ב-RPC או בארנק);
• עומס ברשת או תקלות תשתית זמניות.

כיצד לבדוק חסימה דרך החוזה החכם של USDT

שלב 1. פתחו את החוזה החכם של USDT ב-TRON בתוך Tronscan: TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t

שלב 2. עברו ללשונית Contract.

שלב 3. פתחו את הקטע Read Contract.

שלב 4. מצאו את המתודה getBlackListStatus. ב-Tronscan היא עשויה להופיע כ-«8. getBlackListStatus (59bf1abe)».

שלב 5. הזינו את הכתובת שברצונכם לבדוק ובצעו את השאילתה.

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

כיצד לנטר פעילות חסימת USDT בזמן אמת

כל אירוע — preban, ban, unban, destroy — נרשם באופן ציבורי on-chain. משמעות הדבר שכל אחד יכול לבנות ניטור:

• גישה ישירה — הפעילו archive node של TRON ו-Ethereum, הירשמו ל-event logs של חוזה ה-USDT דרך WebSocket. הזול ביותר בעלות, דורש תשתית.
• דרך שירותי צד שלישי — QuickNode Streams, Alchemy webhooks, Infura. בתשלום, אך ללא תשתית משלכם.
• דרך מוצר מוכן — אנחנו עושים זאת בזמן אמת מאז 2017: פיד התראות בטלגרם, REST API, שרת MCP לכלי AI, HuggingFace dataset לחוקרים.

קריאה נוספת

• מי באמת מחליט על חסימת USDT — על מקורות החסימות: רשויות אכיפת החוק, סנקציות, הערכת הסיכון הפנימית של Tether.
• שחרור המוני ב-14 במאי 2026 — 497 כתובות ב-72 דקות — מקרה מעשי של אירוע נדיר, מפורק מנתוני on-chain.