بروزرسانی: ۱۲ مهر, ۱۴۰۵ - 11 دقیقه زمان مطالعه

از تهاتر تا توکنایزینگ

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

آیا تهاتر توکن‌شده می‌تواند لایه‌ای تازه در تأمین مالی زنجیره‌ی ساخت باشد؟

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

نمونه‌های مختلفی از این روش را می‌توان در پروژه‌های سازندگان مطرح یافت. بر اساس ارزیابی‌های میدانی، این سازندگان بین ۲0 تا ۳۵ درصد از واحدهای پروژه‌های خود را به‌عنوان پرداخت خدمات ساخت به پیمانکاران واگذار می‌نمایند. با این حال، تهاتر سنتی یک محدودیت ساختاری جدی دارد: اندازه‌ی دارایی قابل واگذاری اغلب با اندازه‌ی طلب تأمین‌کننده تطابق ندارد.

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

۱. ریشه‌ی مسئله: عدم تطابق اندازه

فرض کنید تأمین‌کننده‌ای ۸۰۰ میلیون تومان از سازنده طلب دارد و تنها دارایی قابل تهاتر، یک واحد مسکونی به ارزش ۲۰ میلیارد تومان است. این طلب ۴ درصد ارزش واحد را تشکیل می‌دهد. واگذاری کامل واحد یا حتی دانگی منطقی نیست و واگذاری «چند متر از واحد» نیز صرفاً یک مسئله‌ی محاسباتی نیست؛ بلکه مجموعه‌ای از مشکلات حقوقی، ثبتی و اجرایی ایجاد می‌کند.

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

۲.  تهاتر توکن‌شده (Tokenized Barter) چیست؟

تهاتر توکن‌شده را می‌توان این‌گونه تعریف کرد:

تبدیل ارزش اقتصادی یک تعهد تهاتری به واحدهای دیجیتال قابل ثبت، مدیریت و قابل انتقال (در صورت وجود زیرساخت حقوقی و بازار مناسب).

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

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

این تفاوت، مدل حاضر را از پروژه‌هایی که صرفاً یک توکن ایجاد می‌کنند جدا می‌کند.

نکته‌ی مهم درباره‌ی جایگاه این مدل: تهاتر توکن‌شده در نقطه‌ی شروع، یک نوآوری در تسویه (Settlement) است، نه مستقیماً یک ابزار تأمین مالی. اگر تأمین‌کننده کالا را تحویل داده و به جای پول، یک حق اقتصادی دریافت کند، در وهله‌ی اول روش تسویه تغییر کرده است. اما اگر تأمین‌کننده بتواند آن حق را پیش از سررسید به سرمایه‌گذار بفروشد، سرمایه وارد زنجیره می‌شود و مدل به تأمین مالی زنجیره‌ی تأمین (Supply Chain Finance) نزدیک می‌شود. این تمایز در سراسر مقاله حفظ می‌شود.

۳. معماری پیشنهادی: پنج لایه به‌جای یک توکن ساده

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

لایه‌ی ۱: ثبت و امانت‌داری (Registry / Escrow)

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

نکته‌ی اصطلاحی: Registry و Escrow الزاماً یک چیز نیستند. Registry دفتر ثبت و کنترل حقوق و تعهدات است؛ Escrow یک سازوکار نگهداری یا کنترل دارایی/وجوه است. در این معماری، Registry نقش اصلی را در جلوگیری از دوباره‌تعهدی ایفا می‌کند و Escrow- در صورت وجود- یک لایه‌ی تکمیلی برای کنترل دارایی یا وجوه است.

جریان داده: اطلاعات هویتی طرفین، اسناد مالکیت، قراردادهای تهاتری و سوابق واگذاری در این لایه ثبت و به‌صورت رمزنگاری‌شده نگهداری می‌شود. هر واحد دیجیتال دارای شناسه‌ی یکتا (Token ID) است که به رکورد متناظر در Registry متصل می‌شود. این اتصال، منبع حقیقت (Source of Truth) برای جلوگیری از دوباره‌تعهدی است.

لایه‌ی ۲: ارزش‌گذاری (Valuation)

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

جریان داده: خروجی این لایه، یک «ارزش مبنا» (Base Value) است که به‌صورت دوره‌ای به‌روزرسانی می‌شود. این ارزش مبنا مبنای محاسبه‌ی تعداد واحدهای دیجیتال قابل تخصیص به هر تأمین‌کننده قرار می‌گیرد.

لایه‌ی ۳: تهاتر (Barter Engine)

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

جریان داده: این لایه از یک سو به Registry متصل است (برای ثبت تعهد) و از سوی دیگر به Valuation (برای دریافت ارزش مبنا). خروجی آن، یک «حق تهاتری تأییدشده» است که آماده‌ی توکنایزینگ می‌شود.

لایه‌ی ۴: توکنایزینگ (Tokenization)

حق اقتصادی تأییدشده به تعداد مشخصی واحد دیجیتال تبدیل می‌شود.

جریان داده: این لایه تعداد واحدهای دیجیتال را بر اساس فرمول «ارزش حق ÷ ارزش مبنا» محاسبه و آن‌ها را به کیف پول تأمین‌کننده تخصیص می‌دهد. هر واحد دارای متادیتای مشخص (تاریخ صدور، ارزش مبنا، پروژه، شرایط تسویه) است.

لایه‌ی ۵: نقدشوندگی و تسویه (Liquidity / Settlement)

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

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

در این معماری، توکن تنها یکی از اجزای سیستم است؛ نه کل سیستم.

۴. قیمت‌گذاری: مسئله‌ای مهم‌تر از تعداد توکن

فرض کنیم ارزش مبنای یک پروژه ۵۰۰ میلیارد تومان باشد و ۱۰۰ هزار واحد دیجیتال برای آن تعریف شود. ارزش مبنای اولیه‌ی هر واحد برابر است با ۵ میلیون تومان.

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

چارچوب مفهومی شاخص‌گذاری قراردادی

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

  • Property Index: تغییرات میانگین قیمت منطقه‌ای بر اساس داده‌های رسمی یا پلتفرم‌های معتبر
  • Material Index: تغییرات قیمت سبد مصالح اصلی (فولاد، سیمان، بتن و…)
  • Risk/Progress Factors: عواملی که ریسک تکمیل و پیشرفت پروژه را منعکس می‌کنند؛ این عوامل ماهیت متفاوتی از شاخص‌های قیمتی دارند و پیشرفت بیشتر پروژه لزوماً به معنای افزایش ارزش حق نیست.
  • تابع f، وزن‌ها و نحوه‌ی محاسبه: باید پیش از پایلوت توسط ارزش‌گذار و مشاور مالی مستقل تعیین و در قرارداد تثبیت شود.

نحوه‌ی به‌روزرسانی: تعداد واحدهای دیجیتال ثابت می‌ماند، اما ارزش مرجع هر واحد بر اساس فرمول قراردادی در هر دوره به‌روزرسانی می‌شود. در سررسید، تسویه بر اساس ارزش روز انجام می‌شود. در کل مقاله از «ارزش اسمی» استفاده نمی‌شود؛ زیرا می‌تواند بار حقوقی و مالی نادرستی ایجاد کند. به‌جای آن، «ارزش مرجع» یا در موارد لازم «ارزش تسویه» به کار می‌رود.

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

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

۵. تفکیک قیمت نقدی از قیمت تهاتری

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

  • قیمت مرجع نقدی: قیمتی که در معامله‌ی نقدی همان کالا یا خدمت پرداخت می‌شد.
  • ارزش توافق‌شده تهاتری: ارزشی که طرفین برای معامله‌ی تهاتری توافق می‌کنند.
  • پریمیوم یا تخفیف تهاتر: اختلاف میان دو مورد بالا.

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

۶. تعارض منافع: چه کسی ارزش را تعیین می‌کند؟

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

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

۷. ریسک‌هایی که توکنایزینگ حذف نمی‌کند

توکنایز کردن تهاتر به‌خودی‌خود ریسک پروژه را از بین نمی‌برد. مهم‌ترین ریسک‌ها عبارت‌اند از:

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

۸. اگر سازنده نکول کند؟

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

پاسخ به ساختار حقوقی بستگی دارد. اگر توکن صرفاً نماینده‌ی یک طلب قراردادی باشد، ممکن است دارنده در رتبه‌ی طلبکاران عادی قرار گیرد. اگر حق او به سازوکارهای حقوقی مشخصی مانند وثیقه‌ی معتبر، حساب امانی با شرایط روشن، یا ساختار حقوقی جداگانه برای پروژه (SPV) متصل شود، ممکن است حقوق و نحوه‌ی وصول او متفاوت باشد. با این حال، ایجاد هر نوع اولویت نسبت به سایر طلبکاران نیازمند مبنای حقوقی معتبر و قابل اجراست و صرفِ وجود Escrow به‌تنهایی اولویت طلب ایجاد نمی‌کند.

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

۹. تأمین‌کننده در نهایت چه چیزی دریافت می‌کند؟

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

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

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

۱۰. چرا تأمین‌کننده باید این مدل را بپذیرد؟

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

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

دو مزیت بالقوه

اول، تطابق دقیق‌تر پرداخت با اندازه‌ی طلب. تأمین‌کننده‌ای که 2 میلیارد تومان تومان طلب دارد، مجبور نیست در برابر آن دارایی چند ده میلیارد تومانی دریافت کند.

دوم، امکان نقد کردن بخشی از حق پیش از پایان پروژه. تأمین‌کننده می‌تواند بخشی از واحدهای دیجیتال را نگه دارد و بخشی را- در صورت وجود بازار مجاز و خریدار- برای تأمین نقدینگی واگذار کند.

اما این مزیت فقط با نقدشوندگی واقعی تحقق می‌یابد. اگر فروش واحدهای دیجیتال فقط با تخفیف قابل‌توجه ممکن باشد، آن تخفیف عملاً بخشی از هزینه‌ی تأمین مالی پروژه است. به‌عنوان یک مثال (نه یک نرخ واقعی)، اگر تأمین‌کننده طلب ۱ میلیاردی خود را در قالب توکن دریافت کند ولی برای نقد کردن آن مجبور شود آن را ۸۰۰ میلیون بفروشد، سیستم عملاً یک هزینه تأمین مالی ۲۰درصدی ایجاد کرده است؛ فقط این هزینه در قالب «تخفیف نقدشوندگی» ظاهر شده، نه نرخ بهره. بنابراین مدل باید در مقایسه با روش‌های جایگزین سنجیده شود، نه به‌صورت مستقل.

۱۱. آیا این مدل قبلاً در بازار اجرا شده است؟

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

تهاتر ساختمانی ← توکنایز کردن حق تهاتری ← انتقال یا بازار ثانویه

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

بر اساس گزارش Deloitte Center for Financial Services با عنوان Digital dividends: How tokenized real estate could revolutionize asset management (۲۰۲۵)، ارزش جهانی املاک توکنایزشده می‌تواند از کمتر از ۳۰۰ میلیارد دلار در ۲۰۲۴ به حدود ۴ تریلیون دلار در ۲۰۳۵ برسد. این بخش در مقایسه با برخی کاربردهای دیگر توکنایزینگ، همچنان حوزه‌ای نوظهور محسوب می‌شود و از این منظر برای مدل‌هایی مانند تهاتر توکن‌شده اهمیت دارد.

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

۱۲. چارچوب حقوقی: مهم‌ترین شرط توسعه

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

در دستورالعمل تأسیس، فعالیت، انحلال و نظارت بر کارگزاران رمزپول مصوب بانک مرکزی، «رمزدارایی» هر نماد رقومی ارزش یا حق مالی و غیرمالی تعریف شده که به‌صورت الکترونیکی، متمرکز یا غیرمتمرکز، قابل انتشار، عرضه، نگهداری و انتقال است. این دستورالعمل، رمزدارایی‌ها را بر اساس کاربرد به سه دسته‌ی «رمزپول»، «توکن اوراق بهادار» و «توکن کاربردی» تقسیم می‌کند.

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

آیین‌نامه اجرایی این بند که در سال ۱۴۰۴ تصویب شده نیز دامنه‌ی «اموال و دارایی‌ها» را به‌طور مشخص شامل طلب، حقوق مالی، عواید قابل تصرف از قراردادها یا اجرای پروژه‌ها و مطالبات قراردادی دانسته و برای پذیرش و استفاده از این دارایی‌ها سازوکارهایی در بازار سرمایه پیش‌بینی کرده است.

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

اگر ساختار به شکل «تأمین‌کننده ← توکن ← سرمایه‌گذار عمومی ← بازار ثانویه» طراحی شود، طبقه‌بندی حقوقی توکن، نحوه‌ی عرضه، حقوق دارنده و سازوکار معامله باید تخصصی بررسی شود و ممکن است الزامات بازار سرمایه یا مقررات رمزدارایی مطرح شود. به همین دلیل، مسیر منطقی برای آزمایش مدل، شروع از محیطی بسته و کنترل‌شده است و فقط در صورت تأیید حقوقی و اقتصادی، حرکت به مدل‌های گسترده‌تر.

ابعاد مالیاتی و حسابداری

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

آثار مالیاتی هر مرحله می‌تواند متفاوت باشد:

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

این موارد باید در طراحی پایلوت با مشورت متخصصان مالیاتی و حسابداری بررسی شوند.

۱۳. چرخه‌ی تأیید و توکنایزینگ

شرایط اجرا

  • پروژه و طرف‌ها از پیش مشخص باشند؛
  • Registry و Escrow از روز اول فعال باشند؛
  • واحدهای دیجیتال در محیطی کنترل‌شده نگهداری شوند و انتقال فقط میان طرف‌های تأییدشده انجام شود؛
  • ارزش مبنا را ارزش‌گذار مستقل تأیید کند و ارزش حق به‌صورت دوره‌ای به‌روزرسانی شود؛
  • بازار عمومی فقط پس از ارزیابی عملکرد اقتصادی و تأیید حقوقی بررسی شود.

معیارهای سنجش موفقیت

«قابل اندازه‌گیری» بودن پایلوت یعنی از ابتدا شاخص‌هایش مشخص باشد. برای مثال:

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

۱۴. تحلیل ذی‌نفعان: چه کسی چه چیزی از این مدل می‌گیرد؟

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

نتیجه‌گیری

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

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

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

مسیر تکامل مدل را می‌توان این‌گونه خلاصه کرد:

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

پرسش اصلی بنابراین این نیست که «آیا می‌توان یک ملک را توکنایز کرد؟» پرسش مهم‌تر این است:

آیا می‌توان ارزشی را که در زنجیره‌ی تأمین ساختمان ایجاد می‌شود، به یک حق اقتصادی استاندارد، قابل ثبت و در شرایط مناسب قابل تسویه تبدیل کرد؟

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