Автоплатежи в Web3: тест безопасности трех протоколов

В Web3 ровно тот же сценарий — регулярная оплата сервиса, зарплата внештатному разработчику, повторяющийся платеж за API — упирается в неудобный выбор: либо каждый раз подтверждать транзакцию вручную (то есть никакой автоматизации), либо один раз выдать смарт-контракту разрешение на списание токенов и надеяться, что этим разрешением не воспользуются сверх меры. Между этими полюсами работают специализированные протоколы автоплатежей — Sablier, Superfluid и Gelato. Я разобрала архитектуру каждого из них по одним и тем же критериям, чтобы понять, кому из них реально можно доверить регулярное списание денег — и где за аккуратным интерфейсом скрывается дыра в безопасности.

Сравнивать несколько решений по одним и тем же критериям — приём давно не новый и за пределами крипты: так, например, при тестировании трёх форматов обучения немецкому подход ровно тот же — три варианта, общий чек-лист, честный вывод. С автоплатежами в Web3 логика та же, только ставки выше: деньги уходят не с банковской карты, а напрямую с кошелька, и откатить платёж после подтверждения блокчейна уже нельзя.

Два способа отдавать деньги «по расписанию»: поток против триггера

У автоплатежей в Web3 нет единой модели. Одни протоколы превращают платеж в непрерывный поток токенов: деньги «текут» от отправителя к получателю каждую секунду, пока пользователь не закроет поток. Другие работают как оркестратор: держат контракт с логикой «вызови такую-то функцию тогда-то» и исполняют её по расписанию, по событию или на каждом блоке. Первая модель — это Sablier и Superfluid. Вторая — Gelato. От выбора модели зависит всё дальнейшее: как списывается газ, где лежит разрешение на токены и что именно злоумышленник может попытаться атаковать.

Если совсем коротко: Sablier и Superfluid отвечают на вопрос «кому и сколько сейчас причитается», а Gelato — на вопрос «когда и какое действие нужно выполнить». Это не конкуренты, а инструменты для разных задач, и путать их — первая ошибка, которую делают при выборе.

Sablier: эскроу с фиксированной раскладкой по времени

Sablier работает с 2019 года и построен вокруг простой идеи: при создании потока отправитель кладёт токены в эскроу-контракт, указывает адрес получателя и срок, за который вся сумма должна быть выплачена. После этого средства лежат в контракте, а получатель в любой момент может вывести ту часть, которая уже «накапала» по линейной формуле. Смарт-контракты протокола — немодифицируемые: у разработчиков нет ключа, которым можно подменить логику после деплоя. Версия v2.2 прошла аудит от Cyfrin CodeHawks, и именно в таком сочетании (иммутабельность плюс независимая проверка) и заключается главный защитный рубеж Sablier.

За около семи лет работы через протокол прошло более 781 тысячи транзакций на сумму свыше $1,5 млрд, число активных пользователей превысило 344 тысячи, а количество созданных потоков перевалило за 131 тысячу. Эти цифры важны не как маркетинг, а как индикатор «обкатанности» кода: чем дольше иммутабельный контракт находится в основных сетях без происшествий, тем меньше шансов на скрытую логическую ошибку. Сегодня Sablier работает в 24+ EVM-совместимых сетях, и везде используется одна и та же проверенная логика — одна из причин, почему проекты вестинга для инвесторов и DAO-грантов выбирают его чаще остальных.

Superfluid: непрерывный поток и экономия на газе

Superfluid предлагает модель «бессрочного» потока: токены передаются получателю каждую секунду в реальном времени, без заранее зафиксированной даты окончания. Главное архитектурное отличие — в газовой модели. При открытии, изменении или закрытии потока пользователь платит за транзакцию, но сам перевод токенов каждую секунду газа не требует: балансы отправителя и получателя пересчитываются по формуле, а не переписываются новой транзакцией. На практике это означает, что запустить поток на год — не дороже, чем запустить поток на час.

Для пользовательского опыта это радикальное упрощение: один раз подтверждаешь открытие потока и больше не возвращаешься к транзакции до момента, когда решишь закрыть платёж. Никаких ежемесячных подтверждений, никакого ручного «продли подписку». С точки зрения безопасности это тоже плюс: меньше точек входа — меньше поверхность атаки. Единственное, что нужно держать в голове, — поток не остановится сам по себе, его нужно закрывать осознанно, иначе деньги продолжат уходить. Для зарплатных сценариев, где сотрудник получает токены «по секундам», и для подписок на API-сервисы с поминутной тарификацией это естественная модель: она убирает из уравнения дату окончания и привязывает оплату к реальной продолжительности использования.

Gelato: автоматизация через триггеры, а не поток

Gelato решает совсем другую задачу. Это не протокол платежей как таковых, а платформа автоматизации: она умеет вызывать функции любого смарт-контракта по расписанию (интервал или cron-формат), по событию в блокчейне или на каждом новом блоке. Логика пишется на TypeScript, хранится в IPFS, а исполняет её децентрализованная сеть нод.

Для автоплатежей это значит вот что: можно один раз настроить функцию «раз в месяц вызывай transfer() у токена X в пользу адреса Y», и Gelato сам, без участия пользователя, будет инициировать такие транзакции. Подходит и для более сложных сценариев — например, регулярной покупки токенов по стратегии усреднения стоимости, ребалансировки портфеля по заданным долям, перевода процентов по депозиту в стейкинге. По сути Gelato превращает «ручной on-chain сценарий» в «запланированное задание», и в этом его главная сила — и одновременно главная зона ответственности, потому что слепо доверять автоматическому исполнителю чужих функций стоит только после тщательной проверки того, что именно он будет вызывать.

Ключевое отличие от потоковых протоколов: у Gelato нет собственного механизма хранения средств. Он не кладёт токены в эскроу и не пересчитывает балансы по формуле — он только инициирует вызовы, а логика перевода живёт в целевом контракте. Это значит, что вся ответственность за корректность суммы, адреса и частоты лежит на том коде, который Gelato вызывает, а не на самом Gelato.

Сравнение архитектур: три протокола в одной таблице

Эта таблица — не «кто лучше», а карта различий. Дальше смотрим, какие из этих различий реально влияют на безопасность пользовательских денег, а какие остаются на уровне удобства.

Безопасность на фоне цифр: почему автоплатежи — лакомая цель для атакующих

В 2025 году средний ущерб от одного инцидента взлома в Web3 превысил $5,3 млн. Это усреднённая цифра по рынку: в неё входят и мелкие скам-проекты, и крупные протоколы, но сам масштаб показывает, что деньги в ончейне по-прежнему привлекают внимание злоумышленников куда сильнее, чем в традиционном финтехе. Отдельно статистика говорит о том, что около 90% уязвимых смарт-контрактов, обнаруженных в результате инцидентов, не проходили независимый аудит безопасности до деплоя. Это не значит, что аудит гарантирует защиту — но обратная картина красноречива: код, который никто не проверял, живёт в основной сети с теми же ошибками, с которыми его написали, и пользователи узнают об уязвимостях уже по факту потери средств.

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

Где у протокола «руль управления»: иммутабельность и архитектура доступа

Архитектурное решение, которое сильнее всего влияет на безопасность автоплатежей, — это ответ на вопрос: «может ли разработчик изменить логику контракта после того, как в нём уже лежат пользовательские деньги?»

Sablier отвечает на этот вопрос радикально: контракты немодифицируемые, у команды нет админ-ключа, которым можно подменить правила игры. Это одновременно и плюс (нет «единой точки компрометации» в лице разработчика), и минус (если в логике обнаружится баг, исправить его «на горячую» не получится — придётся мигрировать на новую версию, и пользователям нужно будет вручную перевести средства в новый контракт). Для пользователя это означает: пока протокол работает без инцидентов, ваши деньги в безопасности просто потому, что контракт невозможно «переписать изнутри».

Здесь важно понимать и обратную сторону: прохождение аудита не означает гарантию отсутствия уязвимостей. Аудит — это независимая проверка на конкретный момент времени, она снижает вероятность известных классов ошибок, но не закрывает все возможные сценарии атак, которые могут проявиться позже, в связке с другими контрактами или новыми стандартами токенов. Поэтому честный разговор о безопасности протокола автоплатежей всегда состоит из двух частей: «аудит был проведён» и «архитектура не предполагает вмешательства извне». Только в таком сочетании появляется настоящая защита, потому что аудит без иммутабельности оставляет лазейку для разработчика, а иммутабельность без аудита закрепляет в коде все ошибки, которые в нём уже есть.

Одобрение токенов: невидимый риск, который остаётся в любом протоколе

Какой бы изящной ни была архитектура Sablier, Superfluid или Gelato, на старте пользователь всё равно делает одну и ту же вещь: выдаёт смарт-контракту разрешение (ERC-20 approval) на списание своих токенов. Без этого шага ни один из протоколов не сможет перевести ни копейки — это фундаментальное требование стандарта токенов, и обойти его нельзя, можно только по-разному его ограничивать.

В Sablier разрешение выдаётся адресу протокольного эскроу-контракта (Lockup-контракта) на конкретную сумму, и после закрытия потока неиспользованный остаток allowance можно отозвать. В Superfluid approval также выдаётся протокольному контракту, но работает оно строго в рамках конкретной сети и конкретного токена: разрешение, данное в Polygon, не переносится в Arbitrum, и для каждого нового токена нужно отдельное подтверждение. В Gelato approval выдаётся адресу контракта-spender — обычно это обёртка или целевой контракт, который Gelato вызывает от имени пользователя, — и при правильной настройке ограничивается конкретной суммой или адресом получателя. Во всех трёх случаях пользователь остаётся «держателем ключей» — отозвать разрешение можно в любой момент.

Главная практическая рекомендация, которую редко проговаривают вслух: после того как автоплатеж стал не нужен, отзывайте approval. В большинстве современных кошельков это делается в пару кликов через специальный revoker, и именно этот простой шаг закрывает самый частый вектор атаки — «старый, забытый, безлимитный approval, который лежит в контракте годами». Ни один аудит протокола не защитит от того, что пользователь однажды выдал разрешение и забыл о нём: если протокол или обёртка, которой выдан allowance, будет скомпрометирована, злоумышленник получит доступ к средствам в пределах выданного разрешения — и отзыва approval уже не будет.

Что выбрать под конкретную задачу

Если задача — зарплата сотрудникам в реальном времени или подписка без фиксированной даты окончания, Superfluid с его газосберегающей моделью «потока по секундам» подходит лучше остальных: один раз открыл — деньги идут, в любой момент закрыл, комиссий за сам процесс передачи нет.

Если задача — классический вестинг для инвесторов, эскроу с заранее оговорённой суммой и сроком или разовая выплата по графику, Sablier остаётся самым проверенным вариантом: иммутабельные контракты, аудит от Cyfrin CodeHawks на версии v2.2, около семи лет эксплуатации и свыше $1,5 млрд прошедшего через протокол объёма — это редкое сочетание в Web3.

Если задача — не просто переводить токены, а регулярно запускать on-chain действия (покупка по стратегии, ребалансировка портфеля, вызов кастомной логики в произвольном контракте), Gelato закрывает этот сценарий: триггеры по расписанию, событиям или блокам, логика на TypeScript в IPFS, поддержка крупных EVM-сетей.

Все три протокола закрывают разные ниши и не конкурируют «в лоб» — это скорее три инструмента в одной мастерской. Общий знаменатель у них один: на старте пользователь один раз выдаёт разрешение на токены — и дальше либо деньги текут потоком, либо сеть-исполнитель сама дёргает нужные функции. После использования автоплатежа — отзовите approval через revoker, и тогда риск сводится к архитектурным особенностям самого протокола. А с ними, как видно из таблицы выше, у каждого инструмента свой характер, своя модель газа и своё понимание того, где именно лежит «руль управления» деньгами.