Как работают keepers в DeFi простыми словами: кто исполняет действия протокола и где нужен automation layer

Когда DeFi-протокол выглядит аккуратно в интерфейсе, у новичка легко появляется ложное ощущение, что всё внутри происходит «само».

Цена обновляется. Позиция ликвидируется. Vault ребалансируется. Награды собираются. Очередь вывода двигается. Будто контракт сам просыпается и делает нужный следующий шаг.

Но смарт-контракт сам по себе ничего не инициирует. Он не запускает действия по расписанию и не принимает решение в вакууме. Ему всегда нужен кто-то, кто придёт извне и вызовет нужную функцию.

Именно здесь появляются keepers.

Если говорить совсем простыми словами, keeper — это внешний исполнитель, который следит за условиями в протоколе и в нужный момент запускает допустимое действие onchain.

Это не обязательно один бот и не обязательно отдельная сеть. Keeper-модель может выглядеть по-разному:

  • публичные арбитражёры и ликвидаторы;
  • внутренние боты команды;
  • сеть независимых исполнителей;
  • automation-сервис поверх протокола;
  • policy-driven execution layer, где часть действий автоматическая, а часть идёт через подтверждение.

Для бизнеса и продуктовых команд тема keepers важна не только на уровне механики протокола. Вокруг них быстро возникают очень прикладные вопросы:

  • кто именно исполняет критичные действия;
  • что будет, если никто не пришёл вовремя;
  • как не допустить ошибочный или слишком агрессивный вызов;
  • как сочетать скорость, лимиты риска и audit trail;
  • какой automation layer строить поверх keeper-механики, если у вас есть treasury, клиентские средства или собственные стратегии.

Ниже — разбор без лишнего маркетинга: что такое keepers, где они используются, почему протоколы без них часто ломаются в операционке и как безопасно строить automation вокруг execution-событий.

Что такое keeper простыми словами

Keeper — это внешний участник, который:

  1. наблюдает за состоянием протокола;
  2. понимает, что наступило условие для конкретного действия;
  3. отправляет транзакцию для исполнения этого действия;
  4. получает экономический стимул, комиссию или иной результат за корректное выполнение.

Бытовая аналогия — не «автопилот», а дежурный исполнитель с чётким чек-листом.

Контракт хранит правила, но keeper приносит событие в исполнение.

Например:

  • если позиция стала unsafe, кто-то должен вызвать liquidation;
  • если vault ушёл из целевого диапазона, кто-то должен вызвать rebalance;
  • если накопились награды, кто-то должен вызвать harvest;
  • если пора закрыть эпоху, обновить коэффициент или подтвердить settlement, кто-то должен запустить этот переход состояния.

С инженерной точки зрения keeper — это мост между условием и фактическим onchain execution.

Почему смарт-контракт не может сделать это сам

Это один из самых полезных базовых принципов для понимания DeFi.

Смарт-контракт не является постоянно работающим процессом. Он исполняется только тогда, когда кто-то присылает транзакцию.

То есть у протокола нет своего внутреннего cron, который ночью проснётся и проверит:

  • не пора ли ликвидировать позицию;
  • не пора ли обновить oracle-dependent state;
  • не пора ли собрать комиссии;
  • не пора ли выполнить maintenance-переход.

Без внешнего исполнителя состояние может оставаться корректным по правилам, но неприменённым на практике.

Отсюда и появляется keeper-экономика: протоколу нужно мотивировать кого-то приходить вовремя.

Где keepers встречаются чаще всего

Keeper-механика существует во многих местах, даже если продукт об этом почти не говорит.

1. Liquidations

Самый понятный пример.

Если collateral у позиции падает ниже безопасного порога, кто-то должен инициировать ликвидацию. Иначе плохой долг будет продолжать висеть в системе.

Поэтому ликвидации почти всегда завязаны на внешних исполнителей:

  • они следят за health factor;
  • сравнивают данные цены и пороги;
  • решают, окупится ли транзакция;
  • отправляют liquidation call.

2. Vaults и rebalancers

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

Если rebalance не пришёл вовремя:

  • стратегия уходит из целевого диапазона;
  • доходность падает;
  • риск растёт;
  • пользователи получают не тот результат, который ожидали.

3. Harvest и compounding

Во многих протоколах награды нужно не просто «начислить в уме», а реально собрать отдельной транзакцией, иногда ещё и конвертировать, а затем реинвестировать.

Если это делать слишком редко, деньги лежат неэффективно. Если слишком часто — gas и market impact съедают смысл.

Значит, кто-то должен выбрать правильный момент исполнения.

4. Settlement, epoch rollover, accounting updates

Некоторые протоколы живут не в непрерывной модели, а в эпохах, батчах или отдельных расчётных циклах.

В конце периода требуется:

  • зафиксировать состояние;
  • обновить коэффициенты;
  • закрыть batch;
  • применить итоговый расчёт;
  • открыть следующий период.

Это тоже keeper-задача.

5. Cross-protocol automation

Чем сложнее DeFi-стек, тем чаще действие в одном месте должно запускаться из-за условий в другом.

Например:

  • на lending-позиции ухудшился health factor;
  • treasury на DEX держит свободный collateral;
  • policy layer разрешает top-up только до заданного лимита;
  • keeper-сервис инициирует пополнение или частичное закрытие позиции.

Здесь keeper уже не просто исполняет одну функцию. Он становится частью orchestration-слоя между несколькими системами.

Из чего обычно состоит keeper-система

Если убрать бренды и детали реализации, почти любая зрелая keeper-архитектура состоит из четырёх частей.

Signal layer

Собирает входные данные:

  • onchain-события;
  • цены;
  • состояние позиций;
  • лимиты;
  • gas conditions;
  • доступность ликвидности;
  • состояние кошельков и bridge-маршрутов.

Decision layer

Решает, стоит ли действовать прямо сейчас.

То есть система проверяет не только можно ли вызвать функцию, но и нужно ли это делать именно сейчас.

Например:

  • ликвидация уже экономически оправдана;
  • harvest выгоден только при накоплении достаточной суммы;
  • rebalance нужен, но рынок слишком тонкий и лучше подождать;
  • settlement должен пройти до конца эпохи независимо от gas.

Policy layer

Здесь живут ограничения и guardrails:

  • максимальный размер действия;
  • допустимые маршруты;
  • список разрешённых контрактов;
  • pause/freeze режимы;
  • лимиты на дневной объём;
  • требования к ручному подтверждению.

Именно этот слой превращает «бота» в контролируемую automation-систему.

Execution layer

Отвечает за саму отправку транзакции:

  • формирует вызов;
  • проверяет nonce и идемпотентность;
  • учитывает retry-логику;
  • пишет status и audit trail;
  • эскалирует инцидент, если действие не прошло.

На практике ценность часто не в самом вызове функции, а в том, что execution слой делает его наблюдаемым, повторяемым и ограниченным политиками.

Где начинается реальная операционная боль

В маленьком протоколе или на раннем этапе всё часто выглядит терпимо:

  • один бот следит за парой условий;
  • команда иногда вручную запускает maintenance-функции;
  • сообщения об ошибках летят в Telegram;
  • если что-то не случилось вовремя, все просто чинят это руками.

Но при росте почти всегда всплывают одни и те же проблемы.

Никто не знает, кто отвечает за конкретное действие

Есть контракт, есть скрипт, есть VPS, есть какой-то кошелёк. Но если execution сорвался, непонятно:

  • это bug;
  • gas spike;
  • сломанный RPC;
  • неверный trigger;
  • policy block;
  • нехватка средств на gas;
  • гонка с другим исполнителем.

Система умеет исполнять, но не умеет различать приоритеты

Например, у команды одновременно возникли:

  • liquidation risk;
  • необходимость ребалансировки LP;
  • harvest наград;
  • bridge refill для горячего кошелька.

Если у automation нет очереди приоритетов и лимитов, она может оптимизировать второстепенное действие раньше критичного.

У команды есть алерты, но нет контролируемого ответа

Очень частая проблема: мониторинг существует, а безопасный action pipeline — нет.

В результате оператор видит сообщение вроде “позиция близка к ликвидации”, но дальше начинается ручная импровизация:

  • откуда брать collateral;
  • кто имеет право перевода;
  • какой размер допустим;
  • не конфликтует ли это действие с другими лимитами.

Именно здесь automation layer становится не роскошью, а нормальной операционной необходимостью.

Практический блок: какая проблема возникает у бизнеса

Для бизнеса и продуктовой команды keeper-механика редко выглядит как «нам нужен бот». Обычно проблема звучит намного приземлённее:

  1. у нас есть DeFi-операции, которые нельзя исполнять вручную 24/7;
  2. любое опоздание создаёт финансовый риск, деградацию стратегии или плохой клиентский опыт;
  3. полностью бесконтрольная автоматизация тоже опасна;
  4. нужен слой, который сочетает скорость исполнения, policy guardrails и понятную наблюдаемость.

Это особенно заметно в сценариях:

  • treasury management;
  • клиентские yield- или lending-продукты;
  • automated hedging;
  • cross-chain liquidity operations;
  • поддержка позиций на нескольких venue одновременно.

Какой архитектурный паттерн обычно имеет смысл

Хорошо работает модель risk-aware keeper control plane.

В ней протоколы и кошельки не связываются напрямую с хаотичным набором скриптов. Вместо этого появляется сервисный слой с понятной структурой.

1. Наблюдение и нормализация сигналов

Сервис собирает данные из onchain и offchain-источников, приводит их к общему виду и сохраняет историю решений.

2. Каталог действий

Каждый тип keeper-действия описан как отдельный workflow:

  • liquidation;
  • top-up;
  • rebalance;
  • harvest;
  • settlement;
  • emergency pause или strategy stop.

3. Policy engine

Для каждого workflow задаются правила:

  • когда действие разрешено;
  • какой максимальный объём допустим;
  • нужен ли human approval;
  • какие кошельки и сети разрешены;
  • какие pre-checks обязательны.

4. Исполнение с audit trail

Система запускает действие, пишет reason, входные параметры, tx hash, результат и все ретраи.

5. Escalation path

Если автоматическое действие не прошло или упёрлось в policy block, задача не исчезает. Она эскалируется оператору с уже подготовленным контекстом.

Это важная разница между взрослой automation-системой и «ботом на VPS».

Что можно давать как сервис или implementation layer

Если смотреть прикладно, вокруг keeper-механики можно строить вполне конкретный сервисный слой без лобовой рекламы.

Например:

  • dashboard по execution health и pending actions;
  • policy-driven liquidation monitoring;
  • managed rebalance workflows для vault- и LP-стратегий;
  • treasury top-up orchestration;
  • multi-wallet action router;
  • alerting + safe execution approvals;
  • unified audit log по всем keeper-событиям.

То есть продавать ценность стоит не как “мы тоже умеем запускать бота”, а как:

  • снижение ручного операционного риска;
  • сокращение времени реакции;
  • единый control plane для критичных onchain-действий;
  • прозрачность для ops, risk и compliance-процессов.

Где главный риск в keeper-автоматизации

Главная ошибка — думать, что если действие полезно в среднем, его безопасно делать автоматически всегда.

Например:

  • harvest можно вызвать слишком рано и потерять экономику;
  • rebalance можно сделать в плохой ликвидности;
  • collateral top-up можно провести из кошелька, где ликвидность была нужна для другого сценария;
  • liquidation helper может сработать на неверном ценовом сигнале;
  • retry-логика может случайно дублировать нежелательное действие.

Поэтому хороший keeper-слой начинается не с вопроса “что автоматизировать”, а с вопроса “какие решения допустимы, при каких условиях и как это будет проверяться”.

Это, кстати, хорошо перекликается с тем, что в последних обсуждениях на Hacker News регулярно всплывает и в более широком мире automation: ценность даёт не просто агент, который может что-то сделать, а control plane с политиками, лимитами, наблюдаемостью и понятной эскалацией. Для DeFi это ещё важнее, потому что ошибка здесь быстро превращается в прямой финансовый ущерб.

Главное, что стоит запомнить

Keeper в DeFi — это не «магический бот», а исполнительный слой, который приводит правила протокола в действие.

Если упростить до сути:

  • контракт хранит допустимую логику;
  • signal layer понимает, что произошло;
  • keeper или execution service инициирует нужное действие;
  • policy layer не даёт автоматизации выйти за границы;
  • бизнес получает не просто скорость, а управляемость.

Именно поэтому по мере взросления DeFi-продуктов ключевым активом становится не только стратегия и не только доступ к ликвидности, а ещё и надёжный automation layer вокруг execution-событий.

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