دفتر دارایی در RWA چیست و چرا برای پولِ ورود/خروج و کسر هزینه‌ها حیاتی است؟

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

مقدمه

در محصولات RWA یا «دارایی‌های واقعیِ توکنیزه‌شده»، معمولاً اول از همه سراغ رجیستری مالکیت می‌رویم؛ یعنی جایی که مشخص می‌کند هر فرد چند واحد دارد و انتقال واحدها چگونه ثبت می‌شود. این لایه لازم است، اما برای عملیات تمیز و مقیاس‌پذیر کافی نیست.

برای اینکه یک واحد پشتوانه‌دار بدون بدهی پنهان رشد کند، باید مسیر پول هم استاندارد و قابل استعلام باشد: پولِ ورود، پولِ خروج، اقلام کارمزد و هزینه، و تسویه‌های دوره‌ای. در این مقاله تفاوت رجیستری مالکیت با دفتر دارایی را روشن می‌کنیم و یک نقشه حداقلی برای طراحی «پولِ ورود/خروج + کسر هزینه‌ها + گزارش‌گیری قابل تطبیق» ارائه می‌دهیم.

طرح مسئله

سؤال عملی بسیاری از تیم‌ها ساده به نظر می‌رسد: «ما واحدی می‌سازیم که پشتوانه واقعی دارد؛ پول‌ها دقیقاً کجا جمع می‌شود، کارمزدها از چه مسیری کسر می‌شود و چطور می‌توانیم مانده‌ها را ثابت کنیم؟»

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

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

سوءبرداشت رایج: کیف پول، رجیستری مالکیت و دفتر دارایی یکی نیستند

برای اینکه طراحی شفاف شود، بهتر است سه لایه را از هم جدا کنیم:

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

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

دفتر دارایی دقیقاً چه کاری می‌کند؟ (به زبان ساده)

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

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

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

نقشه حداقلی پولِ ورود/خروج (گام‌ها و رویدادها)

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

1. ثبت درخواست واریز

   • رویداد: DEPOSIT_INITIATED
   • ثبت هویت پرداخت‌کننده، مبلغ مورد انتظار و یک شناسه ارجاع.

2. دریافت واریز و ثبت قطعی

   • رویداد: DEPOSIT_POSTED
   • اتصال به شماره پیگیری بانکی یا شناسه پرداخت.
   • افزایش «مانده نقدی قابل استفاده» در دفتر دارایی.

3. انجام معامله یا صدور واحد در رجیستری مالکیت

   • رویداد در رجیستری: انتقال یا صدور.
   • رویداد در دفتر دارایی: TRADE_EXECUTED یا ISSUANCE_CONFIRMED با ارجاع به شناسه رجیستری.

4. محاسبه و ثبت کارمزد/هزینه

   • رویداد: FEE_ACCRUED (اگر هزینه ابتدا انباشته می‌شود) یا FEE_CHARGED (اگر همان لحظه کسر می‌شود).
   • ثبت مبنای محاسبه و روش اعمال.

5. تسویه دوره‌ای

   • رویداد: SETTLEMENT_RUN
   • تبدیل اقلام انباشته به پرداخت نهایی به گیرندگان مشخص، با قواعد روشن.

6. برداشت: ثبت درخواست تا پرداخت

   • رویدادها: WITHDRAWAL_INITIATED، WITHDRAWAL_APPROVED، WITHDRAWAL_PAID
   • اتصال به مرجع بانکی و کاهش مانده نقدی.

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

الگوهای کسر هزینه و کارمزد (دوره‌ای و تراکنشی)

هزینه‌ها معمولاً همان جایی هستند که «بدهی پنهان» ساخته می‌شود. دو الگو بخش بزرگی از نیازها را پوشش می‌دهد.

۱) کارمزدهای تراکنشی

کارمزد هم‌زمان با معامله یا تبدیل کسر می‌شود.

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

۲) هزینه‌های دوره‌ای یا هزینه نگه‌داری

هزینه‌ها با گذر زمان ایجاد می‌شود؛ مثل نگه‌داری، انبارداری، بیمه یا مدیریت.

• مناسب وقتی هزینه به زمان و «موقعیت» وابسته است.
• در دفتر دارایی: در طول دوره FEE_ACCRUED ثبت می‌شود و پایان دوره با SETTLEMENT_RUN بسته می‌شود.

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

گزارش‌گری: چه مانده‌ها و صورت‌حساب‌هایی باید قابل استعلام باشد

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

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

این همان چیزی است که به تیم عملیات، مالی و حسابرسی کمک می‌کند: گردش حساب بانکی ↔ رویدادهای دفتر دارایی ↔ رویدادهای رجیستری مالکیت.

راهکار یا چارچوب عملی

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

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

یک مثال ساده

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

• روز اول: واریز انجام می‌شود. دفتر دارایی DEPOSIT_POSTED را ثبت می‌کند و مانده نقدی قابل استفاده افزایش می‌یابد.
• روز دوم: خرید واحد انجام می‌شود. رجیستری مالکیت انتقال واحد را ثبت می‌کند و دفتر دارایی رویداد TRADE_EXECUTED را با ارجاع به همان ثبت نگه می‌دارد.
• در طول ماه: اقلام کوچک FEE_ACCRUED برای هزینه‌های دوره‌ای ثبت می‌شود.
• پایان ماه: با SETTLEMENT_RUN دوره بسته می‌شود و هزینه‌های انباشته از مانده نقدی کسر می‌شود یا اگر مانده کافی نباشد، طبق قاعده محصول «پرداختنی» ثبت می‌شود.
• هر برداشت بعدی: با WITHDRAWAL_PAID ثبت می‌شود و شماره پیگیری بانکی به رویداد وصل است.

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

ریسک‌ها و محدودیت‌ها

دفتر دارایی شفافیت و تطبیق را بهتر می‌کند، اما به‌تنهایی تضمین نمی‌کند که:

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

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

جمع‌بندی

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

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

پرسش‌های متداول

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

۲) چرا رجیستری مالکیت را از دفتر دارایی جدا می‌کنیم؟
چون هرکدام سؤال متفاوتی را جواب می‌دهد. رجیستری می‌گوید «مالک واحدها چه کسی است» و دفتر دارایی می‌گوید «پول و هزینه‌ها دقیقاً چه اتفاقی برایشان افتاد».

۳) اگر کارمزد را همان لحظه کسر کنیم، باز هم تسویه دوره‌ای لازم است؟
گاهی نه، اما بسیاری از هزینه‌های دنیای واقعی زمان‌محور است. تسویه دوره‌ای کمک می‌کند این هزینه‌ها زمان‌بندی، قابل پیگیری و قابل تطبیق شود.