Gelato Network – набор инфраструктурных сервисов для приложений и собственных блокчейнов. Через Gelato разработчики отправляют gasless-транзакции, автоматизируют вызовы контрактов, получают случайность и оракульные данные, оплачивают услуги из общего баланса и запускают rollup либо Avalanche L1. Это уже не только децентрализованная сеть ботов, которой Gelato был на раннем этапе.
Название Network может создать неверное впечатление о едином протоколе. На практике у Gelato несколько продуктов с разными моделями доверия. Relay и Functions используют управляемую исполнительную инфраструктуру, а Rollup as a Service собирает целый технологический стек из выбранных компонентов.
Relay и gasless-транзакции
Relay принимает подписанный запрос и отправляет его в сеть от имени приложения. Разработчик может субсидировать gas, списывать оплату в поддерживаемом токене либо использовать ERC-4337 Paymaster и Bundler. Пользователю не обязательно заранее иметь нативную монету, но расход всё равно покрывается балансом проекта или выбранным способом расчёта.
Gasless SDK поддерживает smart wallets на основе ERC-4337 и EIP-7702. В первом случае UserOperation проходит через EntryPoint, во втором обычный адрес получает делегируемую контрактную логику. Эти механизмы дополняют account abstraction в Ethereum, но не защищают пользователя от вредоносного вызова, который он сам подписал.
Web3 Functions
Functions – серверные функции, которые вычисляют условие и данные для будущей on-chain транзакции. Триггером может быть время, событие или новый блок. Когда условие выполнено, исполнитель Gelato вызывает целевой контракт. Разработчик может писать логику на TypeScript или формировать её через Solidity-контракт.
Функция способна читать API, рассчитывать ребалансировку или проверять состояние нескольких контрактов. Это удобно для ликвидаций, регулярных выплат и обслуживания позиций, но вычисление вне блокчейна не становится доверительным только из-за последующей транзакции. Контракт назначения должен сам проверять критические ограничения.
От Automate к Functions
Ранние версии Gelato строились вокруг задач и сети Executors. Затем продукт назывался Ops и Automate. Текущий legacy-интерфейс прямо сообщает, что прежний Automate больше не доступен, и направляет пользователей в Gelato Functions. Старые статьи о самостоятельных Executors и пополнении treasury нельзя переносить на нынешний сервис без проверки.
Functions сохраняет идею автоматического исполнения, но предлагает более облачную модель с dashboard, управляемыми исполнителями, уведомлениями и серверной логикой. Это улучшает разработку, одновременно усиливая зависимость от оператора.
Жизненный цикл задачи
Приложение сначала создаёт задачу и указывает контракт назначения, триггер и способ оплаты. Сервис периодически проверяет условие, формирует calldata и симулирует вызов. После успешной проверки исполнитель отправляет транзакцию, а dashboard сохраняет состояние и историю попыток.
Отдельные модули задают режим: разовое исполнение, выделенный адрес отправителя, временной или событийный trigger. Они не заменяют авторизацию в целевом контракте. Контракт должен принимать вызов только от ожидаемого executor либо самостоятельно доказывать, что условие действительно выполнено.
1Balance, VRF и данные
1Balance объединяет оплату услуг Gelato: проект вносит USDC и расходует один баланс на транзакции в разных сетях. Такой учёт упрощает эксплуатацию, но депозит находится в системе расчётов Gelato и требует контроля лимитов и доступа к ключам.
VRF доставляет проверяемую случайность в контракт, что нужно играм, розыгрышам и распределению NFT. Дополнительные сервисы включают private RPC и потоки цен. Наличие нескольких поставщиков данных не отменяет риск задержки, неверной конфигурации и несоответствия частоты обновления задаче приложения.
Проверяемость VRF относится к происхождению случайного значения, а не к честности правил игры. Контракт обязан заранее зафиксировать, как результат превращается в победителя, и не позволять администратору повторять запрос до удобного исхода.
Rollup as a Service
Gelato разворачивает и обслуживает сети на OP Stack, Arbitrum Orbit и других поддерживаемых основах. Заказчик выбирает settlement, data availability, мост, explorer, oracle и дополнительные интеграции. Gelato управляет sequencer-инфраструктурой, RPC, мониторингом и обновлениями по выбранному соглашению.
Собственный rollup не получает безопасность Ethereum автоматически во всех аспектах. Риски зависят от контракта моста, механизма доказательств, ключей обновления, доступности данных и полномочий sequencer. Сравнение с Optimism корректно только после проверки конкретной конфигурации сети.
Токен GEL и управление
GEL был выпущен в 2021 году как токен управления и координации исполнителей. Максимальное первоначальное предложение составило 420,69 млн GEL. План включал токены сообщества, команды, ранних инвесторов и публичного распределения с разными графиками разблокировки.
Ранний проект предполагал staking и slashing исполнителей. Управление GEL действует через отдельный портал голосования и вестинга, однако текущие коммерческие продукты оплачиваются не обязательно в GEL: например, 1Balance использует USDC. Поэтому активность Relay или RaaS не означает прямого автоматического спроса на токен.
История
Gelato появился в 2019 году как протокол автоматизации Ethereum. V1 позволял пользователям создавать задачи, а исполнителям – отправлять транзакции за вознаграждение. В 2021 году вышли V2 и токен GEL. Позднее Gelato расширил Relay, Automate, Account Abstraction и Web3 Functions.
С 2023 года важным направлением стал Rollup as a Service. Проект начал обслуживать отдельные L2 и добавил интеграции мостов, explorers, data availability и оракулов. К 2025–2026 годам публичная документация позиционирует Gelato как облачную платформу для wallets и chains, а не только как DeFi-автоматизатор.
Команда
Gelato основали Луис Шлисске и Хильмар Шобер. Они развивали проект от Ethereum automation к инфраструктуре rollups и корпоративных сетей. Ключевые сервисы обслуживает компания Gelato, тогда как GEL и голосование относятся к отдельному уровню сообщества. Эти контуры управления не следует считать полностью взаимозаменяемыми.
Основные риски
Централизация сервиса. Отказ API, исполнителей, RPC или панели управления способен остановить автоматизацию даже при исправных целевых контрактах.
Внешние вычисления. Functions получает данные вне сети. Ошибка кода, секретов или API может инициировать нежелательную транзакцию.
Ключи и разрешения. Релееру нужны строго ограниченные полномочия. Слишком широкая роль превращает компрометацию ключа в угрозу средствам.
Rollup-конфигурация. Заказная сеть наследует риски моста и выбранного стека. Даже совместимость с Arbitrum не гарантирует одинаковую децентрализацию.
Расчётный баланс. Ошибка лимитов 1Balance или утечка API-ключа может привести к неожиданным расходам.
GEL. Токен сохраняет управление, но его роль в современной выручке платформы ограничена и может не соответствовать ожиданиям инвестора.
Gelato закрывает много задач эксплуатации Web3 из одного набора сервисов. Его следует оценивать как инфраструктурного провайдера с контрактными компонентами, а GEL – как отдельный актив, чья связь с использованием продуктов не является долей в бизнесе.
