اثبات بدهی یا Proof of Liabilities (PoL) روشی برای متعهدکردن یک صرافی یا نهاد حضانتی به مجموعه‌ای از بدهی‌هایش در برابر کاربران است؛ به‌گونه‌ای که هر کاربر بتواند بررسی کند موجودی او در محاسبه کل بدهی‌ها لحاظ شده، بدون اینکه موجودی سایر کاربران عمومی شود. اهمیت PoL از یک نکته ساده می‌آید: دیدن مقدار زیادی رمزارز در کیف‌پول‌های یک صرافی کافی نیست؛ باید بدانیم در برابر همان دارایی‌ها چه میزان تعهد وجود دارد. اگر صرافی 100 میلیون دلار ذخیره قابل اثبات داشته باشد اما 120 میلیون دلار به کاربران و طرف‌های دیگر بدهکار باشد، «ذخیره زیاد» به‌تنهایی تصویر سالمی از وضعیت مالی نمی‌دهد.
در عمل، Proof of Liabilities معمولاً در کنار Proof of Assets یا Proof of Reserves معنا پیدا می‌کند. PoL سمت بدهی را نشان می‌دهد؛ PoA سمت دارایی قابل کنترل را؛ و مقایسه این دو می‌تواند یک تصویر محدود اما مفید از پوشش تعهدات ایجاد کند. با این حال، حتی نسبت پوشش بالاتر از 100 درصد نیز به معنی تضمین امنیت، نقدشوندگی یا توانگری دائمی صرافی نیست. دامنه گزارش، زمان اسنپ‌شات، بدهی‌های خارج از زنجیره، دارایی‌های در رهن و کیفیت دارایی‌ها همچنان باید جداگانه بررسی شوند.
Proof of Liabilities چیست و دقیقاً چه چیزی را اثبات می‌کند؟
Proof of Liabilities را می‌توان «اثبات رمزنگاری‌شده بدهی‌های درون دامنه گزارش» تعریف کرد. در یک صرافی متمرکز، مهم‌ترین بخش این بدهی معمولاً موجودی مشتریان است؛ یعنی رمزارز یا وجهی که کاربران در حساب خود می‌بینند و صرافی متعهد است در صورت برداشت یا تسویه به آن‌ها برگرداند. هدف PoL این نیست که نام و موجودی همه کاربران را عمومی کند، بلکه می‌خواهد صرافی را به یک مجموعه مشخص از مانده‌ها متعهد کند و امکان راستی‌آزمایی عضویت هر کاربر را فراهم سازد.
بنابراین سه ادعا از هم جدا هستند: نخست اینکه «موجودی من در محاسبه لحاظ شده است»؛ دوم اینکه «مجموع مانده‌های کاربران طبق روش اعلام‌شده برابر عدد مشخصی است»؛ و سوم اینکه «صرافی دارایی کافی برای پوشش این عدد دارد». PoL عمدتاً به دو ادعای اول مربوط است. برای ادعای سوم باید سمت دارایی نیز اثبات و شرایطی مثل مالکیت، کنترل، محدودیت حقوقی و نقدشوندگی بررسی شود.
بدهی کاربر با کل بدهی شرکت یکی نیست
یکی از مهم‌ترین نکاتی که در خواندن گزارش‌ها باید رعایت شود این است که «customer liabilities» الزاماً با «کل بدهی‌های حقوقی و اقتصادی شرکت» برابر نیست. ممکن است یک گزارش فقط مانده حساب‌های اسپات و فیوچرز کاربران را در چند دارایی پوشش دهد، اما وام بانکی، بدهی مالیاتی، تعهدات قراردادی، دعاوی حقوقی، بدهی شرکت وابسته یا برخی محصولات خارج از دامنه آن باشد. پس عبارت Proof of Liabilities را همیشه همراه با Scope گزارش بخوانید: چه نوع بدهی‌هایی، متعلق به کدام شخصیت حقوقی، در چه زمان و برای کدام دارایی‌ها وارد محاسبه شده‌اند؟
Proof of Liabilities چگونه کار می‌کند؟
مشکل اصلی این است که صرافی باید مجموع بدهی کاربران را قابل بررسی کند، اما انتشار فهرست نام حساب‌ها و مانده هر نفر نقض حریم خصوصی است. راه‌حل کلاسیک استفاده از ساختارهای تعهد رمزنگاری مانند Merkle Tree و به‌ویژه Merkle Sum Tree است. در این ساختار، اطلاعات هر حساب به یک برگ تبدیل می‌شود، سپس برگ‌ها در چند سطح ترکیب می‌شوند تا در نهایت یک ریشه یا Merkle Root ساخته شود که به کل مجموعه داده متعهد است.
Merkle Sum Tree چگونه بدهی‌ها را جمع می‌کند؟
در Merkle Sum Tree هر برگ معمولاً شامل شناسه‌ای مشتق‌شده از حساب، یک nonce یا مقدار تصادفی و مانده آن حساب است. علاوه بر هش، مقدار جمع نیز در گره‌ها نگهداری می‌شود. دو برگ در یک گره والد ترکیب می‌شوند؛ مانده آن‌ها جمع می‌شود و هش جدیدی از داده فرزندان ساخته می‌شود. این کار تا رسیدن به ریشه ادامه پیدا می‌کند. در نتیجه، ریشه هم یک تعهد رمزنگاری به مجموعه حساب‌هاست و هم می‌تواند مجموع بدهی‌های درون آن درخت را نمایندگی کند.
اگر یک مانده در درخت تغییر کند، مسیر هش آن تا ریشه تغییر خواهد کرد. همین ویژگی باعث می‌شود بعد از انتشار ریشه، صرافی نتواند بی‌صدا داده یک حساب را تغییر دهد بدون اینکه خروجی نهایی متفاوت شود. اما این ویژگی به‌تنهایی تضمین نمی‌کند که صرافی همه حساب‌های واقعی را وارد درخت کرده است؛ تشخیص حذف یک حساب به مشارکت کاربران و روش ممیزی وابسته است.
کاربر چگونه موجودی خود را در درخت بررسی می‌کند؟
برای راستی‌آزمایی، کاربر لازم نیست کل پایگاه داده را دریافت کند. صرافی می‌تواند یک Merkle Proof در اختیار او بگذارد؛ یعنی اطلاعات لازم از برگ حساب تا ریشه، شامل هش‌ها و جمع‌های همسایه. کاربر با داده حساب خود مسیر را دوباره محاسبه می‌کند و بررسی می‌کند آیا به همان ریشه منتشرشده می‌رسد یا نه. اگر برسد، می‌توان نتیجه گرفت حساب و مانده مورد استفاده در همان Snapshot داخل مجموعه متعهدشده قرار داشته است.
برای دیدن یک نمونه فنی از فرایند تولید و اعتبارسنجی بدهی‌ها، مخزن متن‌باز Proof of Liabilities بیت‌مکس نشان می‌دهد چگونه یک کاربر با nonce اختصاصی، مانده خود و total liabilities منتشرشده را بررسی می‌کند. این مثال آموزشی مفید است، اما اعتبار یک پیاده‌سازی خاص همچنان به روش اجرا، کد، دامنه و ممیزی آن بستگی دارد.
Zero-Knowledge Proof چه مشکلی را حل می‌کند؟
Merkle Sum Tree ساده می‌تواند اطلاعاتی درباره جمع مانده گره‌های همسایه افشا کند و اگر محدودیت‌های عددی به‌درستی طراحی نشده باشند، امکان سوءاستفاده از مقادیر منفی یا دستکاری محاسبات وجود دارد. راهکارهای جدیدتر از اثبات‌های دانش صفر استفاده می‌کنند تا بتوان صحت محاسبات، نامنفی بودن مانده‌ها یا قرارگرفتن مانده کاربر در محدوده مجاز را بدون افشای جزئیات حساس اثبات کرد.
از نظر پژوهشی، طرح Provisions برای اثبات حریم‌خصوصی‌محور توانگری نشان می‌دهد چگونه اثبات بدهی و اثبات دارایی می‌توانند در یک چارچوب proof of solvency کنار هم قرار گیرند. ارزش این رویکرد در این است که «شفافیت» الزاماً به معنی عمومی‌کردن اطلاعات خصوصی کاربران یا تمام آدرس‌های صرافی نیست.
تفاوت Proof of Assets، Proof of Reserves، Proof of Liabilities و Proof of Solvency
مفهوم | پرسش اصلی | چه چیزی نشان می‌دهد؟ | چه چیزی را ثابت نمی‌کند؟ |
|---|---|---|---|
Proof of Assets (PoA) | صرافی چه دارایی‌هایی را کنترل می‌کند؟ | وجود/کنترل مجموعه‌ای از دارایی‌های اعلام‌شده | میزان بدهی، مالکیت آزاد از وثیقه، کل وضعیت مالی |
Proof of Liabilities (PoL) | صرافی در دامنه گزارش چقدر به کاربران بدهکار است؟ | تعهد به مجموعه مانده‌ها و امکان inclusion verification | وجود دارایی کافی یا تمام بدهی‌های خارج از دامنه |
Proof of Reserves (PoR) | آیا دارایی اعلام‌شده با بدهی کاربران مقایسه شده است؟ | بسته به روش، assets + liabilities در یک snapshot | توانگری دائمی، internal controls، همه تعهدات حقوقی |
Proof of Solvency | آیا دارایی‌های قابل اثبات حداقل بدهی‌های قابل اثبات را پوشش می‌دهد؟ | A ≥ L در دامنه و زمان مشخص | آینده شرکت، ریسک نقدینگی، بدهی پنهان یا خارج از scope |
در بازاریابی صرافی‌ها ممکن است این واژه‌ها به‌جای هم استفاده شوند، اما برای تحلیل دقیق باید ببینید گزارش واقعاً چه چیزهایی را اندازه‌گیری کرده است. «Proof of Reserves» فقط زمانی برای سنجش پوشش تعهدات مفید است که سمت بدهی نیز تعریف و قابل راستی‌آزمایی باشد؛ در غیر این صورت دیدن کیف‌پول‌های بزرگ بیشتر شبیه اثبات دارایی است تا اثبات توانگری.
نسبت ذخایر به بدهی‌ها را چگونه بخوانیم؟
اگر گزارش برای یک دارایی 105 واحد ذخیره و 100 واحد بدهی گزارش کند، نسبت پوشش 105 درصد است. این عدد در همان Snapshot و همان Scope نشان می‌دهد ذخایر گزارش‌شده از بدهی‌های گزارش‌شده بیشتر بوده‌اند. اما سه کلمه «همان Snapshot و Scope» بسیار مهم‌اند. اگر بخشی از بدهی‌ها حذف شده باشد، برخی دارایی‌ها قرض‌گرفته یا در رهن باشند، ارزش‌گذاری دارایی‌های کم‌نقدشونده واقع‌بینانه نباشد یا پس از اسنپ‌شات وضعیت تغییر کند، 105 درصد به‌تنهایی نتیجه نهایی درباره سلامت مالی نیست.
به همین دلیل، نسبت پوشش را یک شاخص کنترل بدانید، نه گواهی ایمنی. تفاوت 100 درصد و 110 درصد نیز بدون دانستن نوسان دارایی‌ها، نقدشوندگی، ساختار بدهی و کیفیت کنترل‌های داخلی معنای محدودی دارد. در بحران برداشت، صرافی باید نه‌فقط «دارایی روی کاغذ»، بلکه دارایی آزاد، در دسترس و قابل انتقال داشته باشد.
Proof of Liabilities چه چیزهایی را ثابت نمی‌کند؟
یک PoL خوب سطح شفافیت را بالا می‌برد، اما نباید از آن نتیجه‌ای بزرگ‌تر از دامنه واقعی‌اش گرفت. این تفاوت در بازار کریپتو اهمیت زیادی دارد، چون عبارت‌های «audit»، «attestation»، «proof of reserves» و «proof of solvency» در تبلیغات گاهی مبهم استفاده می‌شوند.
هشدار رسمی PCAOB درباره محدودیت گزارش‌های Proof of Reserves تأکید می‌کند که این گزارش‌ها ذاتاً محدودند و لزوماً بدهی‌ها، حقوق دارندگان دارایی، دارایی‌های قرض‌گرفته یا کنترل‌های داخلی را بررسی نمی‌کنند. PCAOB همچنین تصریح می‌کند PoR engagement معادل حسابرسی کامل صورت‌های مالی نیست.
در همین جهت، هشدار SEC درباره خدمات اطمینان‌بخشی کریپتو نیز نسبت به بازاریابی خدمات non-audit به‌عنوان چیزی هم‌سطح حسابرسی هشدار داده است. بنابراین نام یک مؤسسه حسابداری در گزارش، به‌خودی‌خود نشان نمی‌دهد کل صورت‌های مالی یا همه تعهدات شرکت حسابرسی شده‌اند.
بدهی‌های خارج از زنجیره و تعهدات شرکت‌های وابسته
وام‌ها، حساب‌های پرداختنی، بدهی مالیاتی، دعاوی حقوقی، تعهدات قراردادی، ضمانت‌ها، بدهی شرکت‌های وابسته یا زیان‌های مشتقه ممکن است در زنجیره قابل مشاهده نباشند و بسته به طراحی گزارش، حتی وارد Merkle Tree کاربران هم نشوند. در نتیجه یک PoL مربوط به مانده مشتریان لزوماً «کل بدهی شرکت» نیست. گزارش حرفه‌ای باید Scope را دقیق بنویسد و مشخص کند چه اقلامی عمداً خارج از محاسبه هستند.
دارایی قرض‌گرفته، در رهن یا دارای حق شخص ثالث
بلاک‌چین می‌تواند وجود دارایی در یک آدرس را نشان دهد و امضای رمزنگاری می‌تواند کنترل کلید را ثابت کند، اما این دو همیشه مالکیت اقتصادی آزاد از هر حق شخص ثالث را ثابت نمی‌کنند. ممکن است دارایی قرض گرفته شده، وثیقه شده یا مشمول قرارداد دیگری باشد. برای تحلیل توانگری، وضعیت encumbrance و حقوق اشخاص ثالث اهمیت دارد.
اسنپ‌شات لحظه‌ای و مشکل زمان‌بندی
گزارش PoR/PoL معمولاً وضعیت را در یک زمان مشخص ثبت می‌کند. این مزیت دارد چون داده‌ها قابل بازتولید می‌شوند، اما محدودیت نیز ایجاد می‌کند: کاربر باید بداند فاصله بین اسنپ‌شات‌ها چقدر است، آیا تاریخچه گزارش‌ها در دسترس است و آیا روش از انتقال موقت دارایی یا «window dressing» جلوگیری می‌کند. گزارش ماه قبل درباره وضعیت امروز تضمین ایجاد نمی‌کند.
کیفیت و نقدشوندگی دارایی‌های ذخیره
دو صرافی ممکن است هر دو نسبت پوشش 105 درصد داشته باشند، اما کیفیت ذخایرشان یکسان نباشد. ذخیره‌ای که عمدتاً از BTC، ETH یا استیبل‌کوین‌های پرنقدشونده تشکیل شده با ذخیره‌ای متکی به توکن کم‌عمق، توکن وابسته به خود پلتفرم یا دارایی قفل‌شده ریسک متفاوتی دارد. PoL اندازه تعهد را می‌سنجد؛ کیفیت دارایی سمت مقابل باید جداگانه تحلیل شود.
آیا Merkle Tree می‌تواند دستکاری شود؟
Merkle Tree ابزار قدرتمندی برای تعهد به داده است، اما «درخت مرکل» به‌تنهایی تضمین کامل درستی اقتصادی داده‌ها نیست. اگر صرافی حسابی را از ابتدا وارد مجموعه نکند، آن حساب در ریشه وجود نخواهد داشت؛ کاربر حذف‌شده باید متوجه شود و اعتراض کند. در Merkle Sum Treeهای ساده نیز طراحی ضعیف می‌تواند اجازه دهد مقادیر منفی یا حساب‌های ساختگی جمع بدهی را پایین بیاورند. به همین دلیل پیاده‌سازی‌های جدید از range proof یا مدارهای دانش صفر برای اثبات نامنفی بودن و صحت جمع استفاده می‌کنند.
همچنین باید میان «صحت محاسبات روی داده ورودی» و «کامل بودن داده ورودی» فرق گذاشت. یک ZK proof می‌تواند ثابت کند محاسبه روی مجموعه ارائه‌شده درست انجام شده است؛ اما اگر برخی بدهی‌های واقعی اصلاً به مجموعه داده داده نشده باشند، اثبات رمزنگاری به‌تنهایی از وجود آن‌ها آگاه نیست. این همان جایی است که ممیزی، کنترل داخلی، مشارکت کاربران و شفافیت دامنه همچنان ضروری می‌شوند.
آیا Proof of Liabilities ورشکستگی صرافی را پیش‌بینی می‌کند؟
خیر. PoL یک ابزار پیش‌بینی ورشکستگی نیست. این روش می‌تواند نشان دهد در زمان مشخص چه مقدار بدهیِ درون دامنه گزارش وجود داشته و آیا حساب کاربر در مجموعه لحاظ شده است. حتی ترکیب PoL با Proof of Assets نیز فقط یک تصویر نقطه‌ای از پوشش ایجاد می‌کند. ورشکستگی می‌تواند از زیان معاملاتی، هک، سقوط ارزش وثیقه، برداشت گسترده، بدهی خارج از گزارش، دعوی حقوقی، اختلال بانکی یا سوءمدیریت بعدی ایجاد شود.
بهترین استفاده از PoL این است که آن را به‌عنوان یک «سیگنال شفافیت و کنترل» در کنار معیارهای دیگر ببینیم. نبود PoL یا PoR قابل راستی‌آزمایی لزوماً اثبات مشکل مالی نیست؛ همان‌طور که وجود آن نیز اثبات امنیت کامل نیست. ارزش واقعی زمانی بیشتر می‌شود که گزارش منظم، قابل تکرار، دارای روش روشن، قابل بررسی توسط کاربر و همراه با اطلاعاتی درباره بدهی‌ها، مالکیت دارایی و محدودیت‌های گزارش باشد.
چک‌لیست بررسی گزارش PoR و PoL یک صرافی
تاریخ و ساعت Snapshot را پیدا کنید و ببینید گزارش چند وقت یک‌بار تکرار می‌شود.
شخصیت حقوقی و دامنه گزارش را مشخص کنید؛ آیا گزارش کل گروه را پوشش می‌دهد یا فقط یک Entity را؟
فهرست دارایی‌های تحت پوشش را بررسی کنید؛ آیا دارایی مهمی از حساب‌های کاربران خارج مانده است؟
ببینید total liabilities چگونه ساخته شده و آیا کاربر می‌تواند Merkle Proof یا روش معادل را شخصاً بررسی کند.
بررسی کنید سازوکار از مانده منفی، overflow/underflow یا دستکاری جمع جلوگیری می‌کند یا نه؛ ZK/range proof می‌تواند امتیاز مثبت باشد.
سمت دارایی را جدا بررسی کنید: آیا کنترل کیف‌پول‌ها اثبات شده یا فقط آدرس‌ها فهرست شده‌اند؟
وضعیت دارایی‌های قرض‌گرفته، در رهن، pledged یا دارای حق شخص ثالث را جویا شوید.
نقدشوندگی و کیفیت ذخایر را بسنجید؛ مقدار زیاد توکن کم‌عمق با دارایی نقدشونده یکسان نیست.
نوع گزارش شخص ثالث را بخوانید: audit، examination، attestation یا agreed-upon procedures را با هم یکی ندانید.
نسبت پوشش را فقط در همان Scope و Snapshot تفسیر کنید و آن را با سابقه امنیتی، شرایط برداشت و ساختار نگهداری دارایی ترکیب کنید.
اگر بعد از این بررسی می‌خواهید گزینه‌ها را کنار هم بسنجید، می‌توانید از صفحه مقایسه صرافی‌های ارز دیجیتال برای ادامه مسیر انتخاب استفاده کنید؛ اما وضعیت PoR/PoL، محدودیت جغرافیایی و شرایط هر صرافی باید در همان روز از منابع رسمی خودش دوباره کنترل شود.
نمونه‌های واقعی چه چیزی به ما یاد می‌دهند؟
برای نمونه، گزارش Proof of Reserves کراکن توضیح می‌دهد که فرآیند این پلتفرم شامل مجموع liabilities مشتریان، امکان راستی‌آزمایی رمزنگاری موجودی و بررسی کنترل دارایی‌های روی زنجیره توسط شخص ثالث است. نکته آموزشی این مثال ساختار گزارش است، نه نتیجه‌گیری دائمی درباره ریسک یک صرافی.
در نمونه‌ای دیگر، صفحه Proof of Reserves بایننس استفاده از Merkle Tree را برای بررسی حضور حساب‌ها در liabilities report و zk-SNARK را برای اعتبارسنجی محاسبات توضیح می‌دهد. این نمونه نشان می‌دهد PoRهای جدید می‌توانند از یک فهرست ساده آدرس‌ها فراتر بروند؛ با این حال محدودیت‌های Scope، Snapshot و بدهی‌های خارج از گزارش همچنان پابرجاست.
در بررسی هر برند، روش را به نام برند ترجیح دهید: آیا گزارش قابل راستی‌آزمایی است؟ آیا بدهی و دارایی هر دو تعریف شده‌اند؟ آیا گزارش تاریخی و منظم است؟ آیا شرایط خارج از زنجیره و دارایی‌های دارای محدودیت روشن شده‌اند؟ این سؤالات از یک badge تبلیغاتی ارزش بیشتری دارند.
سؤالات متداول
آیا Proof of Liabilities همان حسابرسی مالی است؟
خیر. PoL یک مکانیزم یا جزء اثبات برای بدهی‌های تعریف‌شده در Scope است. حسابرسی صورت‌های مالی دامنه‌ای بسیار گسترده‌تر دارد و می‌تواند شامل درآمد، هزینه، بدهی‌های مختلف، کنترل‌ها، اشخاص وابسته و شواهد حسابداری باشد. نوع engagement شخص ثالث را باید از متن گزارش خواند، نه از اصطلاحات بازاریابی.
اگر نسبت ذخایر بالاتر از 100 درصد باشد، صرافی کاملاً امن است؟
خیر. این نسبت فقط می‌گوید در دامنه و زمان گزارش، دارایی‌های محاسبه‌شده از بدهی‌های محاسبه‌شده بیشتر بوده‌اند. بدهی خارج از دامنه، دارایی در رهن، نوسان قیمت، نقدشوندگی و رویدادهای بعد از Snapshot می‌توانند نتیجه را تغییر دهند.
Merkle Proof دقیقاً چه چیزی را به کاربر ثابت می‌کند؟
Merkle Proof نشان می‌دهد داده حساب شما در مجموعه‌ای که به Merkle Root منتشرشده متعهد شده وجود دارد و مسیر هش آن معتبر است. این اثبات به‌تنهایی نمی‌گوید همه حساب‌های دیگر وارد مجموعه شده‌اند یا کل بدهی‌های حقوقی شرکت پوشش داده شده است.
چرا بدهی‌های خارج از زنجیره مهم‌اند؟
زیرا بلاک‌چین فقط بخشی از واقعیت اقتصادی یک شرکت را نشان می‌دهد. وام، مالیات، تعهد قراردادی، دعوی حقوقی یا بدهی شرکت وابسته ممکن است روی زنجیره قابل مشاهده نباشد اما بر توان پرداخت اثر بگذارد.
PoL برای کاربران ایرانی چه فایده‌ای دارد؟
برای کاربر ایرانی نیز ارزش PoL در امکان سنجش شفافیت نگهداری دارایی است، نه در رفع ریسک‌های تحریم، KYC یا دسترسی. حتی اگر یک صرافی PoR/PoL مناسبی منتشر کند، محدودیت جغرافیایی، امکان برداشت، ریسک مسدودشدن حساب و شرایط حقوقی باید جداگانه بررسی شوند.
جمع‌بندی
Proof of Liabilities نیمه‌ای است که بدون آن دیدن ذخایر صرافی می‌تواند گمراه‌کننده باشد. PoL تلاش می‌کند مجموع بدهی‌های تعریف‌شده، به‌ویژه مانده کاربران، را به‌صورت رمزنگاری‌شده متعهد کند و به هر کاربر امکان دهد حضور موجودی خود را بررسی کند. Merkle Sum Tree این کار را به‌صورت کارآمد انجام می‌دهد و روش‌های دانش صفر می‌توانند حریم خصوصی و صحت محاسبات را بهتر کنند.
با این حال، گزارش خوب را نباید به ضمانت سلامت مالی تبدیل کرد. نسبت پوشش، Merkle Root و تأیید شخص ثالث فقط وقتی معنا دارند که Scope، timestamp، نوع engagement، دارایی‌های آزاد از وثیقه، بدهی‌های خارج از زنجیره و کیفیت ذخایر روشن باشند. برای تصمیم عملی، PoL را یکی از لایه‌های ارزیابی ریسک حضانتی بدانید؛ نه جایگزین حسابرسی کامل و نه مجوز نگهداری بلندمدت همه دارایی‌ها در یک صرافی.
