«کدام صرافی امن‌تر است؟» سؤال ساده‌ای به نظر می‌رسد، اما پاسخ آن با یک نام یا رتبه‌بندی ثابت به دست نمی‌آید. وقتی پول یا رمزارزتان را وارد یک پلتفرم می‌کنید، تنها با خطر هک روبه‌رو نیستید؛ ممکن است برداشت در زمان حساس متوقف شود، کنترل یک حساب به دست فرد دیگری بیفتد، دارایی مشتریان از دارایی شرکت جدا نباشد یا شرایط استفاده برای محل اقامت شما محدودیت ایجاد کند. صرافی‌ای که یکی از این خطرها را خوب مدیریت می‌کند، لزوماً در همه موارد عملکرد مشابهی ندارد.
در این راهنما یک مسیر بررسی ارائه می‌کنیم: چه مدرکی بخواهید، چه گزینه‌ای را در حساب خود بررسی کنید، کدام ادعا صرفاً تبلیغاتی است و در برابر علامت خطر چه تصمیمی بگیرید. این روش برای ارزیابی هر صرافی ارز دیجیتال کاربرد دارد و تضمین‌کننده نبودِ ریسک نیست. در نهایت، امن‌بودن یک پلتفرم به ترکیبی از امنیت فنی، امانت‌داری، نقدشوندگی، پاسخ‌گویی و تناسب حقوقی با وضعیت کاربر وابسته است.
ثبت تراکنش در بلاکچین، به خودی خود امنیت حساب صرافی را تضمین نمی‌کند. مهاجم ممکن است بدون دستکاری شبکه، رمز عبور یا نشست کاربر را به دست بیاورد؛ یا مشکل از سرور، سازوکار امضای برداشت، حسابداری داخلی یا خطای انسانی باشد. حتی اگر دارایی‌ها روی زنجیره قابل مشاهده باشند، مالک واقعی آن‌ها و تعهد صرافی در قبال مشتری از روی آدرس کیف پول به‌تنهایی مشخص نمی‌شود.
سه پرسش را از هم جدا کنید: آیا حساب من در برابر دسترسی غیرمجاز محافظت می‌شود؟ آیا دارایی‌های مشتری به‌درستی نگهداری و ثبت می‌شوند؟ اگر مشکلی رخ دهد، آیا برداشت، پیگیری و پاسخ‌گویی مشخص است؟ پاسخ مثبت به یکی، جای دو پرسش دیگر را نمی‌گیرد.
رتبه‌بندی معتبر به دوره زمانی، حوزه قضایی، روش امتیازدهی، وزن معیارها، مدارک و محدودیت داده نیاز دارد. اگر این موارد منتشر نشده باشد، مقام اول یا سوم صرفاً برداشت نویسنده است. «تا امروز هک نشده»، «احراز هویت دارد» و «کاربران زیادی دارد» هم هرکدام تنها یک نشانه محدودند، نه اثبات امنیت. گاهی نبود گزارش رخداد به معنای نبود رخداد نیست؛ ممکن است درباره حادثه اطلاعات کافی منتشر نشده باشد.
نقطه آغاز ارزیابی، شیوه نگهداری دارایی‌های سپرده‌شده است. صرافی برای پاسخ به برداشت‌های روزمره معمولاً به موجودی در دسترس نیاز دارد و برای دارایی‌های کم‌گردش‌تر می‌تواند کنترل‌های محدودکننده‌تری به کار ببرد. اصطلاح‌های «کیف پول گرم» و «کیف پول سرد» تنها بخشی از ماجرا را توضیح می‌دهند: اولی معمولاً اتصال و آمادگی بیشتری برای عملیات دارد و دومی در پی کاهش مواجهه مستقیم کلیدها با محیط‌های آنلاین است. هیچ‌کدام به‌تنهایی تضمین نیستند.
حال که به اینجای مقاله رسیدیم و کمی درباره امنیت صرافی‌ها و اهمیت آن دانستیم، وقت آن است تا فهرستی از امن ترین صرافی ارز دیجیتال در سال ۲۰۲۵ را بررسی کنیم. در ادامه می‌توانید این فهرست را مشاهده کنید.
| نام | kyc | AML | سابقه هک | ذخیره سازی سرد |
| بایننس | ✅ | ✅ | ❌ | ❌ |
| کراکن | ✅ | ✅ | ❌ | ✅ |
| بیت استمپ | ✅ | ✅ | ❌ | ✅ |
| ایران اکسچنج | ✅ | ✅ | ندارد | ❌ |
| بیت مارت | ✅ | ✅ | ❌ | ✅ |
| کوین بیس | ✅ | ✅ | ندارد | ✅ |
| بیتفینکس | ✅ | ✅ | ❌ | ✅ |
| هوبی | ✅ | ✅ | ❌ | ✅ |
| هیت بی تی سی | ✅ | ✅ | ❌ | ❌ |
| جمینی | ✅ | ✅ | ❌ | ✅ |
| اوکی اکس | ✅ | ✅ | ❌ | ✅ |
| کوکوین | ✅ | ✅ | ❌ | ✅ |
| آپهولد | ✅ | ✅ | ❌ | ✅ |
| کریپتو‌دات‌کام | ✅ | ✅ | ❌ | ❌ |
ببینید پلتفرم درباره نگهداری دارایی‌های مشتری، تفکیک دسترسی کارکنان، مجوز امضای تراکنش‌ها و فرایند بازیابی در شرایط اضطراری چه توضیحی میدهد. آیا هر فرد با یک دسترسی می‌تواند انتقال عمده انجام دهد؟ آیا برداشت‌های بزرگ کنترل بیشتری دارند؟ آیا در مستندات عمومی حداقل شرحی از بازبینی دوره‌ای و ثبت رویدادها وجود دارد؟ ممکن است جزئیات کامل به‌دلیل ملاحظات امنیتی منتشر نشود؛ اما نبود هرگونه توضیح و سند، امکان ارزیابی را محدود می‌کند.
امضای چندگانه و محاسبات چندطرفه (MPC) می‌توانند ریسک وابستگی به یک کلید یا یک شخص را کاهش دهند، مشروط به طراحی و پیاده‌سازی درست. اگر همان فرد بتواند همه مجوزها را دور بزند، استفاده از واژه «چندامضایی» ارزش عملی چندانی ندارد. همچنین «۹۹ درصد دارایی در کیف پول سرد» بدون تاریخ، روش اندازه‌گیری و تأیید مستقل، یک ادعای کمّیِ تأییدنشده است.
یک خطر مهم، مخلوط‌شدن وجوه مشتری با دارایی عملیاتی یا استفاده از آن برای تعهدات دیگر است. ارزیابی باید میان جداسازی حسابداری، جداسازی حقوقی مالکیت و کنترل عملی انتقال فرق بگذارد. توصیه‌های نهادهای بین‌المللی تنظیم‌گری نیز بر حفاظت از دارایی مشتری، تفکیک و افشای خطرهای امانت‌داری تأکید کرده‌اند. وجود این توصیه‌ها نشان نمی‌دهد که یک صرافی خاص آن‌ها را اجرا کرده است.
اگر مهاجم بتواند وارد حساب شود، حتی زیرساخت حرفه‌ای نگهداری دارایی هم تمام خطر را از بین نمی‌برد. رمز عبور تکراری، صفحه ورود جعلی، سرقت نشست، بدافزار و حمله به روش بازیابی حساب، مسیرهای متفاوتی برای دسترسی غیرمجازند. نخستین کار شما انتخاب گذرواژه بلند و یکتا و نگهداری آن در مدیر رمز معتبر است؛ اما کنترل دوم ورود هم اهمیت دارد.
کدهایی که به‌صورت دستی از پیامک یا برنامه تولید رمز وارد می‌شوند، ممکن است در سایت جعلی دریافت و بلافاصله برای ورود به سایت واقعی استفاده شوند. بر اساس راهنمای NIST SP 800-63B-4، OTP دستی در برابر فیشینگ مقاوم نیست؛ در مقابل، سازوکارهای مبتنی بر FIDO2/WebAuthn می‌توانند با اتصال رمزنگاری‌شده به نام دامنه، مقاومت بهتری در برابر جعل صفحه ورود ایجاد کنند. این تمایز مهم است، ولی Passkey هم شما را از همه انواع بدافزار، خطای حساب یا سوءاستفاده از نشست مصون نمی‌کند.
اگر صرافی از کلید امنیتی یا Passkey پشتیبانی می‌کند، گزینه‌ها و سازوکار بازیابی آن را پیش از فعال‌سازی مطالعه کنید. اگر تنها OTP در دسترس است، استفاده از آن معمولاً از نداشتن عامل دوم بهتر است؛ در عین حال باید دامنه سایت را با دقت کنترل کنید و کد را به هیچ شخص یا پشتیبانی ارائه ندهید.
بعضی حساب‌ها در ورود اولیه محافظت خوبی دارند، اما در «فراموشی رمز»، تغییر تلفن، تعویض ایمیل یا درخواست پشتیبانی آسیب‌پذیرند. بررسی کنید آیا پس از ورود از دستگاه ناشناس هشدار دریافت می‌کنید، فهرست نشست‌ها قابل مشاهده و پایان‌دادن به آن‌ها ممکن است، و تغییر عوامل امنیتی چه تأثیری بر برداشت دارد. دوره تأخیر منطقی پس از تغییر اطلاعات حساس می‌تواند مفید باشد، ولی نباید به مسدودسازی نامحدود و بدون پاسخ‌گویی تبدیل شود.
امنیت فقط جلوگیری از ورود غیرمجاز نیست؛ باید حرکت دارایی از حساب نیز قابل کنترل باشد. وقتی برداشت ثبت می‌کنید، اشتباه در انتخاب شبکه یا مقصد می‌تواند حتی بدون وقوع حمله هم باعث از دست رفتن پول شود. برخی پلتفرم‌ها برای آدرس‌های مجاز برداشت، تأیید اضافه، توقف موقت تغییرات حساس و اعلان برداشت امکان‌هایی دارند؛ وجود دقیق هر قابلیت باید در همان پلتفرم بررسی شود.
پیش از انتقال مبلغ قابل توجه، نام شبکه و سازگاری مقصد را مستقل بررسی کنید. اگر آدرس را کپی کرده‌اید، چند کاراکتر ابتدا و انتهای آن را با آدرس اصلی بسنجید؛ بدافزار تغییر کلیپ‌بورد ممکن است مقصد را عوض کند. با مبلغی کوچک و با درنظرگرفتن کارمزد آزمایش کنید؛ سپس بعد از تأیید رسیدن دارایی و روشن‌شدن وضعیت شبکه، مبلغ اصلی را منتقل کنید. آزمایش کوچک نیز خطای شبکه یا محدودیت برداشت را به‌طور کامل حذف نمی‌کند.
دسترسی API برای ابزارهای تحلیلی یا ثبت سفارش می‌تواند مفید باشد، اما کلیدی با مجوز برداشت از کلید صرفاً خواندنی پرخطرتر است. اصل «حداقل دسترسی» را اجرا کنید: مجوزها را به نیاز واقعی محدود کنید، کلیدهای بلااستفاده را حذف کنید، در صورت وجود محدودسازی IP آن را ارزیابی کنید و کلید را داخل فایل عمومی یا پیام‌رسان نفرستید. هیچ‌گاه برای دریافت پشتیبانی، کد بازیابی یا کلید API کامل را برای فرد ناشناس ارسال نکنید.
گزارش Proof of Reserves یا «اثبات ذخایر» معمولاً می‌کوشد نشان دهد در زمان مشخصی چه دارایی‌هایی تحت کنترل مجموعه قرار داشته‌اند. روش‌هایی مانند درخت مرکل ممکن است به مشتری امکان دهند وجود مانده ثبت‌شده خود را در مجموعه‌ای از داده‌ها بررسی کند؛ بااین‌حال حتی صحت فنی یک اثبات، همه پرسش‌های مالی و حقوقی را پاسخ نمی‌دهد.
h3>مسئله بدهی‌ها و تعهدات پنهان
برای تصور موضوع، یک مثال کاملاً فرضی در نظر بگیرید: اگر دارایی قابل مشاهده یک مجموعه ۱۰۰ واحد باشد، ولی تعهدات آن ۱۱۰ واحد، مشاهده ۱۰۰ واحد دارایی به‌تنهایی نشانه توان پرداخت نیست. علاوه بر مقدار بدهی، مالکیت واقعی دارایی، وثیقه‌بودن یا قرض‌گرفتن موقت آن و تاریخ ثبت داده‌ها اهمیت دارد. به همین علت PCAOB هشدار داده که گزارش‌های PoR با حسابرسی کامل صورت‌های مالی یکسان نیستند و ممکن است بدهی‌ها یا حقوق کاربران را پوشش ندهند.
تاریخ snapshot چیست؟ چه دارایی‌ها و شبکه‌هایی پوشش داده شده‌اند؟ آیا تعهدات به مشتریان نیز روشن شده است؟ چه نهادی گزارش را تهیه کرده و دامنه کار او چه بوده؟ آیا نتیجه به‌صورت قابل تکرار یا مستقل بررسی‌پذیر است؟ اگر فقط یک نمودار رنگی از کیف پول‌ها می‌بینید، آن را معادل گواهی سلامت مالی تعبیر نکنید.
| شواهد | چه چیزی را نشان میدهد؟ | چه چیزی را لزوماً نشان نمی‌دهد؟ |
|---|---|---|
| موجودی آدرس روی زنجیره | مقدار دارایی یک آدرس در زمان مشاهده | مالکیت حقوقی یا نبود وثیقه بر دارایی |
| اثبات درخت مرکل | درج یک رکورد در مجموعه داده اعلام‌شده | کامل‌بودن تمام بدهی‌ها یا نبود حساب‌های حذف‌شده |
| گزارش حسابرس با دامنه محدود | نتیجه کار انجام‌شده در محدوده مشخص | پوشش همه عملیات، همه زمان‌ها یا تضمین آینده |
| صورت‌های مالی قابل اتکا | اطلاعات گسترده‌تر از وضعیت مالی | حذف کامل ریسک نقدینگی و عملیاتی |
برای سنجش سابقه، از تعداد سال‌های فعالیت شروع نکنید و همان‌جا متوقف نشوید. ببینید در رخدادهای گزارش‌شده چه اتفاقی افتاده، چه تعداد حساب یا چه نوع دارایی تحت تأثیر بوده، چه زمانی به کاربران اطلاع داده شده و آیا گزارش اصلاحات یا نتیجه بررسی منتشر شده است. حادثه امنیتی می‌تواند برای مجموعه‌های باتجربه هم رخ دهد؛ تفاوت مهم در صداقت، سرعت رسیدگی، کاهش خسارت و اصلاح علت ریشه‌ای است.
حسابرسی کد یک قرارداد هوشمند، آزمون نفوذ یک سامانه، گواهی مدیریت امنیت اطلاعات و بررسی صورت‌های مالی، چهار کار متفاوت هستند. گواهی ISO/IEC 27001 اگر واقعی و معتبر باشد، درباره محدوده تعیین‌شده یک نظام مدیریت امنیت اطلاعات صحبت می‌کند؛ به‌تنهایی ضمانت نمی‌دهد که صرافی هرگز هک نشود. استاندارد CCSS نیز برای سامانه‌های مرتبط با رمزارز تدوین شده است، اما صرف نوشتن نام آن در سایت به معنی گذراندن ارزیابی مستقل نیست.
در مورد هر گواهی یا بررسی، نام مرجع صادرکننده، تاریخ اعتبار، دامنه پوشش، نسخه استاندارد و امکان استعلام را بررسی کنید. اگر گزارش مربوط به یک محصول محدود است، آن را به تمام کسب‌وکار تعمیم ندهید. ادعای داشتن بیمه نیز بدون متن پوشش، سقف تعهد، استثناها و نام بیمه‌گر معنای روشنی برای کاربر ندارد.
پشتیبانی پاسخ‌گو، صفحه وضعیت خدمات، اطلاع‌رسانی روشن درباره اختلال و مسیر شکایت مستند، بخشی از تجربه امنیت است. اعلان زودهنگام همیشه به معنی حل فوری نیست، اما سکوت طولانی و تغییر پیاپی توضیحات بدون سند، ارزیابی اعتماد را دشوار می‌کند. ببینید آیا پلتفرم درباره رخدادهای مهم گزارش پس از حادثه، اقدامات اصلاحی و تکلیف مشتریان منتشر کرده است.
استفاده از یک پلتفرم فقط موضوع سرعت و امکانات نیست. پیش از افتتاح حساب یا انتقال دارایی، شرایط استفاده، محدودیت جغرافیایی، شرایط اقامت و احراز هویت، سازوکار حل اختلاف، مقررات مرتبط با خدمات پرداخت و احتمال توقف دسترسی را بررسی کنید. این شرایط ممکن است تغییر کنند؛ از یک تصویر قدیمیِ صفحه ثبت‌نام نمی‌توان مجازبودن فعلی خدمات را نتیجه گرفت.
وجود KYC (شناخت مشتری) یا AML (مبارزه با پول‌شویی) می‌تواند در چارچوب الزامات شناسایی و کنترل ریسک مالی معنا داشته باشد، اما اثبات ایمن‌بودن زیرساخت فنی یا تضمین حفظ پول نیست. همچنین ثبت شرکت در یک کشور، الزاماً به معنی نظارت مستقیم بر همه خدمات رمزارزی آن شرکت نیست. ادعای مجوز را با عنوان مجوز، مرجع صادرکننده، قلمرو فعالیت و تاریخ اعتبار تطبیق دهید.
تغییر مسیر اتصال، کشور IP یا تنظیمات نرم‌افزاری، شرایط قرارداد و تعهدات حقوقی پلتفرم را تغییر نمی‌دهد. پیش از واریز، بررسی کنید آیا پلتفرم واقعاً به کشور محل اقامت و مدارک هویتی شما خدمات میدهد و در صورت مسدودسازی حساب چه رویه‌ای برای بازگرداندن دارایی وجود دارد. اگر پاسخ روشن نیست، دارایی را صرفاً به امید اینکه «دیگران هم استفاده می‌کنند» منتقل نکنید.
برای استفاده عملی از این راهنما، هر معیار را با یکی از سه وضعیت «مدرک قابل مشاهده»، «فقط ادعا» و «نامشخص» ثبت کنید. نبود سند عمومی الزاماً اثبات ناامنی نیست؛ اما برای تصمیمی که به سرمایه شما مربوط می‌شود، باید به معنای عدم قطعیت باشد. اگر چند معیار حیاتی مثل امکان برداشت، مالکیت دارایی و پاسخ‌گویی نامشخص هستند، با مبلغ زیاد آزمون نکنید.
| محور بررسی | مدرک یا آزمایش قابل انجام | علامت هشدار |
|---|---|---|
| دسترسی به حساب | روش MFA، نشست‌ها و فرایند بازیابی | درخواست کد محرمانه توسط پشتیبانی |
| حفاظت از دارایی | افشای سیاست نگهداری و جداسازی وجوه | ادعای مطلق «غیرقابل هک» |
| برداشت | شرایط کارمزد، شبکه، محدودیت و زمان‌بندی | تغییر ناگهانی شرایط بدون توضیح |
| شفافیت مالی | تاریخ و دامنه گزارش ذخایر و بدهی‌ها | استفاده از PoR به‌عنوان تضمین قطعی |
| سابقه پاسخ‌گویی | گزارش رخداد، اصلاحات و کانال شکایت | گزارش‌های بدون تاریخ و پاسخ‌گویی |
| وضعیت حقوقی | شرایط استفاده و دامنه مجوز قابل استعلام | تضاد کشور اقامت با شرایط خدمات |
فرض کنید پلتفرم «الف» ورود مقاوم به فیشینگ دارد، ولی درباره تفکیک دارایی مشتری اطلاعات عمومی کافی نداده است. پلتفرم «ب» اسناد بهتری درباره امانت‌داری ارائه می‌کند، اما ورود آن فقط به رمز و پیامک متکی است. نتیجه درست این نیست که یکی را بی‌قیدوشرط «امن‌تر» بنامیم؛ برای کاربری که موجودی زیادی را بلندمدت نگه می‌دارد، موضوع امانت‌داری ممکن است اولویت بیشتری داشته باشد و برای کاربر دیگری خطر تصاحب حساب. در هر دو مورد باید نقص‌های حیاتی را جدا ثبت کرد.
می‌توانید به هر معیار بر اساس اهمیت شخصی وزن بدهید، اما عدد نهایی را با گواهی رسمی یا احتمال واقعی زیان اشتباه نگیرید. امتیازدهی شخصی فقط ابزار نظم‌دادن به تصمیم است، نه نتیجه یک آزمون مستقل امنیتی.
یک: دامنه و مسیر ارتباط رسمی را ذخیره کنید و از لینک‌های تبلیغاتی یا پیام‌های ناشناس وارد نشوید. دو: امنیت حساب، عوامل بازیابی و اعلان‌های ورود را تنظیم کنید؛ در صورت امکان از روش مقاوم به فیشینگ استفاده کنید. سه: شرایط برداشت و شبکه مقصد را قبل از واریز بررسی کنید و برای نخستین انتقال، خطر خطا و کارمزد را با یک آزمایش کوچک بسنجید. هیچ‌کدام از این گام‌ها به‌تنهایی خطر صرافی را به صفر نمی‌رسانند.
پس از بررسی امنیت پلتفرم، نوبت به تصمیم معاملاتی می‌رسد. برای آشنایی با مسیر و شرایط خرید ارز دیجیتال، ابتدا هزینه نهایی، شبکه انتقال و محدودیت‌های برداشت را بشناسید؛ برای پیگیری عمومی تغییرات بازار نیز می‌توانید صفحه قیمت ارز دیجیتال را بررسی کنید. این دو مرحله، بررسی امنیت و امانت‌داری را حذف نمی‌کنند.
اگر هدف شما نگهداری بلندمدت دارایی است، تفاوت کیف پول شخصی و نگهداری امانی نزد پلتفرم را نیز در نظر بگیرید. در کیف پول شخصی، مسئولیت پشتیبان‌گیری و حفاظت از عبارت بازیابی با خود شماست و افشای آن می‌تواند غیرقابل جبران باشد؛ در نگهداری امانی، بخشی از کنترل در اختیار ارائه‌دهنده خدمت قرار می‌گیرد. هیچ گزینه‌ای برای همه افراد و همه شرایط بهترین نیست.
اهمیت امنیت معمولاً تا زمانی که همه چیز درست کار می‌کند پنهان می‌ماند. بهتر است قبل از نخستین واریز بدانید اگر کد ورود به دست دیگری افتاد، برداشت معلق شد یا پلتفرم اعلام اختلال کرد چه راهی برای کنترل وضعیت دارید. واکنش عجولانه، به‌ویژه کلیک روی لینک «بازیابی فوری» که در پیام ناشناس می‌رسد، می‌تواند خسارت مسئله اولیه را بیشتر کند.
اگر اعلان ورود ناشناسی دریافت کردید، ابتدا از نشانی رسمی و ذخیره‌شده وارد شوید؛ روی لینک موجود در خود پیام هشدار کلیک نکنید. نشست‌های فعال را بررسی و در صورت امکان نشست ناشناس را قطع کنید. سپس از دستگاهی که به سلامت آن اطمینان دارید گذرواژه را تغییر دهید، عوامل احراز هویت و روش‌های بازیابی را بازبینی کنید و احتمال آلوده‌بودن ایمیل یا رایانه خود را نیز در نظر بگیرید. اگر برداشت مشکوک ثبت شده، بدون اتلاف وقت از مسیر رسمی پشتیبانی درخواست بررسی دهید و زمان‌ها و شناسه‌های مرتبط را ثبت کنید. مسیر مسدودسازی حساب در همه صرافی‌ها یکسان نیست؛ نمی‌توان آن را بدون سند به نام یک دکمه مشخص آموزش داد.
توقف برداشت لزوماً نشانه هک نیست. ممکن است ازدحام شبکه، نگهداری فنی، مغایرت اطلاعات، هشدار امنیتی یا محدودیت حقوقی وجود داشته باشد. ابتدا وضعیت شبکه و اعلان‌های رسمی را بخوانید و شماره درخواست را ثبت کنید. سپس بپرسید آیا توقف مربوط به همه کاربران است یا حساب شما، دلیل چیست، و چه سندی برای رفع محدودیت لازم است. اگر علت اعلام نشده یا پاسخ‌ها مرتب تغییر می‌کنند، این عدم قطعیت را در ارزیابی خود ثبت کنید. برای «آزادسازی» دارایی، وجه اضافه را به نشانی اعلام‌شده در پیام ناشناس نفرستید؛ کلاهبرداران از اضطراب کاربران در چنین شرایطی سوءاستفاده می‌کنند.
میان «پلتفرم اعلام کرده خسارت را جبران می‌کند» و «بیمه‌نامه معتبر برای این نوع خسارت وجود دارد» فاصله زیادی است. سقف، استثناها، موضوع پوشش، ذی‌نفع و فرایند مطالبه باید روشن باشد. بعضی پوشش‌ها ممکن است صرفاً بخشی از دارایی امانی را در شرایط محدود شامل شوند و خطای شخصی کاربر یا سرقت ناشی از افشای اطلاعات را پوشش ندهند. تا زمانی که متن حقوقی و شرایط واقعی در دسترس نیست، جبران کامل را پیش‌فرض تصمیم خود قرار ندهید.
نتیجه یک بررسی امنیتی برای همیشه معتبر نمی‌ماند. شرکت ممکن است مالک جدید پیدا کند، سیاست برداشت یا ذخیره دارایی را عوض کند، برنامه‌های احراز هویت را به‌روزرسانی کند یا با محدودیت منطقه‌ای روبه‌رو شود. یک پوشه ساده از پیوند شرایط استفاده، تاریخ اسناد، عکسِ عمومی از اعلان‌ها و شماره پشتیبانی نگه دارید. هر تغییر مهم در این موارد می‌تواند دلیل کافی برای بررسی مجدد محل نگهداری دارایی‌ها باشد؛ حتی اگر تجربه قبلی شما بدون مشکل بوده است.
صرافی امن را نمی‌توان فقط از ظاهر سایت، شمار کاربران یا ادعای نگهداری سرد تشخیص داد. اگر قرار است سرمایه‌ای به یک سرویس بسپارید، امنیت حساب، حفاظت از دارایی، اعتبار گزارش‌ها، امکان برداشت، سابقه پاسخ‌گویی و حق استفاده از خدمات را کنار هم بگذارید. هرجا داده قابل بررسی ندارید، آن را «نامشخص» ثبت کنید، نه «تأییدشده». همین تفکیک ساده معمولاً از اعتماد به وعده‌های مطلق مفیدتر است.
این مقاله برای آموزش روش ارزیابی تهیه شده و تأییدیه امنیتی برای هیچ ارائه‌دهنده‌ای صادر نمی‌کند. برای اطلاعات مقدماتی خدمات و ساختار پلتفرم می‌توانید از صفحه صرافی ارز دیجیتال شروع کنید، اما قبل از هر اقدام مالی، شرایط جاری و مدارک مرتبط را مستقل بررسی کنید.
این مقاله بر رتبه‌بندی یا آزمون میدانی یک صرافی خاص متکی نیست. برای بررسی ادعاهای کلیدی می‌توانید به این منابع اولیه مراجعه کنید: راهنمای احراز هویت NIST، هشدار PCAOB درباره محدودیت اثبات ذخایر، توضیح رسمی استاندارد CCSS، توصیه‌های IOSCO در چارچوب FSB برای نگهداری دارایی و کنترل ریسک و راهنمای FATF برای ارائه‌دهندگان خدمات دارایی مجازی. تاریخ و دامنه انتشار هر سند را هنگام استفاده بررسی کنید؛ اشاره به استانداردها، گواهی امنیتی برای ایران اکسچنج یا هر پلتفرم دیگر صادر نمی‌کند.
خیر. 2FA تنها بخشی از کنترل دسترسی حساب را تقویت می‌کند. نوع عامل دوم، فرایند بازیابی، کنترل برداشت، شیوه نگهداری دارایی و پاسخ‌گویی عملیاتی هم اهمیت دارند؛ افزون بر این، کد یک‌بارمصرف دستی در برابر فیشینگ مقاوم محسوب نمی‌شود.
خیر. نگهداری سرد می‌تواند احتمال مواجهه مستقیم کلیدها با تهدید آنلاین را کاهش دهد؛ ولی خطای عملیاتی، سوءاستفاده داخلی، فرایند امضای ضعیف یا نقص بازیابی همچنان ممکن‌اند.
خیر. اثبات ذخایر ممکن است بخشی از موجودی را در لحظه‌ای مشخص نشان دهد، اما به‌تنهایی همه بدهی‌ها، تعهدات و مالکیت قانونی دارایی‌ها را روشن نمی‌کند. دامنه گزارش را بخوانید و از فرض «توان پرداخت تضمین‌شده» پرهیز کنید.
نام دقیق استاندارد، مرجع مستقل، تاریخ اعتبار، دامنه سیستم بررسی‌شده و راه استعلام نتیجه را پیدا کنید. عبارت «دارای استاندارد جهانی» بدون سند و دامنه، برای تصمیم کافی نیست.
نه لزوماً. حتی زیرساخت قوی هم محدودیت جغرافیایی، شروط هویتی، ریسک مسدودسازی یا دشواری پیگیری حقوقی را رفع نمی‌کند. تناسب قانونی خدمات با محل اقامت و شرایط کاربر باید جدا سنجیده شود.
