Недавно я пересмотрел логику стейкинга и эмиссии Dusk и обнаружил, что настоящая проблема заключается не в нарративной упаковке, а в очень реальной экономической дилемме.

Концепция Dusk такова: общий объем поставки — 1 миллиард токенов, из которых первые 500 миллионов — начальная эмиссия, а оставшиеся 500 миллионов распределяются в течение длительного периода в качестве наград за стейкинг валидаторов. Это очень разумно на этапе запуска проекта — для поддержки сети валидаторов необходимо за счет новых эмиссий выпускать токены. Проблема возникает на поздних этапах. Если фактические транзакционные сборы в сети так и не вырастут, то доходность от стейкинга по сути превратится в «государственную субсидию», что в долгосрочной перспективе негативно скажется на цене токена и настроении держателей.

Рассмотрим конкретные параметры стейкинга: порог в 1000 DUSK, два эпохи (около 4320 блоков, примерно 12 часов при блокчейне с 10-секундным интервалом). Низкий порог и быстрая возможность входа и выхода действительно позволяют расширить базу валидаторов, но есть и обратные эффекты — если доходность полностью зависит от эмиссии, участники станут более краткосрочными, а безопасность и стабильность сети будут чрезмерно зависеть от устойчивости рыночных настроений. Это скрытая опасность.

Поэтому я сейчас считаю, что для оценки того, сможет ли Dusk перейти от временного ажиотажа к устойчивому развитию, важно следить за двумя ключевыми показателями: во-первых, сможет ли доля транзакционных сборов в сети, входящих в доходность стейкинга, постоянно расти; во-вторых, сможет ли взаимодействие с экосистемой и приложениями демонстрировать стабильный рост, а не просто всплеск активности и затем резкое падение.

Технический прогресс DuskEVM вряд ли сможет решить эту проблему. Если не появится реальных бизнес-сценариев, при которых можно постоянно генерировать сборы, вся структура стимулирования токенов рано или поздно застрянет в «субсидиях». Я не берусь утверждать, сможет ли проект выйти из этого состояния, но это действительно самый важный показатель, который стоит проверять с помощью данных на текущем этапе.