هک 351.6 میلیون دلاری Bitget؛ آیا لازاروس پشت این حمله است؟

اولین انتقال آن‌قدر کوچک بود که در نگاه اول کاملاً بی‌خطر به نظر می‌رسید: 0.84 Ether از یک کیف پول با نام Bitget به آدرسی که به‌تازگی ایجاد شده بود، منتقل شد. اما این فقط شروع ماجرا بود. کمی بعد، استیبل‌کوین‌ها، طلای توکنیزه‌شده، Ether، Avalanche، BNB و احتمالاً 93.7 میلیون XRP در چندین شبکه جابه‌جا شدند؛ در حالی که کیف پول‌های دریافت‌کننده، دارایی‌ها را با سرعت بالا تبدیل و میان آدرس‌های مختلف منتقل کردند.

اطلاعیه امنیتی Gracy Chen، مدیرعامل Bitget، درباره حادثه 351.6 میلیون دلاری کیف پول گرم، منتشرشده در X در تاریخ 24 سپتامبر 2026

اطلاعیه امنیتی Bitget، ارزش دارایی‌های تحت‌تأثیر این حادثه را حدود 351.6 میلیون دلار اعلام کرده است. در این اطلاعیه آمده است که سیستم‌های صرافی در ساعت 18:31 به وقت UTC در 24 سپتامبر، انتقال‌های غیرمجاز را شناسایی کرده‌اند؛ کیف پول‌های سرد همچنان امن بوده‌اند، موجودی حساب کاربران دقیق و بدون تغییر باقی مانده و برداشت‌ها نیز در جریان بررسی‌های امنیتی متوقف شده‌اند. این موارد اطلاعات مهمی را روشن می‌کنند، اما هنوز توضیح نمی‌دهند که چگونه یک سرویس کیف پول توانسته تراکنش‌هایی را ایجاد کند که Bitget قصد تأیید آن‌ها را نداشته است.

همین ابهام، بخش اصلی ماجراست. Gracy Chen، مدیرعامل Bitget، احتمال داده است که یک سرویس کیف پول در بخش backend درگیر یک حمله زنجیره تأمین شده باشد، نه اینکه کلید خصوصی افشا شده باشد. از سوی دیگر، تحلیلگر درون‌زنجیره‌ای Specter بخشی از مسیر انتقال XRPهای سرقت‌شده را به سرمایه مرتبط با هک AFX در ژوئیه 2026 مرتبط دانسته است. آن حمله قبلتر به TraderTraitor نسبت داده شده بود؛ گروهی که با جمهوری دموکراتیک خلق کره (DPRK) ارتباط دارد. این سرنخ به اندازه‌ای جدی است که نمی‌توان آن را نادیده گرفت، اما شواهد موجود هنوز برای نسبت دادن قطعی حمله Bitget به گروه لازاروس کافی نیست.

هک Bitget؛ ماجرا از کجا شروع شد؟

رد تراکنش‌های این حادثه به‌تدریج و در چند مرحله آشکار شد و همین موضوع باعث شد برآوردهای اولیه، فاصله زیادی با رقم نهایی اعلام‌شده از سوی Bitget داشته باشند. رصدهای اولیه بیشتر روی شبکه‌های سازگار با ماشین مجازی اتریوم (EVM) متمرکز بودند و میزان دارایی‌های تحت‌تأثیر را حدود 170 تا 183.8 میلیون دلار برآورد می‌کردند. Bitget بعدها مجموعه گسترده‌تری از دارایی‌ها و شبکه‌ها را در برآورد 351.6 میلیون دلاری خود لحاظ کرد. این اختلاف لزوماً به معنای وجود تناقض نیست، اما هنوز تطبیق تراکنش‌ها به‌صورت جزئی و تراکنش‌به‌تراکنش منتشر نشده است.

روشن‌ترین بخش از توالی اولیه تراکنش‌ها این‌گونه به نظر می‌رسد:

• انتقال آزمایشی: 0.84 Ether تقریباً هم‌زمان با زمانی که Bitget اعلام کرده سامانه‌های امنیتی‌اش این حادثه را شناسایی کرده‌اند، به یک آدرس تازه‌ایجادشده منتقل شد.

• خروج استیبل‌کوین‌ها: بر اساس گزارش‌ها، این آدرس از کیف پول‌هایی که با نام صرافی شناسایی شده‌اند، حدود 34.75 میلیون Tether و 12.85 میلیون USD Coin و 3,000 واحد Tether Gold دریافت کرده است.

• تبدیل سریع دارایی‌ها: در شبکه Arbitrum، یک آدرس تازه دیگر حدود 19.67 میلیون USDT0 را برای خرید نزدیک به 7,111 واحد Ether از طریق UniswapX و 1inch Fusion به کار گرفته است. بر اساس گزارش‌ها، در برخی از این معاملات تا 5% بیشتر از قیمت معمول پرداخت شده است؛ موضوعی که نشان می‌دهد در این روند، سرعت از بهینه‌بودن قیمت اهمیت بیشتری داشته است.

• شبکه‌های دیگر: بر اساس گزارش‌ها، حدود 821,012 Avalanche و در ادامه 8.2 میلیون USD Coin از زیرساخت‌هایی با نام Bitget در شبکه Avalanche منتقل شده‌اند. فعالیت‌هایی نیز در BNB Chain در بررسی گسترده‌تر جریان تراکنش‌ها مشاهده شده است.

• جریان XRP: بر اساس گزارش‌ها، دو کیف پول با نام Bitget در مجموع 93.7 میلیون XRP را به یک آدرس جدید در XRP Ledger ارسال کرده‌اند. با توجه به قیمت‌های گزارش‌شده در زمان وقوع این حادثه، ارزش این انتقال‌ها حدود 143 میلیون دلار بوده است؛ رقمی که می‌تواند بخش قابل‌توجهی از اختلاف میان برآوردهای اولیه مبتنی بر شبکه‌های EVM و رقم اعلام‌شده از سوی Bitget را توضیح دهد.

افشای اولیه Bitget درباره حادثه کیف پول در 24 سپتامبر 2026، برآورد ارزش دارایی‌های تحت‌تأثیر و توقف موقت برداشت‌ها؛ منتشرشده از سوی Bitget و بررسی‌شده در 25 سپتامبر 2026، حدود ساعت 02:40 UTC.

فعلاً، واژه «تحت‌تأثیر» دقیق‌ترین توصیف برای رقم 351.6 میلیون دلار است. این رقم هنوز محاسبه نهایی میزان ضرر خالص نیست. رقم نهایی باید پس از کسر ارزش دارایی‌هایی که همچنان تحت کنترل Bitget هستند، توسط ناشران یا صرافی‌ها مسدود شده‌اند، بازگردانده شده‌اند یا بازیابی شده‌اند، مشخص شود. تا زمان نهایی‌شدن بررسی‌های این گزارش، هنوز مشخص نشده بود که این موارد چه تأثیری بر رقم اعلام‌شده داشته‌اند.

زمان‌بندی این حادثه هم قابل‌توجه است. شناسایی حادثه در ساعت 18:31 UTC به این معنا نبود که همه انتقال‌های گزارش‌شده بلافاصله متوقف شدند. انتقال 8.2 میلیون USD Coin در شبکه Avalanche در حدود ساعت 20:55 UTC، یعنی بیش از دو ساعت بعد، شناسایی شد. چند توضیح برای این فاصله زمانی ممکن است وجود داشته باشد: شاید تراکنش‌هایی که از قبل امضا شده بودند، همچنان در صف ارسال قرار داشتند؛ شاید برای هر شبکه لازم بوده اقدامات جداگانه‌ای برای متوقف‌کردن انتقال‌ها انجام شود؛ یا شاید مسیر به خطر افتاده همچنان امکان ارسال تراکنش‌ها را فراهم می‌کرده است. تا زمانی که Bitget گزارش امضای تراکنش‌ها و زمان‌بندی اقدامات انجام‌شده برای مهار حادثه را منتشر نکند، نمی‌توان شناسایی حادثه و مهار آن را یک رویداد واحد در نظر گرفت.

چرا برآوردهای اولیه زیان کمتر بود؟

در حوادث بلاک‌چینی، معمولاً نمی‌توان از همان ابتدا یک صورت‌حساب دقیق از میزان زیان در اختیار داشت. تحلیلگران ممکن است در زمان‌های مختلف، آدرس‌های متفاوتی را شناسایی کنند، برچسب‌گذاری کیف پول‌ها با تأخیر انجام شود و یک حجم مشخص از دارایی هنگام تبدیل یا انتقال بین شبکه‌ها، چند بار در داده‌ها ظاهر شود. بنابراین، جمع‌کردن تمام ارقام ثبت‌شده در داده‌های لحظه‌ای می‌تواند میزان زیان را بیش از مقدار واقعی نشان دهد.

سه چالش محاسباتی در شکل‌گیری برآوردهای Bitget نقش داشتند:

• هم‌پوشانی انتقال‌ها و تبدیل‌ها: اگر 19.67 میلیون USDT0 به 7,111 Ether تبدیل شود، ارزش دلاری هر دو دارایی را نمی‌توان به‌عنوان دو زیان جداگانه محاسبه کرد.

• پل‌های بین‌زنجیره‌ای باعث می‌شوند انتقال یک دارایی در دو شبکه قابل مشاهده باشد: یک دارایی ممکن است از یک شبکه به شبکه دیگری منتقل شود و در هر دو شبکه در سوابق تراکنش‌ها دیده شود. اگر این دو انتقال به‌عنوان دو خروجی جداگانه حساب شوند و ارتباط آن‌ها از طریق پل در نظر گرفته نشود، ارزش یک دارایی دوبار محاسبه می‌شود.

• تغییر قیمت‌ها در زمان حمله: هم‌زمان با ادامه خریدهای سنگین Ether، قیمت این دارایی تغییر می‌کرد و تحلیلگران نیز در حال محاسبه ارزش دلاری دارایی‌های جابه‌جاشده بودند. بنابراین، اگر همین محاسبه 10 دقیقه بعد انجام می‌شد، ممکن بود رقم نهایی متفاوت باشد؛ بدون اینکه در این فاصله سرقت دیگری رخ داده باشد.

بخش مربوط به انتقال XRP، همچنان بزرگ‌ترین ابهام حل‌نشده در این ماجراست. اگر کنترل 93.7 میلیون XRP در اختیار همان مهاجم بوده باشد، با در نظر گرفتن فعالیت‌های انجام‌شده روی شبکه‌های EVM در کنار این انتقال XRP، برآورد مستقل از میزان دارایی‌های تحت‌تأثیر، به رقم 351.6 میلیون دلار بسیار نزدیک می‌شود. اما اگر این آدرس مقصد برای یکی از عملکردهای داخلی Bitget یا برای یک طرف معامله قانونی دیگر استفاده شده باشد، این اختلاف به توضیح دیگری نیاز دارد. صرف اینکه یک آدرس در منابع عمومی با نام یا عنوان مشخصی شناخته می‌شود، برای تعیین مالکیت دارایی‌های آن کافی نیست.

فعالیت‌های Ethereum مرتبط با آدرس اصلی Bitget که در گزارش‌های مربوط به این حادثه به آن اشاره شده است؛ بر اساس داده‌های Etherscan و بررسی‌شده در 25 سپتامبر 2026.

یک گزارش جامع پس از حادثه می‌تواند با انتشار آدرس‌های تحت‌تأثیر، هش تراکنش‌ها، نوع و کاربری داخلی کیف پول‌ها، دارایی‌های منتقل‌شده، دارایی‌های تبدیل‌شده، مبالغ مسدودشده، مبالغ بازیابی‌شده و میزان نهایی زیان جبران‌نشده، بخش زیادی از این ابهام را برطرف کند. بدون چنین گزارش جامعی، رقم 351.6 میلیون دلار همچنان به‌عنوان رقم محاسبه‌شده از سوی Bitget قابل‌اعتناست، اما امکان محاسبه و تأیید مستقل آن بر اساس اطلاعات موجود وجود ندارد.

چگونه ممکن است یک کیف پول، تراکنشی معتبر ارسال کند که صرافی هرگز قصد انجام آن را نداشته است؟

بلاک‌چین فقط بررسی می‌کند که یک تراکنش از نظر رمزنگاری معتبر باشد و مجوز لازم برای انجام آن را داشته باشد. اما نمی‌تواند تشخیص دهد که آیا این پرداخت واقعاً مورد تأیید صرافی بوده، آیا مقصد آن توسط کارکنان بررسی شده یا اینکه یک بخش آسیب‌دیده در backend، اطلاعات اشتباه درباره مقصد را به ابزار امضای تراکنش منتقل کرده است؛ در حالی که خود ابزار امضا همچنان بدون مشکل کار می‌کرده است.

همین تمایز می‌تواند توضیحات اولیه Chen درباره این حادثه را روشن‌تر کند. او گفته است که این حادثه ممکن است به یک حمله زنجیره تأمین شباهت داشته باشد؛ یک ابزار شخص ثالث مورد استفاده Bitget، به سرویس backend مربوط به کیف پول‌های حیاتی نفوذ کرده یا آن را تحت‌تأثیر قرار داده است. بر اساس این توضیحات، مهاجم ظاهراً به‌جای دسترسی مستقیم به کلید خصوصی، اطلاعات نادرستی درباره مقصد انتقال را به سیستم امضای تراکنش رسانده است؛ در نتیجه، سیستمی که همچنان به‌درستی کار می‌کرده، ممکن است تراکنشی را امضا کرده باشد که Bitget قصد انجام آن را نداشته است. احتمال دخالت فردی از داخل مجموعه پایین ارزیابی شده، اما همچنان منتفی نیست و بررسی‌ها برای مشخص‌شدن مسیر دقیق حمله ادامه دارد.

در یک فرایند معمول برداشت، پیش از انتقال دارایی‌ها باید چند طرح کنترلی با یکدیگر هماهنگ باشند:

1. مشتری یا فرایند داخلی مدیریت خزانه، یک درخواست انتقال معتبر ایجاد می‌کند.

2. بررسی‌های مربوط به حساب کاربری، دستگاه، آدرس مقصد و ریسک مشخص می‌کنند که آیا این درخواست مجاز است یا خیر.

3. یک سامانه کنترل، دارایی، شبکه، مقصد، مبلغ، سرعت انجام تراکنش‌ها و سطح تأیید موردنیاز را بر اساس سیاست‌های تعریف‌شده بررسی می‌کند.

4. یک یا چند بخش از سامانه امضای تراکنش، جزئیات همان تراکنش را تأیید و امضا می‌کنند.

5. یک سرویس ارسال، تراکنش امضاشده را به شبکه ارسال می‌کند.

6. سامانه‌های نظارتی، نتیجه را با درخواست تأییدشده اولیه مقایسه می‌کنند و در صورت مشاهده فعالیت غیرعادی پس از آن، ادامه فرایند را متوقف می‌کنند.

به خطر افتادن هر یک از این مراحل، لزوماً به‌تنهایی کافی نیست؛ اگر سایر کنترل‌ها واقعاً مستقل از یکدیگر عمل کنند. نگرانی مطرح‌شده در توضیحات اولیه Bitget این است که ممکن است یک بخش نرم‌افزاری مورداعتماد، به فرایند امضای تراکنش‌ها دسترسی کافی داشته باشد تا بتواند بر اطلاعاتی که سیستم امضا تأیید می‌کند، اثر بگذارد. اگر سیستم امضا فقط بررسی کرده باشد که درخواست از یک سرویس مجاز آمده است، این بررسی به‌تنهایی کافی نیست. سیستم باید مقصد و مبلغ تراکنش را هم به‌طور مستقل با اطلاعاتی که پیش‌تر تأیید شده و امکان تغییر آن وجود ندارد، مقایسه کند. اگر چنین بررسی‌ انجام نشده باشد، حتی یک امضای کاملاً معتبر هم می‌تواند یک انتقال مخرب را مجاز کند.

محتمل‌ترین مسیرهای احتمالی اختلال در کنترل‌های امنیتی

هیچ‌کدام از موارد زیر تاکنون اثبات نشده‌اند، اما هرکدام می‌توانند به شکل متفاوتی نشان دهند که کنترل‌های امنیتی چگونه ممکن است از کار افتاده باشند:

• به خطر افتادن ابزار یا به‌روزرسانی نرم‌افزار شخص ثالث: مهاجم ممکن است یکی از وابستگی‌های نرم‌افزاری، ابزار مدیریتی یا سرویس مورد استفاده در فرایند کیف پول را دستکاری کند. در این حالت، صرافی ممکن است درخواست‌هایی را که از طریق آن بخش از سیستم ارسال می‌شوند، قابل‌اعتماد تلقی کند.

• سرقت اطلاعات دسترسی به backend: دسترسی به حساب کاربری اختصاصی یک سرویس، اطلاعات دسترسی API، یک دسترسی فعال یا یک توکن با سطح دسترسی بالا می‌تواند به مهاجم اجازه دهد خود را به‌جای یک سامانه داخلی مجاز جا بزند.

• دور زدن سامانه اعمال سیاست‌ها: درخواست امضا به سیستم امضاکننده می‌رسد، بدون اینکه محدودیت‌های معمول، لیست آدرس‌های مجاز، کنترل تعداد و سرعت تراکنش‌ها یا حدنصاب‌های لازم برای تأیید، روی آن اعمال شده باشند.

• دستکاری رابط امضای تراکنش: افراد مسئول تأیید، یک تراکنش را روی صفحه می‌بینند و تأیید می‌کنند، اما سیستم امضا، تراکنش دیگری را دریافت می‌کند. این اتفاق زمانی ممکن است رخ دهد که سیستم به‌طور مستقل تطبیق ندهد که اطلاعات نمایش‌داده‌شده برای فرد، همان داده‌هایی است که در نهایت امضا می‌شوند.

• به خطر افتادن بخشی از کلید یا سیستم امضاکننده: حتی ساختارهای چندامضایی یا محاسبات چندطرفه (MPC) هم در صورت دسترسی مهاجم به تعداد کافی از امضاکننده‌ها، هماهنگ‌کننده یا فرایند تأیید مربوط به آن‌ها، ممکن است نتوانند جلوی یک انتقال مخرب را بگیرند.

• دسترسی افراد داخلی یا نیروهای قراردادی با سطح دسترسی بالا: ممکن است یک فرد مجاز، یا مهاجمی که از دسترسی آن فرد استفاده می‌کند، انتقال‌های مخرب را ثبت یا تأیید کند. Bitget در حال حاضر احتمال دخالت فردی از داخل مجموعه را پایین می‌داند، اما تاکنون شواهدی منتشر نکرده است که این احتمال را به‌طور کامل منتفی کند.

توضیحات Bitget درباره کیف پول‌های گرم (Hot)، نیمه‌گرم (Warm) و سرد (Cold) هنوز مشخص نمی‌کند که کدام بخش از این فرایند دچار مشکل شده است. کیف پول گرم برای انجام تراکنش‌های آنلاین و پرتعداد طراحی شده است. کیف پول نیمه‌گرم معمولاً با افزودن لایه‌های تأیید یا جداسازی بیشتر، امنیت بالاتری دارد، اما همچنان برای انجام عملیات در دسترس است. کیف پول سرد، اختیار امضای تراکنش‌ها را به‌صورت آفلاین یا جدا از سیستم‌های معمول متصل به اینترنت نگه می‌دارد. این دسته‌بندی‌ها کاربرد موردنظر کیف پول‌ها را توصیف می‌کنند، نه لزوماً کنترل‌هایی را که در شب وقوع این حمله روی تک‌تک آدرس‌ها اعمال شده بود.

از سوی دیگر، دست‌کم یکی از منابع اولیه در داده‌های سرویس‌های ردیابی شخص ثالث، این زیرساخت را به‌عنوان زیرساخت سرد شناسایی کرده است؛ اما Bitget می‌گوید هیچ کیف پول سردی به خطر نیفتاده است. ممکن است دلیل این اختلاف، استفاده از دسته‌بندی‌های متفاوت برای کیف پول‌ها باشد. برای روشن‌شدن این اختلاف، باید مشخص شود هر آدرس عمومی چه نقشی در ساختار داخلی Bitget دارد و هر یک از سیستم‌های امضاکننده چگونه مدیریت و استفاده می‌شوند.

چرا سرعت تبدیل دارایی‌ها اهمیت دارد

به نظر نمی‌رسد مهاجم قصد داشته باشد دارایی‌های سرقت‌شده را به همان شکل نگه دارد و صرفاً یک سبد متنوع از آن‌ها تشکیل دهد. استیبل‌کوین‌ها و طلای توکنیزه‌شده برای یک سارق یک مشکل جدی دارند: ناشران این دارایی‌ها ممکن است بتوانند موجودی‌هایی را که شناسایی شده‌اند، مسدود کنند. در مقابل، Ether در پلتفرم‌های غیرمتمرکز مختلف نقدشوندگی بیشتری دارد و نهادی متمرکز وجود ندارد که بتواند موجودی آن را مسدود کند.

بنابراین، اینکه مهاجم برای خرید Ether از طریق تجمیع‌کننده‌ها مبلغی بالاتر از قیمت معمول پرداخته، آن‌قدرها هم که در نگاه اول به نظر می‌رسد غیرمنطقی نیست. یک مهاجم حرفه‌ای ممکن است حاضر باشد هزینه اجرای نامطلوب معامله را بپذیرد. به‌خصوص وقتی هر دقیقه، احتمال مسدودشدن مرحله بعدی توسط ناشر، پل، صرافی یا سرویس اعتبارسنج بیشتر می‌شود. الگوی این تبدیل‌ها نشان می‌دهد که مهاجم از قبل آماده بوده و مسیرهای مشخصی را برای انتقال دارایی در نظر گرفته است. همچنین حاضر بوده برای افزایش امکان جابه‌جایی دارایی، بخشی از ارزش آن را از دست بدهد.

با این حال، این الگو به‌تنهایی هویت مهاجم را مشخص نمی‌کند. تبدیل سریع استیبل‌کوین‌ها در بسیاری از سرقت‌های بزرگ رمزارزی، به رفتاری رایج تبدیل شده است. این روش می‌تواند در کنار شواهد دیگر، به شناسایی عامل یا گروه پشت حمله کمک کند. اما به‌تنهایی برای نسبت‌دادن حمله به یک عامل مشخص کافی نیست.

چرا احتمال ارتباط مهاجمان با کره شمالی مطرح شده است؟

فرضیه ارتباط با کره شمالی بر پایه سه نوع شواهد متفاوت مطرح شده است: رفتاری که شباهت‌هایی به سرقت‌های پیشین مرتبط با عوامل دولتی دارد، شاخص‌های فنی غیرعمومی که مدیرعامل Bitget به آن‌ها اشاره کرده است و یک ادعای عمومی بر اساس داده‌های درون‌زنجیره‌ای که بخشی از مسیر انتقال XRP را به حمله پیشین AFX مرتبط می‌داند. این شواهد از نظر قدرت و اعتبار یکسان نیستند و کنار هم قرارگرفتن آن‌ها نیز لزوماً به معنای اثبات این ارتباط نیست.

1. الگوی پولشویی آشناست، اما نمی‌تواند مهاجم را مشخص کند

اولین نکته‌ای که جلب توجه می‌کند، سرعت عمل مهاجم است. استیبل‌کوین‌ها و Tether Gold به Ether تبدیل شدند، دارایی‌ها میان آدرس‌های جدید تقسیم شدند و تراکنش‌ها در چندین شبکه ادامه پیدا کردند. در اطلاعیه Federal Bureau of Investigation درباره Bybit آمده است که عوامل TraderTraitor پس از سرقت فوریه 2025، دارایی‌های سرقت‌شده را با سرعت بالا تبدیل کرده و میان هزاران آدرس و چندین بلاک‌چین جابه‌جا کردند.

همین شباهت باعث شد احتمال ارتباط با کره شمالی خیلی زود مطرح شود. اما این بخش، ضعیف‌ترین شواهد موجود است. گروه‌های مجرم، مسیرهای موفق پول‌شویی را تقلید می‌کنند. تجمیع‌کننده‌ها ممکن است برای کاربران نامرتبط نیز مسیرهای مشابهی را انتخاب کنند. از طرف دیگر، هر مهاجمی که دارایی‌های قابل‌مسدودشدن در اختیار داشته باشد، طبیعتاً ترجیح می‌دهد آن‌ها را به دارایی‌هایی تبدیل کند که امکان مسدودکردنشان وجود ندارد یا بسیار محدودتر است. بنابراین، اینکه مهاجم دارایی‌های سرقت‌شده را به‌سرعت به Ether تبدیل کرده، فقط یک شباهت رفتاری با حملات قبلی است. این رفتار به‌تنهایی نمی‌تواند هویت مهاجم را مشخص کند.

2. شاخص‌های IP و VPN؛ نشانه‌هایی از ارتباط با یک گروه کره شمالی

Chen همچنین به آدرس‌های پروتکل اینترنت (IP) و الگوهای استفاده از شبکه خصوصی مجازی (VPN) اشاره کرده است که بررسی‌های انجام‌شده، شباهت آن‌ها را با فعالیت‌های یک گروه مرتبط با کره شمالی نشان می‌دهد. گزارش‌های داخلی مربوط به ورود و دسترسی به سیستم‌ها می‌توانند در این بررسی مهم باشند؛ به‌خصوص اگر نشان دهند که در این حمله از همان زیرساخت‌های خاصی استفاده شده که پیش‌تر در اختیار یک عامل شناخته‌شده بوده‌اند. این شواهد زمانی اهمیت بیشتری پیدا می‌کنند که اطلاعات مربوط به دستگاه، بدافزار، دامنه یا احراز هویت نیز همین ارتباط را تأیید کنند.

این اطلاعات تاکنون به‌صورت عمومی منتشر نشده‌اند. یک آدرس IP ممکن است متعلق به یک VPN تجاری، یک سرور هک‌شده، یک پراکسی خانگی یا حتی یک قربانی دیگر باشد. چندین فرد یا گروه مختلف ممکن است از یک IP یکسان استفاده کنند. حتی یک مهاجم می‌تواند عمداً از زیرساختی استفاده کند که قبلاً در اختیار یک گروه رقیب بوده تا رد خود را پنهان کند. بنابراین، صرف شباهت یک آدرس IP با زیرساخت یک گروه خاص، برای نسبت‌دادن حمله به آن گروه کافی نیست. برای اینکه چنین اتهامی قابل‌اتکا باشد، باید مشخص شود این آدرس چگونه به آن گروه نسبت داده شده، در زمان وقوع حمله چه کسی کنترل آن را در اختیار داشته و چه شواهد دیگری هم‌زمان با آن وجود داشته است.

فرضیه Bitget درباره حمله زنجیره تأمین، با شیوه‌هایی که پیش‌تر در حملات مرتبط با کره شمالی مشاهده شده‌اند، همخوانی دارد؛ اما همخوانی به‌تنهایی به معنای نسبت‌دادن حمله به یک عامل مشخص نیست. در یک اطلاعیه مشترک امنیت سایبری درباره فعالیت‌های TraderTraitor، به استفاده از مهندسی اجتماعی و اپلیکیشن‌های رمزارزی دستکاری‌شده برای نفوذ به کارکنان و سیستم‌های شرکت‌ها اشاره شده است. در گزارش FBI درباره سرقت DMM Bitcoin نیز توضیح داده شده است که مهاجمان چگونه یک استخدام‌کننده جعلی را وارد ماجرا کردند، یک آزمون کدنویسی مخرب را به کار گرفتند، اطلاعات لازم برای حفظ دسترسی به سیستم را سرقت کردند و در نهایت یک درخواست تراکنش معتبر را دستکاری کردند. این اقدامات در کنار یکدیگر، بخشی از همان حمله بودند.

این نمونه‌های قبلی نشان می‌دهند که عوامل مرتبط با کره شمالی در حملات خود فقط کلیدهای خصوصی کیف پول‌ها را هدف نگرفته‌اند و از طریق افراد و نرم‌افزارهای مرتبط با کیف پول‌های رمزارزی نیز اقدام کرده‌اند. اما این نمونه‌ها ثابت نمی‌کنند که در حادثه Bitget هم از همین روش برای نفوذ استفاده شده است. Bitget هنوز باید مشخص کند کدام بخش از سیستم به خطر افتاده، مهاجم از چه مسیری وارد شده، چه اطلاعات دسترسی‌ در معرض خطر قرار گرفته و مشکل در فرایند و سیاست‌های امضای تراکنش‌ها دقیقاً چه بوده است.

3. TraderTraitor یک نام مشخص برای یک تهدید است، نه عنوانی برای همه هک‌های رمزارزی

TraderTraitor نامی است که دولت ایالات متحده برای برخی فعالیت‌های مخرب سایبری مشخص مرتبط با کره شمالی در حوزه بلاک‌چین و صنعت رمزارز به کار می‌برد. بسته به اینکه کدام نهاد یا شرکت امنیتی، کدام عملیات و چه بازه زمانی مورد بررسی باشد، ممکن است از همین فعالیت‌ها با نام‌هایی مانند گروه لازاروس، APT38، Jade Sleet، UNC4899 یا Slow Pisces نیز یاد شود.

این نام‌ها ممکن است در برخی موارد به فعالیت‌های مرتبط با یکدیگر اشاره داشته باشند، اما نمی‌توان آن‌ها را معادل هم در نظر گرفت. اینکه یک مجموعه از فعالیت‌های مرتبط با AFX به TraderTraitor نسبت داده شده، به این معنا نیست که همه آدرس‌های مرتبط با آن نیز تحت کنترل همان افراد بوده‌اند. همچنین نمی‌توان از این موضوع نتیجه گرفت که نفوذ به Bitget هم با استفاده از همان بدافزار یا توسط همان تیم انجام شده است. در حملات گسترده مرتبط با عوامل دولتی، ممکن است افراد و گروه‌های مختلفی در بخش‌های مختلف حمله نقش داشته باشند؛ از اجرای حمله و فراهم‌کردن زیرساخت گرفته تا واسطه‌گری و جابه‌جایی و پول‌شویی دارایی‌ها.

این تفاوت در نام‌گذاری‌ها مهم است، چون گفتن «لازاروس به Bitget حمله کرده است» این تصور را ایجاد می‌کند که هویت مهاجم قطعی شده است.اما شواهد موجود تا زمان نهایی‌شدن این گزارش، فقط نشان می‌دهند که احتمال ارتباط مهاجمان با کره شمالی مطرح شده است. یک تحلیلگر مستقل، بخشی از مسیر انتقال XRP را به مسیر انتقال وجوهی مرتبط دانسته که پیش‌تر در حمله AFX مورد استفاده قرار گرفته بود؛ حمله‌ای که به TraderTraitor نسبت داده شده است. Bitget نیز می‌گوید شاخص‌های داخلی مربوط به IP و VPN، همین احتمال را مطرح می‌کنند.

4.  چه شواهدی می‌تواند این احتمال را به یک نتیجه قابل‌اتکا تبدیل کند؟

برای اینکه بتوان با اطمینان بیشتری گفت چه کسی یا چه گروهی پشت این حمله بوده است، باید شواهد مستقل و قابل‌بررسی از چند بخش مختلف در کنار هم قرار بگیرند:

• ردیابی شفاف و قابل‌بررسی تراکنش‌های بلاک‌چینی: هش دقیق تراکنش‌های XRP و تراکنش‌های میان‌زنجیره‌ای، جزئیات انتقال دارایی‌ها از طریق پل، آدرس‌های تحت کنترل مهاجم، معیارهای مورد استفاده برای شناسایی آدرس‌های مرتبط و توضیح هرگونه ارتباط با سرویس‌هایی که به‌صورت مشترک استفاده می‌شوند.

• شواهد مربوط به زیرساخت: دامنه‌ها، سرورها، گواهی‌های دیجیتال، حساب‌های VPN، سوابق استفاده از پراکسی یا خطاهای عملیاتی که بتوان آن‌ها را به زیرساختی نسبت داد که قبلاً در اختیار همان مهاجم بوده است.

• شواهد مربوط به نحوه نفوذ: بدافزار، اسکریپت‌ها، ارتباطات با سرورهای تحت کنترل مهاجم، سرقت اطلاعات ورود، دسترسی غیرمجاز به نشست‌های فعال کاربران یا بسته‌های نرم‌افزاری متعلق به یک تأمین‌کننده که به خطر افتاده‌اند و کد یا زیرساخت آن‌ها با نمونه‌های قبلی هم‌پوشانی داشته باشد.

• همخوانی زمانی: شواهدی که نشان دهد مهاجم هنگام وقوع هر دو حادثه AFX و Bitget، آدرس‌ها و زیرساخت‌های مرتبط را در اختیار داشته است.

• بررسی مستقل: یک شرکت مشخص در حوزه جرم‌یابی دیجیتال، مجموعه‌ای از صرافی‌ها یا یک نهاد رسمی، به‌طور مستقل به همان نتیجه برسد؛ نه اینکه صرفاً عنوانی را که در شبکه‌های اجتماعی مطرح شده، تکرار کند.

• تعیین عامل حمله از سوی یک نهاد دولتی: بیانیه‌ای رسمی که عامل حمله را مشخص کند و آدرس‌ها یا شاخص‌های فنی کافی را منتشر کند تا فعالان صنعت بتوانند بر اساس آن اقدام کنند.

​​پرونده Bybit در سال 2025 می‌تواند معیار مناسبی برای مقایسه باشد. پنج روز پس از سرقت، FBI به‌طور رسمی اعلام کرد که کره شمالی مسئول این حمله بوده است، نام TraderTraitor را مطرح کرد، درباره شیوه پول‌شویی دارایی‌های سرقت‌شده توضیح داد و ده‌ها آدرس مرتبط در شبکه Ethereum را منتشر کرد. در زمان تهیه این مقاله، تنها چند ساعت از حادثه Bitget گذشته بود. نبود تأیید رسمی مشابه در چنین مرحله‌ای عجیب نیست، اما هنوز نمی‌توان با قطعیت درباره عامل حمله صحبت کرد.

5. چه شواهدی می‌تواند این فرضیه درباره ارتباط با کره شمالی را کم‌رنگ کند؟

این فرضیه در صورتی کم‌رنگ می‌شود که مشخص شود ارتباط احتمالی با AFX در واقع به یک آدرس مشترک متعلق به یک صرافی، پل میان‌زنجیره‌ای یا سرویس دیگر مربوط بوده است؛ یا اینکه آدرس مقصد XRP تحت کنترل مهاجم نبوده باشد. همچنین اگر بررسی زمان‌بندی نشان دهد که کیف پول مشترک در مقطعی در اختیار فرد یا گروه دیگری قرار گرفته بوده، این فرضیه اعتبار کمتری پیدا می‌کند. اگر بعداً مشخص شود ارتباط مطرح‌شده با AFX درست نبوده، یکی از شواهد اصلی این فرضیه از بین می‌رود. همین‌طور اگر شواهد Bitget نشان دهد که حمله توسط گروه دیگری انجام شده یا یک فرد از داخل مجموعه با انگیزه مالی در آن نقش داشته است، فرضیه ارتباط با کره شمالی بیش از پیش اعتبار خود را از دست می‌دهد.

احتمال منحرف‌شدن مسیر شناسایی مهاجم را هم نباید نادیده گرفت. حالا که الگوهای پول‌شویی گروه لازاروس به‌خوبی مستند شده‌اند، گروه‌های دیگر هم می‌توانند از همان الگوها تقلید کنند. کپی‌کردن مسیر تبدیل دارایی‌ها کار دشواری نیست؛ اما بازسازی یک مجموعه آدرس و کیف پول که در طول زمان شکل گرفته، زیرساخت‌های خصوصی، سابقه یک بدافزار و خطاهای عملیاتی مشابه، بسیار دشوارتر است.

بنابراین، منصفانه‌ترین جمع‌بندی این است: یک سرنخ قابل‌اعتنا وجود دارد، اما هنوز نمی‌توان عامل حمله را با قطعیت مشخص کرد. فرضیه ارتباط با کره شمالی فراتر از یک شایعه بی‌نام‌ونشان است، چون هم به یک ارتباط پیشنهادی میان جریان سرمایه در دو حادثه مختلف تکیه دارد و هم Bitget به یک سرنخ فنی مستقل درباره زیرساخت مورد استفاده در این حمله اشاره کرده است. با این حال، شواهد موجود هنوز برای اینکه بتوان با قطعیت گفت گروه لازاروس مسئول هک Bitget بوده، کافی نیستند.

آنچه Bitget هنوز باید درباره این حادثه توضیح دهد

اولین اطلاعیه Bitget به مهم‌ترین پرسش‌هایی پاسخ داد که کاربران در آن لحظه بیش از هر چیز به دنبال آن بودند: حادثه‌ای رخ داده است، برداشت‌ها متوقف شده‌اند و شرکت اعلام کرده که موجودی کاربران و کیف پول‌های سرد در امان مانده‌اند. اما گزارش بعدی باید یک گام فراتر برود و به‌جای اطمینان‌بخشی، شواهد و جزئیات ارائه کند.

مواردی که هنوز باید درباره آن‌ها توضیح داده شود، مشخص‌اند:

• علت اصلی: کدام نرم‌افزار، تأمین‌کننده، سرویس، اطلاعات ورود یا لایه تأیید در این حادثه به خطر افتاده است؟

• مسیر امضای تراکنش: آیا مهاجم امضاهای جدیدی ایجاد کرده، پیش از امضا داده‌های تراکنش را دستکاری کرده یا از تراکنش‌هایی که قبلاً مجوز گرفته بودند سوءاستفاده کرده است؟

• زیرساخت‌های تحت‌تأثیر: کدام آدرس‌ها مربوط به کیف پول‌های گرم، نیمه‌گرم یا سرد بوده‌اند و برای هرکدام چه کنترل‌هایی در نظر گرفته شده بود؟

• مهار حادثه: چرا انتقال‌های گزارش‌شده پس از شناسایی حادثه همچنان ادامه داشتند و راه دسترسی مهاجم دقیقاً چه زمانی مسدود شد؟

• تطبیق میزان دارایی‌های تحت‌تأثیر: Bitget چگونه به رقم 351.6 میلیون دلار در مجموع دارایی‌ها و شبکه‌های مختلف رسیده است، بدون اینکه تبدیل‌ها یا انتقال‌ها از طریق پل‌های میان‌زنجیره‌ای دوباره محاسبه شده باشند؟

• بازیابی: چه میزان از دارایی‌ها مسدود، بازگردانده یا بازیابی شده است و چه میزان همچنان خارج از کنترل Bitget قرار دارد؟

• دسترسی مشتریان: برداشت‌ها چه زمانی و در کدام شبکه‌ها دوباره فعال می‌شوند و آیا محدودیت یا شرایطی برای صف برداشت‌ها وجود خواهد داشت؟

• اقدامات اصلاحی: پیش از بازگشت این سیستم‌ها به روال عادی، Bitget چه کنترل‌های امنیتی را تغییر داده یا تقویت کرده است تا از تکرار چنین حادثه‌ای جلوگیری شود؟

• تعیین عامل حمله: چه شواهدی احتمال ارتباط این حمله با کره شمالی را مطرح می‌کند و آیا یک تحلیلگر یا نهاد مستقل، با بررسی شواهد موجود، به همین نتیجه رسیده است؟

حدود ساعت 02:40 UTC در 25 سپتامبر، برداشت‌ها همچنان رسماً متوقف بودند و مهلت 24ساعته اعلام‌شده برای انتشار گزارش حادثه نیز هنوز به پایان نرسیده بود. در این شرایط، فعال‌بودن واریز و معاملات نمی‌توانست پاسخگوی پرسش اصلی درباره وضعیت دسترسی مشتریان به دارایی‌هایشان باشد. موجودی ثبت‌شده در حساب داخلی زمانی واقعاً برای مشتری قابل استفاده است که بتواند آن را از طریق یک مسیر برداشت فعال و امن، به‌طور واقعی برداشت کند.

آیا صندوق حفاظت از کاربران Bitget می‌تواند این میزان زیان را پوشش دهد؟

Bitget اعلام کرده است که موجودی صندوق حفاظت از کاربران این صرافی بیش از 464 میلیون دلار است و می‌تواند کل مبلغ 351.6 میلیون دلاری دارایی‌های تحت‌تأثیر را پوشش دهد. Bitget در اطلاعات عمومی خود، موجودی اصلی این صندوق را 5,500 Bitcoin اعلام کرده است. با فرض قیمت حدود 84,403 دلار برای هر واحد، ارزش این میزان Bitcoin به حدود 464.2 میلیون دلار می‌رسد.

محاسبات در این قیمت با رقم اعلام‌شده همخوانی دارد، اما حاشیه میزان پوشش واقعی کمتر از چیزی است که رقم اولیه نشان می‌دهد:

• پوشش اسمی: حدود 132% از برآورد دارایی‌های تحت‌تأثیر.

• Bitcoin موردنیاز: حدود 4,166 Bitcoin برای رسیدن به ارزش 351.6 میلیون دلار.

• میزان مصرف‌شده از صندوق: اگر کل زیان از این میزان Bitcoin پرداخت شود، حدود 75.7% از آن مصرف خواهد شد.

• مانده اسمی: حدود 1,334 Bitcoin، پیش از درنظر گرفتن هزینه‌های تراکنش، تغییرات قیمت، سایر مطالبات واجد شرایط یا تأثیرات بازار.

• قیمت سر‌به‌سر: حدود 63,927 دلار برای هر Bitcoin؛ در این قیمت، ارزش 5,500 Bitcoin به اندازه زیان اعلام‌شده خواهد بود.

مهم‌تر از همه، این صندوق یک ذخیره تحت کنترل شرکت است و با بیمه سپرده‌ای که پشتوانه دولتی دارد، تفاوت دارد. شواهد عمومی موجود هنوز مشخص نکرده‌اند که آیا این دارایی‌ها از سایر دارایی‌ها تفکیک شده‌اند، بدون هرگونه تعهد یا محدودیت هستند، امکان انتقال فوری دارند یا به‌طور رسمی برای این حادثه اختصاص یافته‌اند یا خیر. بنابراین، سؤال اصلی دیگر این نیست که 464 میلیون دلار بیشتر از 351.6 میلیون دلار است یا نه؛ مسئله این است که آیا می‌توان موجودی این صندوق را به‌طور مستقل تأیید کرد و آیا امکان استفاده از آن برای جبران این زیان، بدون ایجاد مشکل نقدینگی جدید، وجود دارد یا خیر.

گزارش سپتامبر اثبات ذخایر (PoR) اطلاعات بیشتری درباره وضعیت ذخایر ارائه می‌دهد، اما به ابهام‌های این حادثه پایان نمی‌دهد. Bitget پیش از وقوع این حادثه، نسبت کل ذخایر خود را برای 19 دارایی، 135% اعلام کرده بود. این گزارش نشان می‌دهد که در زمان تهیه این گزارش لحظه‌ای، دارایی‌های موجود برای پوشش موجودی کاربران، بیشتر از میزان تعهدات ثبت‌شده بوده است.اما نمی‌تواند وضعیت ذخایر پس از حادثه را مشخص کند، ثابت کند که تمام موجودی‌های متعلق به کاربران در این محاسبات لحاظ شده‌اند یا نشان دهد که کنترل‌های امنیتی کیف پول‌ها همچنان قابل‌اتکا هستند.

معامله‌گران پس از هک هر صرافی باید چه مواردی را بررسی کنند؟

امنیت یک صرافی را نمی‌توان فقط با یک درصد، یک گواهی، یک صندوق شبیه بیمه یا ادعایی درباره نگهداری دارایی‌ها در کیف پول سرد سنجید. بهتر است چند جنبه مختلف را بررسی کنید و ببینید هرکدام چه چیزی را می‌توانند ثابت کنند و چه چیزی را نمی‌توان از آن‌ها نتیجه گرفت.

• وضعیت برداشت: بررسی کنید آیا می‌توانید دارایی‌هایی را که واقعاً استفاده می‌کنید، از شبکه‌هایی که با آن‌ها کار دارید، برداشت کنید یا خیر. یک برداشت موفق با مبلغ کم، اطلاعات بیشتری درباره وضعیت واقعی برداشت به شما می‌دهد تا صرفاً دیدن موجودی در حساب صرافی.

• شواهد مربوط به ذخایر: به‌دنبال گزارش‌های جدید درباره دارایی‌ها و تعهدات صرافی، شواهد مالکیت کیف پول‌ها، گزارش‌های قبلی و روشی باشید که بتوانید با استفاده از آن مطمئن شوید موجودی خودتان هم در محاسبات لحاظ شده است.

• امنیت عملیاتی: بررسی کنید صرافی دارایی‌ها را چگونه نگهداری و مدیریت می‌کند، چه سازوکاری برای جداسازی امضاکننده‌ها دارد، آدرس‌های مقصد را چگونه کنترل می‌کند، فعالیت‌های مشکوک را چگونه زیر نظر می‌گیرد، در زمان وقوع حادثه چگونه واکنش نشان می‌دهد و چه بررسی‌های امنیتی مستقلی روی سیستم‌های آن انجام شده است.

• اطلاعات و ساختار شرکت: بررسی کنید صرافی تحت مالکیت و فعالیت کدام شرکت است، در چه حوزه قضایی ثبت شده، چه شرایط و مقررات حقوقی بر فعالیت آن حاکم است، چه گزارش‌های مالی منتشر می‌کند و آیا دارایی‌های مشتریان را از دارایی‌های شرکت جدا نگه می‌دارد یا خیر.

• سوابق حوادث امنیتی: فقط اطلاعیه‌های اولیه را نخوانید؛ گزارش‌های پس از حادثه را هم بررسی کنید. کیفیت واکنش یک صرافی را می‌توان از جزئیاتی که درباره آدرس‌ها، زمان‌بندی حادثه، علت اصلی حادثه و اقدامات اصلاحی منتشر می‌کند، بهتر ارزیابی کرد.

• کنترل‌های حساب کاربری: احراز هویت دوعاملی (2FA) را با یک اپلیکیشن فعال کنید، از یک رمز عبور منحصربه‌فرد و خاص استفاده کنید، کد ضد فیشینگ را فعال کنید، دستگاه‌های فعال حساب کاربری خود را بررسی کنید و در صورت وجود، لیست مجاز برداشت را فعال کنید.

• محدودیت در نگهداری دارایی: در یک پلتفرم متمرکز، فقط به اندازه‌ای دارایی نگه دارید که برای معامله یا انتقال‌های کوتاه‌مدت به آن نیاز دارید. نگهداری شخصی دارایی، ریسک نگهداری دارایی توسط صرافی را حذف می‌کند، اما در عوض مسئولیت مدیریت کلیدها و بازیابی دارایی را بر عهده خودتان می‌گذارد.

صرافی‌های بزرگ رمزارزی از نظر شفافیت چه تفاوتی دارند؟

این جدول قرار نیست صرافی‌ها را از نظر امنیت رتبه‌بندی کند. هدف، مقایسه روش‌های عمومی راستی‌آزمایی است که تا 25 سپتامبر 2026 در دسترس بوده‌اند و نشان‌دادن اینکه هرکدام از این روش‌ها به چه پرسشی می‌توانند پاسخ دهند. با این حال، هیچ‌کدام از این شواهد به‌تنهایی ثابت نمی‌کنند که یک صرافی در برابر هک مصون است، تمام تعهدات مالی خود را اعلام کرده یا در زمان وقوع بحران می‌تواند برداشت‌ها را همچنان باز نگه دارد.

آنچه مقایسه صرافی‌ها واقعاً نشان می‌دهد

این جدول یک برنده واحد و قطعی معرفی نمی‌کند، چون هر صرافی اطلاعات و شواهد متفاوتی را برای بررسی عمومی منتشر می‌کند. Coinbase از طریق صورت‌های مالی فصلی و حسابرسی‌های مستقل سالانه، اطلاعات مالی شرکت را به‌صورت متعارف و عمومی گزارش می‌کند. Binance و OKX سامانه‌های رمزنگاری‌شده اثبات ذخایر را همراه با اطلاعات کیف پول‌ها و ابزارهایی برای راستی‌آزمایی موجودی کاربران ارائه می‌دهند. Kraken امکان بررسی موجودی در سطح حساب را در کنار نسبت ذخایر دارایی‌های تحت پوشش فراهم می‌کند؛ در حالی که Bybit و Toobit از سازوکارهای مبتنی بر درخت مرکل استفاده می‌کنند تا کاربران بتوانند بررسی کنند آیا موجودی آن‌ها در یک تصویر لحظه‌ای مشخص از ذخایر لحاظ شده است یا خیر.

این اطلاعات به یکدیگر مرتبط‌ هستند، اما هرکدام به پرسش متفاوتی پاسخ می‌دهند:

• اثبات ذخایر: آیا صرافی در یک مقطع زمانی مشخص، به اندازه موجودی کاربران لحاظ‌شده در گزارش، دارایی‌های تحت پوشش در اختیار داشته است؟

• راستی‌آزمایی قرارگرفتن موجودی کاربر: آیا یک کاربر می‌تواند به‌طور مستقل تأیید کند که موجودی او در محاسبات و تعهدات اعلام‌شده صرافی لحاظ شده است؟

• شواهد مالکیت کیف پول‌ها: آیا صرافی نشان داده است که کنترل آدرس‌هایی را که به‌عنوان ذخایر معرفی کرده، در اختیار دارد؟

• صورت‌های مالی: وضعیت کلی دارایی‌ها، بدهی‌ها، درآمدها، هزینه‌ها، ریسک‌ها و سایر تعهدات مالی و حقوقی شرکت چگونه است؟

• ارزیابی‌های امنیتی: آیا متخصصان مستقل، بخش‌هایی از پلتفرم، اپلیکیشن‌ها، زیرساخت نگهداری و مدیریت دارایی‌ها یا کنترل‌های داخلی صرافی را بررسی و آزمایش کرده‌اند؟

• صندوق‌های حفاظتی: آیا صرافی یک ذخیره مالی جداگانه در نظر گرفته است که بتواند در صورت وقوع برخی حوادث امنیتی مشخص، برای جبران زیان‌ها مورد استفاده قرار گیرد؟

هیچ‌کدام از این موارد به‌تنهایی پاسخگوی همه پرسش‌ها نیستند. یک صرافی ممکن است ذخایر کافی داشته باشد، اما همچنان با به خطر افتادن یک سرویس کیف پول مواجه شود. ممکن است یک ارزیابی امنیتی را با موفقیت پشت سر بگذارد، اما بعداً یک سرویس یا ابزار نرم‌افزاری آسیب‌پذیر را وارد زیرساخت خود کند. ممکن است یک صندوق حفاظت داشته باشد، بدون اینکه مشخص باشد در صورت وقوع حادثه، این صندوق با چه سرعتی قابل استفاده است. همچنین ممکن است صورت‌های مالی حسابرسی‌شده منتشر کند، اما راهکاری رمزنگاری‌شده در اختیار کاربران قرار ندهد تا بتوانند به‌طور مستقل بررسی کنند که موجودی شخصی آن‌ها در محاسبات لحاظ شده است یا خیر.

بنابراین، مقایسه صرافی‌ها نباید فقط بر اساس این باشد که کدام صرافی بالاترین درصد ذخایر را نمایش می‌دهد. مسئله مهم‌تر این است که چه بخش‌هایی از عملکرد و کنترل‌های امنیتی صرافی را می‌توان به‌صورت مستقل بررسی کرد، این اطلاعات تا چه اندازه به‌روز هستند و آیا شواهد موجود با ریسکی که قرار است ارزیابی شود، ارتباط دارند یا خیر.

چرا اثبات ذخایر نمی‌تواند امنیت کیف پول را ثابت کند؟

اثبات ذخایر (PoR) می‌تواند نشان دهد که در یک مقطع زمانی مشخص، دارایی‌های موردنظر صرافی برای پوشش موجودی مشتریانی که در محاسبات لحاظ شده‌اند، وجود داشته است. اما از طریق اثبات ذخایر نمی‌توان نتیجه گرفت که سیستم‌هایی که این دارایی‌ها را مدیریت و کنترل می‌کنند، در برابر نفوذ یا به خطر افتادن مصون هستند.

حادثه Bitget این تفاوت را به‌روشنی نشان می‌دهد. گزارش اثبات ذخایر این صرافی در سپتامبر، پیش از وقوع هک، برای 19 دارایی نسبت کل ذخایر 135% را نشان می‌داد. با وجود این درصد مازاد، همچنان مسیری برای انجام یک تراکنش غیرمجاز و انتقال دارایی‌ها وجود داشت. مسئله‌ای که در این حادثه در حال بررسی است، به نحوه مدیریت کیف پول‌ها، سازوکار تأیید و مجازکردن تراکنش‌ها یا نرم‌افزارهای مرتبط با این فرایند مربوط می‌شود؛ نه صرفاً به اینکه پیش از وقوع حادثه، دارایی‌ها در کیف پول‌های ذخیره وجود داشته‌اند یا خیر.

یک گزارش اثبات ذخایر چه چیزهایی را می‌تواند مشخص کند؟

• آیا موجودی مشتریانی که دارایی‌هایشان در گزارش پوشش داده شده، در محاسبه تعهدات مالی صرافی لحاظ شده است؟

• آیا کیف پول‌های اعلام‌شده، به اندازه کافی از دارایی‌های موردنظر در اختیار داشته‌اند؟

• آیا کاربران می‌توانند با استفاده از مسیر درخت مرکل یا یک روش رمزنگاری دیگر، به‌طور مستقل بررسی کنند که موجودی آن‌ها در محاسبات لحاظ شده است؟

• آیا سابقه‌ای از گزارش‌های قبلی وجود دارد که بتوان وضعیت ذخایر را در طول زمان با آن مقایسه کرد؟

اما معمولاً نمی‌تواند به این پرسش‌ها پاسخ دهد:

• آیا یک سرویس backend که به خطر افتاده است، می‌تواند درخواست یک تراکنش مخرب را برای امضا ارسال کند؟

• آیا سیاست‌ها و کنترل‌های مربوط به برداشت، مستقل از نرم‌افزاری که تراکنش را ایجاد می‌کند، اعمال می‌شوند؟

• آیا یک کارمند، نیروی قراردادی یا تأمین‌کننده می‌تواند بر چند مرحله از فرایند تأیید تراکنش تأثیر بگذارد؟

• آیا تمام تعهدات مالی شرکت، از جمله وام‌ها، تعهدات احتمالی و تعهدات حقوقی، در محاسبات لحاظ شده‌اند؟

• آیا در صورت وقوع یک حادثه امنیتی یا بروز بحران نقدینگی، برداشت‌ها همچنان به‌طور عادی ادامه خواهند داشت؟

• آیا می‌توان در صورت نیاز، بلافاصله و بدون محدودیت از صندوق حفاظت پلتفرم برای جبران زیان‌ها استفاده کرد؟

• آیا نسخه‌های بعدی نرم‌افزار نیز همان کنترل‌هایی را حفظ خواهند کرد که در ارزیابی قبلی بررسی شده‌اند؟

بنابراین، شفافیت ذخایر و امنیت تراکنش‌ها باید به‌صورت جداگانه بررسی شوند. اثبات ذخایر (PoR) عمدتاً نشان می‌دهد که در یک مقطع زمانی مشخص، دارایی‌های صرافی برای پوشش موجودی‌های موردنظر کاربران کافی بوده‌اند. اما امنیت کیف پول به این می‌پردازد که تراکنش‌ها چگونه درخواست و تأیید می‌شوند، چه مراحلی را برای امضا و ارسال به شبکه طی می‌کنند، چگونه تحت نظارت قرار می‌گیرند و در صورت بروز مشکل، چگونه متوقف می‌شوند.

Bybit نمونه خوبی برای درک این تفاوت است. این صرافی پیش از حادثه سال 2025، گزارش‌های ذخایر و ابزارهایی برای راستی‌آزمایی موجودی کاربران داشت؛ با این حال، مشکل اصلی در آن حادثه به فرایند امضای تراکنش‌ها مربوط می‌شد. بنابراین، اطلاعات مربوط به ذخایر همچنان ارزشمند بود، اما نمی‌توانست مانع دستکاری تراکنش‌ها شود.

Bitget نیز باید حالا توضیح دهد که این حادثه دقیقاً چگونه رخ داده است. انتشار یک گزارش جدید از وضعیت ذخایر می‌تواند به مشخص‌شدن میزان تأثیر مالی این حادثه کمک کند، اما جای توضیح فنی درباره سرویسی که به خطر افتاده و نقص در کنترل‌های مربوط به تأیید و مجازکردن تراکنش‌ها را نمی‌گیرد.

چطور نسبت ذخایر را درست تفسیر کنیم؟

نسبت ذخایر بالاتر از 100% در نگاه اول اطمینان‌بخش به نظر می‌رسد، اما برای تفسیر درست آن باید به زمینه و نحوه محاسبه این عدد هم توجه کرد. برای مثال، نسبت 106% یعنی در زمان تهیه گزارش، ذخایر اعلام‌شده برای آن دارایی حدود 6% بیشتر از موجودی متناظر کاربرانی بوده که در محاسبات لحاظ شده‌اند. اما این عدد به این معنا نیست که کل صرافی در برابر هر زیان احتمالی، 6% سرمایه مازاد در اختیار دارد.

چند عامل مشخص می‌کنند که این درصد تا چه اندازه می‌تواند وضعیت ذخایر صرافی را نشان دهد:

• میزان پوشش دارایی‌ها: گزارشی که چهار دارایی اصلی را پوشش می‌دهد، با گزارشی که 19 یا 22 دارایی را پوشش می‌دهد، قابل‌مقایسه نیست.

• میزان پوشش تعهدات مالی: گزارش باید مشخص کند چه نوع حساب‌ها، وام‌ها، پوزیشن‌های مارجین و سایر تعهدات در محاسبات لحاظ شده‌اند.

• تاریخ تهیه گزارش: گزارشی که پیش از وقوع یک حادثه تهیه شده است، نمی‌تواند وضعیت مالی صرافی را پس از متحمل‌شدن یک زیان بزرگ نشان دهد.

• شواهد مربوط به کیف پول‌ها: کاربران باید بتوانند بررسی کنند صرافی برای اثبات کنترل خود بر آدرس‌های کیف پول اعلام‌شده، چه شواهدی ارائه کرده است.

• راستی‌آزمایی موجودی کاربران: یک نسبت کلی ذخایر، زمانی اطلاعات قابل‌اتکاتری ارائه می‌دهد که کاربران بتوانند مستقلاً بررسی کنند موجودی آن‌ها نیز در محاسبات لحاظ شده است.

• گزارش‌های دوره‌ای: گزارش‌های منظم و آرشیوشده کمک می‌کنند تغییرات ناگهانی در میزان ذخایر یا نسبت پوشش تعهدات در طول زمان شناسایی شوند.

• بررسی مستقل: راستی‌آزمایی توسط یک نهاد مستقل می‌تواند اعتماد بیشتری ایجاد کند؛ البته باید به این موضوع هم توجه داشت که چه نهادی بررسی را انجام داده، از چه روشی استفاده کرده و دقیقاً چه بخش‌هایی را بررسی کرده است.

درصد بالاتر ممکن است واقعاً نشان‌دهنده ذخایر مازاد باشد، اما عوامل دیگری هم می‌توانند روی این عدد تأثیر بگذارند؛ مثلاً اینکه چه میزان از تعهدات مالی صرافی در محاسبات لحاظ شده، موجودی‌ها تا چه حد موقتی بوده‌اند، قیمت دارایی‌ها در زمان تهیه گزارش چقدر بوده یا چه محصولاتی اصلاً در گزارش نیامده‌اند. بنابراین، اگر فقط درصد نهایی را با هم مقایسه کنیم و به این جزئیات توجه نکنیم، ممکن است تفاوت میان صرافی‌ها را اشتباه برداشت کنیم.

به همین دلیل، نمی‌توان صرفاً به خاطر بالاتر بودن یک درصد، گفت صرافی کوچک‌تری که فقط چهار دارایی را گزارش می‌کند، از یک صرافی بزرگ‌تر شفاف‌تر است. برای ارزیابی شفافیت باید دید گزارش چه دارایی‌هایی را پوشش می‌دهد، تعهدات مالی چگونه محاسبه شده‌اند، صرافی برای اثبات کنترل کیف پول‌های اعلام‌شده چه شواهدی ارائه کرده، گزارش‌ها با چه فاصله‌ای منتشر می‌شوند و کاربران چگونه می‌توانند موجودی خود را راستی‌آزمایی کنند.

Toobit در این مقایسه چه جایگاهی دارد؟

اطلاعاتی که Toobit به‌صورت عمومی منتشر کرده، به دو پرسش متفاوت پاسخ می‌دهند. گزارش ذخایر سپتامبر نشان می‌دهد که آیا در یک تاریخ مشخص، ذخایر چهار دارایی اصلی از موجودی متناظر کاربران بیشتر بوده است یا خیر. در صفحات مربوط به امنیت نیز توضیح داده شده که Toobit در شرایط عادی، از دارایی‌ها و حساب‌های کاربران چگونه محافظت می‌کند.

این دو نوع اطلاعات زمانی کاربرد بیشتری دارند که جداگانه بررسی شوند. نسبت ذخایر می‌تواند وضعیت پشتوانه دارایی‌ها را در یک مقطع مشخص نشان دهد، در حالی که اثبات مرکل به کاربر کمک می‌کند بررسی کند آیا موجودی حساب او در محاسبات مربوط به تعهدات مالی لحاظ شده است یا خیر. با این حال، هیچ‌کدام به‌تنهایی ثابت نمی‌کنند که همه کیف پول‌ها، سیستم‌های داخلی یا تراکنش‌های آینده همواره در برابر خطرات امنیتی ایمن خواهند بود.

نسبت‌های ذخایر Toobit در ماه سپتامبر

نسبت ذخایر Toobit برای BTC، ETH، USDT و USDC در تاریخ 1 سپتامبر 2026 UTC؛ منبع: Toobit، بررسی‌شده در 25 سپتامبر 2026.

هر چهار نسبت در زمان تهیه این گزارش بالاتر از 100% بوده‌اند. یعنی برای هر یک از این چهار دارایی، میزان ذخایر اعلام‌شده از موجودی متناظر کاربرانی که در گزارش لحاظ شده‌اند، بیشتر بوده است. میزان این مازاد برای هر دارایی متفاوت بوده و از 2% برای Ether تا 6% برای Tether متغیر بوده است.

این درصدها نباید با یکدیگر جمع شوند یا به‌عنوان یک نسبت سرمایه برای کل صرافی در نظر گرفته شوند. هر درصد، ذخایر یک دارایی مشخص را با موجودی متناظر کاربرانی که در محاسبات لحاظ شده‌اند، مقایسه می‌کند. برای مثال، نسبت 106% برای Tether به‌تنهایی هیچ اطلاعاتی درباره تعهدات مالی صرافی در قبال دارایی‌های دیگر ارائه نمی‌دهد.

تعداد دارایی‌هایی که گزارش پوشش می‌دهد، به‌اندازه خود این درصدها اهمیت دارد. این گزارش، چهار دارایی پرکاربرد را بررسی می‌کند، در حالی که گزارش‌های Bitget و OKX که در این مقایسه به آن‌ها اشاره شد، تعداد بیشتری از دارایی‌ها را پوشش می‌دهند. بنابراین، گزارش Toobit برای بررسی وضعیت ذخایر این چهار دارایی مفید است، اما نمی‌تواند وضعیت پشتوانه تمام توکن‌ها یا محصولات موجود در پلتفرم را مشخص کند.

چگونه کاربران می‌توانند از لحاظ شدن موجودی خود مطمئن شوند؟

یک نسبت ذخایر منتشرشده، تا زمانی که کاربران نتوانند بررسی کنند موجودی خودشان در محاسبات تعهدات مالی لحاظ شده است، همچنان فقط یک عدد در سطح کل صرافی محسوب می‌شود. صفحه اثبات ذخایر Toobit، برای این منظور یک ریشه مرکل و فرایند راستی‌آزمایی ارائه می‌کند.

درخت مرکل، اطلاعات مربوط به موجودی حساب‌های مختلف را به هش‌های رمزنگاری‌شده تبدیل می‌کند و در نهایت آن‌ها را به یک مقدار واحد به نام ریشه مرکل می‌رساند. بدون اینکه اطلاعات حساب سایر کاربران نمایش داده شود، کاربر می‌تواند بررسی کند که آیا موجودی حسابش در گزارش لحاظ شده است یا خیر.

   رابط کاربری ریشه مرکل و راستی‌آزمایی قرارگرفتن موجودی حساب در سیستم اثبات ذخایر Toobit؛ منبع: Toobit، بررسی‌شده در 25 سپتامبر 2026.

ابزار مرکل یکی از ضعف‌های مهم اعلام صرف نسبت ذخایر را برطرف می‌کند. این ابزار به کاربران امکان می‌دهد بررسی کنند آیا موجودی حساب آن‌ها در محاسبات لحاظ شده است یا نه، به‌جای اینکه صرفاً به یک درصد کلی اعلام‌شده از سوی صرافی اکتفا کنند.

با این حال، این راستی‌آزمایی محدودیت‌هایی دارد. لحاظ‌شدن موجودی در گزارش فقط نشان می‌دهد که آن موجودی در محاسبات تعهدات مالی لحاظ شده است. این موضوع به‌تنهایی ثابت نمی‌کند که تمام تعهدات مالی در محاسبات لحاظ شده‌اند، دارایی‌های

اعلام‌شده بدون هرگونه محدودیت یا تعهد دیگری در اختیار صرافی بوده‌اند یا صرافی پس از تاریخ تهیه گزارش نیز همان میزان ذخایر را حفظ خواهد کرد یا خیر.

کاربر برای بررسی وضعیت موجودی خود باید به سه سؤال پاسخ دهد:

1. آیا اطلاعات مربوط به موجودی، به تاریخ درست گزارش مربوط می‌شود؟

2. آیا دارایی‌ها و موجودی حساب شما در همان تاریخ در گزارش لحاظ شده‌اند؟

3. آیا می‌توان این نتیجه را از طریق فرایند راستی‌آزمایی ارائه‌شده یا ابزار متن‌باز آن بررسی کرد؟

اگر راستی‌آزمایی نشان دهد که موجودی کاربر در گزارش لحاظ شده است، ارتباط میان حساب او و گزارش منتشرشده از ذخایر قابل‌اعتمادتر می‌شود. اما این موضوع به‌تنهایی گزارش را به یک حسابرسی کامل مالی تبدیل نمی‌کند.

کنترل‌های مرتبط با ذخایر

پشتوانه ذخایر و امنیت کیف پول، هرکدام ریسک متفاوتی را پوشش می‌دهند. یک تصویر لحظه‌ای از ذخایر می‌تواند نشان دهد که آیا دارایی‌های مشخص‌شده در یک زمان معین، برای پوشش موجودی متناظر کاربران کافی بوده‌ است یا خیر. اما سؤال بعدی این است که صرافی چگونه از این دارایی‌ها محافظت می‌کند، دسترسی به فرایندهای انجام تراکنش را چگونه کنترل می‌کند و در صورت مشاهده فعالیت مشکوک، چگونه واکنش نشان می‌دهد.

Toobit چارچوب امنیتی Bee-Safe خود را در شش حوزه دسته‌بندی می‌کند:

• اثبات ذخایر: پشتوانه دارایی‌ها که کاربران می‌توانند از طریق سیستم اثبات ذخایر صرافی آن را راستی‌آزمایی کنند.

• زیرساخت پایدار: زیرساخت چند ابری که با هدف حفظ دسترس‌پذیری پلتفرم و تداوم فعالیت‌های معاملاتی طراحی شده است.

• اقدامات پیشگیرانه: احراز هویت چندمرحله‌ای، نگهداری دارایی‌ها در کیف پول سرد و انجام ممیزی‌های مستمر.

• امنیت داده‌ها: استفاده از معماری اعتماد صفر (Zero Trust)، رمزنگاری و سازوکارهای شناسایی فیشینگ.

• حفاظت کامل از حریم خصوصی: اقدامات حفاظت از داده‌ها، از جمله سازوکارهای امنیتی مبتنی بر اثبات دانش صفر و کنترل‌های بیومتریک.

• دفاع فعال شبانه‌روزی (24/7): نظارت و پشتیبانی مستمر با هدف شناسایی و واکنش به فعالیت‌های مشکوک.

چارچوب امنیتی Bee-Safe در Toobit که اثبات ذخایر، پایداری زیرساخت، کنترل‌های امنیتی حساب‌های کاربری، امنیت داده‌ها، حریم خصوصی و نظارت مستمر را پوشش می‌دهد؛ منبع: Toobit، تا 25 سپتامبر 2026.

این لایه‌های امنیتی، ریسک‌هایی را پوشش می‌دهند که نسبت ذخایر نمی‌تواند آن‌ها را نشان دهد. اثبات ذخایر، پشتوانه دارایی‌ها را بررسی می‌کند؛ در حالی که احراز هویت و کنترل‌های شناسایی فیشینگ، از حساب‌های کاربری محافظت می‌کنند. کیف پول سرد به امنیت نگهداری دارایی‌ها مربوط است. رمزنگاری، از داده‌های حساس محافظت می‌کند و نظارت مستمر، برای شناسایی فعالیت‌های غیرعادی پیش از گسترش آن‌ها انجام می‌شود.

این چارچوب نشان می‌دهد Toobit اعلام کرده است چه کنترل‌های امنیتی را در اختیار دارد، اما صرف وجود یک کنترل امنیتی به این معنا نیست که در هر حادثه‌ای بدون نقص عمل خواهد کرد. ارزش عملی این کنترل‌ها به نحوه اجرا، آزمایش، بررسی مستقل و به‌روزرسانی آن‌ها در مواجهه با آسیب‌پذیری‌های جدید بستگی دارد.

بررسی اطلاعات منتشرشده توسط  Toobit 

اطلاعاتی که Toobit به‌صورت عمومی منتشر کرده، سه بخش اصلی را برای بررسی شفافیت در اختیار کاربران قرار می‌دهد:

1. نسبت ذخایر چهار دارایی اصلی که در گزارش سپتامبر اعلام شده است

2. امکان بررسی و راستی‌آزمایی موجودی حساب کاربران از طریق درخت مرکل و تطبیق آن با تصویر لحظه‌ای مربوط به گزارش

3. اطلاعات منتشرشده درباره کنترل‌های امنیتی در زمینه دسترسی به حساب‌ها، نگهداری دارایی‌ها، زیرساخت، آزمایش‌های امنیتی و آمادگی برای مقابله با حوادث

این اطلاعات، امکان بررسی دقیق‌تری در اختیار کاربران قرار می‌دهند و فراتر از یک اعلامیه کلی درباره امن‌بودن دارایی‌ها هستند. گزارش ذخایر، ارقام مشخصی از وضعیت ذخایر در یک مقطع از گذشته ارائه می‌کند؛ داشبورد اثبات ذخایر (PoR) امکان راستی‌آزمایی موجودی را فراهم می‌کند و صفحه امنیت نیز کنترل‌هایی را که Toobit برای حفاظت از ذخایر خود اعلام کرده است، توضیح می‌دهد.

این محدودیت‌ها باید در کنار نقاط قوت این اطلاعات در نظر گرفته شوند. گزارش سپتامبر فقط چهار دارایی را پوشش می‌دهد و شامل همه توکن‌های موجود در پلتفرم نیست. اثبات ذخایر (PoR) وضعیت ذخایر را در یک مقطع زمانی مشخص نشان می‌دهد و نمی‌تواند جایگزین اثبات مستمر توانایی صرافی در ایفای تعهدات مالی باشد. قرارگرفتن موجودی در درخت مرکل نیز به این معنا نیست که تمام تعهدات مالی شرکت قابل مشاهده یا بررسی هستند. کنترل‌های امنیتی می‌توانند ریسک را کاهش دهند، اما نمی‌توانند احتمال بروز مشکل در نرم‌افزار، سرویس‌های ارائه‌شده توسط تأمین‌کنندگان، فرایندهای عملیاتی، افراد داخلی یا سیستم‌های امضای تراکنش‌ها را به‌طور کامل از بین ببرند.

در مجموع، این شواهد تصویر مشخصی ارائه می‌دهند، اما باید محدودیت‌های آن‌ها را هم در نظر گرفت: Toobit برای Bitcoin، Ether، Tether و USD Coin، فرایندی عملی و قابل‌راستی‌آزمایی برای بررسی ذخایر در اختیار کاربران قرار می‌دهد و در کنار آن، چندین کنترل امنیتی در زمینه حساب‌های کاربری و نگهداری دارایی‌ها را نیز به‌صورت عمومی توضیح داده است. با این حال، باید این شواهد را در چارچوب همان اطلاعاتی که پوشش می‌دهند ارزیابی کرد و نباید صرفاً به دلیل هک Bitget، نتیجه گرفت که یک صرافی دیگر از امنیت بیشتری برخوردار است.

آنچه جدول مقایسه نشان نمی‌دهد

یک جدول می‌تواند اطلاعات و گزارش‌های منتشرشده را منظم و قابل‌مقایسه کند، اما نمی‌تواند تجربه استفاده از یک صرافی در شرایط بحرانی را بازتاب دهد. وضعیت برداشت‌ها، سرعت و کیفیت پاسخ‌گویی پشتیبانی، نحوه اطلاع‌رسانی در زمان وقوع حادثه، محدودیت‌های منطقه‌ای، نقدشوندگی و بررسی حساب‌ها ممکن است سریع‌تر از یک گزارش ذخایر تغییر کنند.

دسترسی و شرایط حقوقی نیز در کشورهای مختلف متفاوت است. دو کاربری که از یک برند جهانی استفاده می‌کنند، ممکن است با شرکت‌های عملیاتی، محصولات، شرکای پرداخت، سازوکارهای نگهداری دارایی یا شرایط قراردادی متفاوتی مواجه شوند. سرویسی که در یک حوزه قضایی در دسترس است، ممکن است در حوزه قضایی دیگری به صورت محدود یا اصلاً در دسترس نباشد.

پیش از انتخاب یک صرافی، بهتر است این موارد را بررسی کنید:

1. آیا دارایی و شبکه‌ای که به آن نیاز دارید، در صرافی پشتیبانی می‌شود؟

2. کارمزدهای فعلی واریز، معامله، تبدیل و برداشت چقدر است؟

3. محدودیت‌های برداشت و الزامات احراز هویت حساب چیست؟

4. جدیدترین گزارش ذخایر چه زمانی منتشر شده و چه دارایی‌هایی را پوشش می‌دهد؟

5. آیا می‌توان بررسی کرد که موجودی حساب شما در محاسبات گزارش لحاظ شده است؟

6. سوابق حوادث امنیتی صرافی و کیفیت گزارش‌هایی که پس از این حوادث منتشر کرده است چگونه است؟

7. چه امکاناتی برای محافظت از حساب و کنترل برداشت‌ها در دسترس است؟

8. آیا یک برداشت آزمایشی با مبلغ کم با موفقیت انجام می‌شود؟

9. در عمل، چه مقدار از سرمایه شما لازم است در اختیار صرافی باقی بماند؟

این سؤال آخر اغلب نادیده گرفته می‌شود. انتخاب یک صرافی به این معنا نیست که باید همه دارایی‌های خود را برای همیشه در آن نگه دارید. معامله‌گران می‌توانند سرمایه موردنیاز برای معاملات روزمره را از دارایی‌هایی که قصد نگهداری بلندمدت آن‌ها را دارند، جدا کنند و بر اساس ریسک‌هایی که می‌توانند مدیریت کنند، تصمیم بگیرند. نگهداری متمرکز دارایی، ریسک‌های مربوط به پلتفرم و طرف مقابل معامله را به همراه دارد. در نگهداری شخصی دارایی، صرافی دیگر در فرایند امضای تراکنش دخالتی ندارد، اما مسئولیت نگهداری کلیدهای خصوصی، تهیه نسخه پشتیبان، امنیت دستگاه، برنامه‌ریزی برای انتقال دارایی پس از فوت و جلوگیری از اشتباهات غیرقابل‌برگشت بر عهده مالک دارایی خواهد بود.

بنابراین، این مقایسه می‌تواند نقطه شروعی برای بررسی دقیق یک صرافی باشد. این مقایسه نشان می‌دهد کدام ادعاها را می‌توان بررسی و راستی‌آزمایی کرد و در چه بخش‌هایی هنوز اطلاعات کافی وجود ندارد. با این حال، این مقایسه به این معنا نیست که نگهداری دارایی در هیچ‌یک از این صرافی‌ها بدون ریسک است.

آزمون واقعی، از اینجا به بعد است

وقوع سرقت دیگر مورد بحث نیست. حالا سؤال اصلی این است که آیا Bitget می‌تواند گزارش دقیق و قابل‌راستی‌آزمایی از میزان زیان خود ارائه دهد، برداشت‌ها را با اطمینان از امنیت آن‌ها دوباره فعال کند، نشان دهد صندوق حفاظت صرافی واقعاً در دسترس است و توضیح دهد چگونه یک سیستم مورداعتماد توانسته تراکنش‌هایی را انجام دهد که مجوز آن‌ها صادر نشده بود.

فرضیه ارتباط این حمله با کره شمالی همچنان ارزش بررسی دارد، چون دو مسیر مستقل به این احتمال اشاره می‌کنند: سرنخ‌های زیرساختی که Bitget در اختیار دارد و ارتباطی که Specter میان مسیر انتقال XRP و سرقت AFX مطرح کرده است. با این حال، هیچ‌کدام از این دو مسیر شواهد عمومی و کافی برای قطعی‌کردن این ارتباط ارائه نمی‌کنند. یک گزارش جامع پس از حادثه باید به‌روشنی مشخص کند کدام اطلاعات برای Bitget قطعی و اثبات‌شده است و کدام موارد هنوز صرفاً در حد احتمال و فرضیه هستند. همچنین، نسبت‌دادن عامل حمله زمانی قابل‌اتکاست که محققان مستقل بتوانند بر اساس شواهد موجود، همان مسیر را دوباره بررسی کنند.

تا آن زمان، می‌توان این حادثه را به ساده‌ترین و دقیق‌ترین شکل این‌طور توصیف کرد: Bitget با یک حادثه بزرگ در کیف پول‌های چندین شبکه مواجه شده که حدود 351.6 میلیون دلار دارایی را تحت‌تأثیر قرار داده است. احتمال بروز نقص در یک سیستم backend یا حمله زنجیره تأمین در حال بررسی است. ارتباط مهاجمان با عوامل مرتبط با کره شمالی مطرح شده، اما هنوز تأیید نشده است. وضعیت برداشت‌ها، میزان نهایی زیان خالص، نحوه استفاده از صندوق حفاظت و مشخص‌شدن سیستم کنترل امنیتی‌ که دچار نقص شده، همچنان عواملی هستند که می‌توانند تصویر نهایی این حادثه را تغییر دهند.

پیش از تصمیم‌گیری، تحقیقات لازم را خودتان انجام دهید (DYOR). این مقاله بر اساس اطلاعیه‌های عمومی منتشرشده درباره این حادثه و اطلاعات درون‌زنجیره‌ای در دسترس تا تاریخ تعیین‌شده تهیه شده است. این مقاله هویت مهاجم یا توانایی Bitget برای ایفای تعهدات مالی خود را تأیید نمی‌کند، بازگشت دارایی‌ها را تضمین نمی‌کند و توصیه‌ای برای استفاده از صرافی خاصی ارائه نمی‌دهد. پیش از هر تصمیم مالی، آخرین وضعیت برداشت‌ها، گزارش‌های ذخایر، امکان استفاده از خدمات صرافی در منطقه خود، کارمزدها و ریسک‌های نگهداری دارایی‌ها را بررسی کنید.

نحوه خرید رمزارز در Toobit

برای خرید رمزارز در Toobit، وارد حساب خود شوید یا یک حساب کاربری جدید ایجاد کنید، در صورت نیاز مراحل احراز هویت را تکمیل کنید و وارد صفحه خرید رمزارز شوید. سپس رمزارز مورد نظرتان و یکی از روش‌های پرداخت موجود را انتخاب کرده و مبلغ خرید را وارد کنید.

پیش از تأیید خرید، نرخ تبدیل نمایش‌داده‌شده، کارمزدهای پرداخت، سقف خرید و مبلغ نهایی دریافتی را بررسی کنید. ارزهای پشتیبانی‌شده، روش‌های پرداخت، الزامات مربوط به حساب و دسترسی به محصولات ممکن است بسته به محل اقامت شما متفاوت باشند.

همین حالا در Toobit رمزارز بخرید.

هشدار ریسک

دارایی‌های رمزارزی با نوسانات قابل‌توجهی همراه هستند و ممکن است بخش قابل‌توجهی از ارزش خود را از دست بدهند. معامله و نگهداری رمزارزها با ریسک‌هایی از جمله زیان‌های ناشی از نوسانات بازار، حوادث امنیتی و اختلالاتی همراه است که ممکن است دسترسی به دارایی‌ها را تحت‌تأثیر قرار دهد. اثبات ذخایر و صندوق‌های حفاظت می‌توانند به افزایش شفافیت و ایجاد حمایت‌های بیشتر کمک کنند، اما ریسک‌های موجود را از بین نمی‌برند. معاملات اهرمی با ریسک بیشتری همراه هستند و ممکن است در مدت کوتاهی به زیان‌های قابل‌توجه یا لیکویید شدن پوزیشن معاملاتی منجر شوند. لطفاً پیش از انجام معامله، شرایط مالی و میزان تحمل ریسک خود را در نظر داشته باشید.