Модель Smart Cycle от Atlas System предоставляет участникам структурированную основу для лучшего понимания механики платформы и участия.
Atlas System построена вокруг прозрачных Smart Cycles, а не скрытой внешней истории доходов. Это делает её экономику более лёгкой для проверки, но также делает неизбежным центральный вопрос: что происходит, когда создаётся меньше новых или повторных циклов, в то время как соответствующие требования продолжают поступать?
Платформы, основанные на участии, обычно выглядят наиболее сильными во время расширения. Новые пользователи приходят, существующие пользователи открывают дополнительные циклы, ликвидность растёт, и успешные требования укрепляют доверие. Более показательный период начинается, когда активность замедляется.
Белая книга Atlas System описывает каждый Smart Cycle как продукт с жизненным циклом: подготовка, запуск, рост, стабилизация, замедление, завершение и переход. Во время замедления активность может снижаться, требования могут в большей степени зависеть от доступной ликвидности, и риски позднего участия возрастают. Smart Cycle 1 не представлен как бесконечно действующий продукт.
Atlas также не описывает отдельный внешний бизнес, который надёжно финансирует рассчитанную дельту. В её материалах говорится, что помощь и дополнительная дельта формируются внутри системы через активность участников и доступную ликвидность. Таким образом, устойчивость системы зависит меньше от импульса запуска, чем от того, как она ведёт себя, когда притоки и спрос на требования перестают двигаться в одном направлении.
Требования зависят от общей ликвидности
Smart Cycle v1 использует два основных пользовательских контракта. Lockup Flow записывает срочные ордера и позволяет соответствующему пользователю запросить внесённую сумму плюс рассчитанное вознаграждение после наступления срока. Daily Flow позволяет пользователям запрашивать рассчитанные ежедневные вознаграждения в течение 200-дневного графика.
Оба взаимодействуют с общей позицией ликвидности PancakeSwap V3 через PositionHandler. Документация проекта на GitHub говорит, что депозиты добавляются в эту позицию, а требования удаляют соответствующую ликвидность.
Это делает требования видимыми, но не безусловными. Требование может быть действительным по правилам времени, но при этом зависеть от наличия ликвидности и возможности её вывода в соответствии с техническими условиями контракта.
Cyberscope выделил это в критическом замечании под названием «Модель вознаграждения по принципу "первый пришёл"». Аудитор сказал, что вознаграждения выплачиваются из общей внесённой ликвидности, а не из изолированных резервов вознаграждений, что создаёт риск того, что более ранние заявители потребляют ликвидность, необходимую более поздним участникам. Он рекомендовал разделить основной капитал участников и финансирование вознаграждений и ввести явный учёт резервов.
Формальной очереди нет
Заманчиво описать это как очередь, но опубликованные контракты, по-видимому, не создают формального списка ожидания по принципу «первый пришёл — первый обслужен» для неоплаченных требований. Соответствующие пользователи сами инициируют свои транзакции требований. Судя по опубликованному коду, исполнение зависит от того, какая действительная транзакция достигнет контракта и будет успешной при наличии достаточной ликвидности и необходимых условий. Время входа не обязательно устанавливает приоритет выплаты.
Таким образом, «ончейн-ордер» означает записанную позицию пользователя, а не гарантированное место в очереди на выплату. BscScan может показать, что требование было отправлено, подтверждено или отклонено. Он не может гарантировать, что более позднее требование получит тот же результат, что и более раннее.
Повторные циклы могут поддерживать ликвидность, но также создают будущие требования
Замедление роста не означает, что в систему не поступают новые средства. Существующие участники могут создавать повторные Smart Cycles, в то время как более поздние версии могут привлекать новую активность. В белой книге описывается, что продолжение создания циклов и поведение участников являются факторами, которые могут сохранить активную фазу. Будущие версии Smart Cycle рассматриваются как отдельные этапы протокола, а не как автоматическое продолжение предыдущего цикла.
Повторное участие может добавить ликвидность в ближайшей перспективе. Но само по себе оно не решает основную проблему. Каждый новый цикл также создаёт будущие условия для требований. Повторные циклы могут поддерживать движение, пока участие остаётся активным, но они не являются внешним источником дохода или гарантированным резервом.
Atlas обсуждает возможный будущий резервный фонд, финансируемый за счет комиссий экосистемы или доли расчетной дельты от последующих циклов. В техническом документе говорится, что такой механизм, если он будет введен, может оказаться недостаточным и не гарантирует компенсацию за более ранний цикл.
Прозрачность не то же самое, что способность
Atlas может сделать видимыми адреса контрактов, переводы, исходный код и транзакции претензий. Это отличается от закрытой платформы, где пользователи видят только внутренний баланс. Однако прозрачность в блокчейне отвечает на более узкий вопрос: что произошло? Она может показать, сколько USDT поступило в контракт, какой кошелек вызвал функцию и была ли транзакция успешной. Она не показывает, что у системы будет достаточно доступной ликвидности для выполнения всех будущих претензий.
В этом разница между прозрачностью и способностью. Протокол может выполнять свой код точно так, как написано, в то время как экономические условия, необходимые для желаемого результата, ухудшаются. Полезные публичные индикаторы во время замедления должны включать доступную ликвидность, объем и профиль погашения непогашенных циклов, успешные и отклоненные претензии, предстоящую концентрацию претензий и изменения параметров, контролируемых владельцем. Интерфейс также должен различать расчетную сумму и сумму, гарантированную к выплате.
Настоящее испытание наступает после импульса
Документы Atlas описывают Smart Cycles как циклические, а не вечные. Но одно лишь раскрытие информации не устанавливает устойчивость. Решающее испытание наступит, когда создание новых и повторных циклов замедлится, накопятся погашенные претензии, и участники смогут наблюдать результаты в реальном времени. BscScan облегчит оценку системы, но не предоставит ликвидность, необходимую для выполнения претензий.
Смарт-контракты могут сделать правила видимыми и последовательно их соблюдать. Они не могут устранить экономическую зависимость между активностью участников, общей ликвидностью и исходящими запросами. Для Atlas System фаза замедления покажет, помогает ли прозрачность пользователям понять эту зависимость до того, как она станет кризисом.
Для получения дополнительной информации посетите официальный сайт, репозиторий GitHub, X, Facebook, TikTok и Telegram.
