В DeFi многие до сих пор мыслят слишком просто: есть пользователь, есть swap-кнопка, есть DEX, есть цена. Но в реальности между нажатием кнопки и финальным исполнением давно живёт отдельный рынок — рынок order flow и execution quality. Именно здесь и возникает большая часть разговоров про MEV, private mempool, searchers, builders, intents, order flow auctions и execution protection.
Если убрать шум и мемы про «злых арбитражников», MEV-инфраструктура — это просто ответ на очень практичный вопрос:
кто именно получает value, которое возникает между намерением пользователя совершить сделку и моментом, когда эта сделка попадает в блок?
Для технической аудитории это полезная тема сразу по нескольким причинам:
- становится понятнее, почему одинаковый swap может исполняться по-разному;
- видно, как деньги реально двигаются между пользователем, LP, searcher, builder и block producer;
- появляется ясный продуктовый угол для MVP: execution gateway, order flow router, simulation API, slippage/MEV dashboard, private routing layer, policy engine для treasury или vault;
- становится очевидно, что automation поверх DeFi — это не только ребалансировки и алерты, но и контроль качества исполнения.
Из общих инженерных сигналов вокруг Hacker News сейчас снова хорошо видно одно: ценность всё чаще появляется не в «ещё одном интерфейсе», а в инфраструктурном слое, который лучше оркестрирует сложную систему под нагрузкой и с adversarial economics. Для DeFi это вообще базовая правда. Execution здесь почти никогда не нейтрально.
Что именно разбираем
Сегодняшний фокус такой:
- что такое MEV-инфраструктура без лишней демонизации;
- как работают public mempool, private order flow, searchers, builders и order flow auctions;
- где именно рождается extra value, fee flow и risk transfer;
- какие практические use case есть у кошельков, агрегаторов, vault’ов и treasury-команд;
- где главные риски и trade-offs;
- как собрать похожий MVP / prototype / automation layer вокруг execution quality.
Важно: это не статья в стиле «как заработать на фронтране». Наоборот, полезнее смотреть на MEV как на часть рыночной микроструктуры, которую надо понимать, измерять и контролировать.
Как это работает простыми словами
Самая полезная ментальная модель здесь такая:
- пользователь хочет свапнуть, ребалансировать, ликвидировать позицию или провести cross-protocol action;
- до включения транзакции в блок есть короткое окно, где другие участники рынка видят order flow или получают право его увидеть;
- если из этого order flow можно извлечь value, начинается конкуренция за право исполнить его выгоднее других.
Где рождается этот value
Value обычно возникает из одного или нескольких факторов:
- арбитраж между venue после крупного swap;
- liquidation opportunity в lending-протоколе;
- возможность сандвича вокруг большой market-сделки;
- backrun после крупного свопа;
- внутренняя неттинговая экономия у market maker’а;
- лучший routing, чем тот, который выбрал сам пользователь;
- cross-domain dislocation между chain, rollup или bridge liquidity.
То есть MEV — это не один конкретный тип атаки. Это более широкий класс извлекаемой ценности из порядка, контекста и времени исполнения.
Кто участвует в этой системе
Чтобы не превращать тему в абстракцию, полезно разложить роли.
1. User / wallet / frontend
Это источник order flow.
Пользователь подписывает транзакцию или intent. Иногда order flow сразу идёт в публичный mempool, иногда — в private relay, wallet-integrated solver network или order flow auction.
2. Searchers
Searcher — это участник, который ищет прибыльные execution opportunities.
Он мониторит:
- pending transactions;
- onchain state;
- DEX prices;
- liquidation thresholds;
- bridge arrivals;
- funding, oracle updates и другие state changes.
Его задача — быстро понять: можно ли на этом order flow заработать, и какой bundle для этого нужен.
3. Builders
Builder собирает блок-кандидат или пакет транзакций, оптимизируя его по value.
Если совсем просто:
- searcher предлагает builder’у bundle;
- builder сравнивает разные bundle и обычные транзакции;
- builder собирает наиболее ценный набор для следующего блока;
- block producer / proposer выбирает лучший блок-кандидат.
4. Relays / private routing providers
Эти игроки передают order flow или block proposals дальше по цепочке.
Они особенно важны, когда речь идёт о private order flow:
- пользователь не хочет светить транзакцию в public mempool;
- wallet или aggregator шлёт её в приватный канал;
- searchers и builders получают доступ к order flow на ограниченных условиях;
- пользователь потенциально снижает риск сандвича или получает rebate от аукциона.
5. LP, market makers и protocol operators
Они не всегда сидят в центре дискуссии про MEV, но именно на них часто ложится экономический эффект:
- LP могут терять value на adverse selection;
- market maker может выигрывать от internalization order flow;
- протокол может вводить fee/rebate-механику;
- vault или treasury-команда может недополучать execution quality, если маршрут устроен плохо.
Почему public mempool — не просто очередь транзакций
Публичный mempool часто интуитивно воспринимают как нейтральный буфер: отправил транзакцию, ждёшь включения в блок. На практике это скорее рыночная доска объявлений о том, что пользователь собирается сделать.
Если на этой информации можно заработать, другие участники реагируют до включения сделки.
Отсюда и возникают знакомые проблемы:
- большой swap двигает цену ещё до завершения исполнения;
- searcher вставляет bundle до и после пользовательской сделки;
- liquidation race съедает большую часть возможного edge;
- кошелёк показывает одну цену, а в блоке пользователь получает другую;
- aggregator выбирает route с плохой post-trade quality, хотя pre-trade quote выглядел прилично.
Именно поэтому private order flow стал не экзотикой, а нормальным продуктовым паттерном.
Что такое private order flow простыми словами
Private order flow — это модель, где order flow сначала отправляется не в общедоступный mempool, а в ограниченный execution channel.
Упрощённая схема:
- пользователь подписывает сделку;
- кошелёк или API отправляет её приватному маршрутизатору;
- router / relay / auction layer решает, кому показать этот order flow;
- searchers или market makers конкурируют за право исполнить его;
- сделка попадает в блок уже через приватный путь.
Зачем это нужно
Основные причины такие:
- снизить вероятность sandwich-атак;
- получить лучший execution на крупном swap;
- монетизировать order flow через аукцион и rebate;
- контролировать, какие исполнители получают доступ к потоку;
- улучшить outcome для vault, treasury или managed strategy.
По сути это уже не просто transaction submission, а execution marketplace.
Как деньги реально двигаются в MEV-инфраструктуре
Вот где начинается самое интересное.
Сценарий 1. Большой swap без защиты
- Пользователь хочет свапнуть крупную сумму.
- Транзакция попадает в public mempool.
- Searcher видит, что swap двинет цену в пуле.
- Он строит bundle, где его buy идёт до сделки пользователя, а sell — после неё.
- Пользователь получает хуже execution.
- Searcher забирает часть value себе.
- Builder и proposer получают часть дохода через bundle bidding.
Value flow здесь такой:
- пользователь платит скрытую цену через ухудшение execution;
- searcher получает прибыль;
- builder/proposer получают revenue за включение выгодного bundle.
Сценарий 2. Тот же swap через private order flow
- Пользователь отправляет order flow в private router.
- Router проводит auction или RFQ между исполнителями.
- Market maker или solver даёт лучшую котировку.
- Сделка исполняется приватно или через защищённый маршрут.
- Пользователь получает лучший net outcome.
- Router может забрать fee или разделить rebate.
Value flow уже другой:
- пользователь теряет меньше на adverse execution;
- часть value уходит не в случайный sandwich, а в контролируемый execution market;
- router/wallet может монетизировать order flow осознанно, а не отдавать его рынку бесплатно.
Сценарий 3. Liquidation / rebalance automation
- Vault или risk engine видит, что health factor падает.
- Automation публикует действие на погашение/ребаланс.
- Если маршрут идёт через публичный mempool, часть value может утечь в виде плохого исполнения или race condition.
- Если маршрут идёт через private execution layer, команда получает больше контроля над outcome.
Для treasury и vault-инфраструктуры это уже прямой operational edge.
Где возникает fee flow и risk transfer
MEV-инфраструктура не создаёт yield в смысле lending APY, но она перераспределяет execution value.
Fee flow
Деньги в таких системах могут приходить из:
- router fee;
- order flow auction fee;
- spread market maker’а;
- builder/searcher payments;
- execution rebate wallet’у или пользователю;
- subscription fee за premium routing / analytics / policy controls.
Risk transfer
Это ещё важнее, чем комиссии.
- пользователь отдаёт часть execution complexity кошельку, router’у или solver’у;
- market maker берёт на себя inventory risk;
- builder принимает inclusion/ordering risk;
- protocol operator или aggregator начинает отвечать за качество маршрута;
- vault / treasury-команда переносит риск ручного исполнения в automation + policy layer.
Именно поэтому тема execution quality всё чаще становится продуктовой, а не только «ресёрчевой».
Реальные сценарии применения
1. Защищённые swaps в кошельке
Самый очевидный use case — кошелёк, который умеет:
- слать сделки в private path;
- сравнивать public и private quotes;
- показывать вероятность sandwich/slippage;
- выбирать защищённый execution по умолчанию.
Это особенно полезно для крупных пользователей и illiquid pairs.
2. Treasury execution для команд и DAO
Если treasury регулярно:
- переводит резервные активы;
- заходит в vault;
- делает крупные ребалансы;
- закрывает risk-heavy позиции,
то execution quality начинает влиять на PnL почти так же сильно, как nominal fee.
Даже улучшение исполнения на десятки basis points на крупных объёмах — это уже вполне материальная операционная экономика.
3. Vault / managed account control plane
Если у вас есть General Vault, yield router или managed strategy, то полезно контролировать не только куда капитал аллоцирован, но и как он физически двигается между leg’ами.
Примеры:
- вход в стратегию через private execution, а не через лобовой public swap;
- unwind крупных позиций через auction/RFQ;
- protected rebalances при низкой ликвидности;
- liquidation-defense workflows, где важен быстрый и аккуратный execution.
4. MEV-aware analytics и dashboards
Отдельный сильный продукт — это аналитика качества исполнения:
- quoted vs achieved price;
- public vs private route comparison;
- estimated sandwich exposure;
- searcher/builder concentration;
- value leakage на крупных actions;
- fail rate и latency по execution providers.
Для технической аудитории и B2B-продуктов это очень понятная ценность.
Основные компоненты архитектуры
Если строить такой продукт как MVP, я бы разложил его на несколько скучных, но полезных компонентов.
1. Order intake API
Слой, который принимает:
- swap requests;
- rebalance actions;
- treasury execution intents;
- liquidation-defense actions.
Он должен уметь:
- валидировать параметры;
- проставлять correlation id;
- назначать execution policy;
- логировать lifecycle.
2. Simulation / quoting engine
Это мозг системы.
Минимально он должен:
- получить quote из публичного роутера;
- получить quote из private/RFQ provider;
- оценить gas и expected output;
- посчитать допустимый slippage;
- симулировать post-trade state;
- выдать route recommendation.
3. Policy engine
Очень важная часть, особенно для B2B и treasury.
Примеры правил:
- сделки выше определённого объёма всегда идут через private path;
- illiquid pairs запрещены без ручного approval;
- rebalances во время высокой volatility требуют tighten slippage;
- liquidation-defense имеет приоритет над обычными rebalance jobs;
- некоторые venue запрещены из-за fail rate или degraded quality.
4. Execution router
Этот слой решает, куда отправлять order flow:
- public mempool;
- private relay;
- RFQ market maker;
- solver / intent router;
- гибридный аукцион между несколькими путями.
5. Settlement / transaction tracking
Нужен ingestion layer, который отслеживает:
- submit time;
- inclusion time;
- revert / fail status;
- achieved output;
- block metadata;
- route used;
- deviation from expected execution.
6. Observability и analytics
Без этого MEV-aware продукт быстро превращается в маркетинговую коробку без доказательств.
Нужны:
- Postgres для execution history;
- Redis для short-lived locks, queues и ephemeral quotes;
- indexer / RPC workers для chain data;
- Grafana / Metabase / Superset для dashboards;
- alerting в Telegram/Slack/PagerDuty на degradation событий.
Риски и trade-offs
Здесь довольно много неприятной правды.
1. Private order flow не равен автоматической честности
То, что сделка ушла в private route, ещё не значит, что пользователь получил best execution.
Риски:
- router может internalize flow в свою пользу;
- auction может быть формально открытым, но фактически концентрированным;
- fee breakdown может быть непрозрачным;
- пользователь может просто поменять один вид leakage на другой.
2. Централизация execution layer
Если весь order flow идёт через один gateway, появляется новый chokepoint:
- censorship risk;
- outage risk;
- pricing power;
- конфликты интересов между router, maker и пользователем.
3. Сложность измерения «качества исполнения»
Это вообще одна из самых недооценённых проблем.
Недостаточно сказать «private route лучше public route». Нужно уметь измерять:
- benchmark quote в момент отправки;
- фактический outcome после всех fee;
- latency;
- fail probability;
- dispersion по venue и notional;
- hidden spread.
Без этого продукт неуправляем.
4. Regulatory и disclosure risk
Если wallet, broker-like интерфейс или treasury service монетизирует order flow, рано или поздно возникает вопрос прозрачности:
- получает ли пользователь rebate;
- кто зарабатывает на execution;
- как выбираются исполнители;
- насколько маршрут нейтрален.
Даже если продукт чисто технический, такие вопросы лучше предусмотреть заранее.
5. Ошибки automation могут стоить дороже ручного execution
Если policy engine настроен плохо, можно:
- загнать крупный order в слишком узкий private route;
- пропустить better venue;
- ужесточить slippage так, что срочный rebalance вообще не исполнится;
- выбрать execution path, который формально «безопасен», но operationally слишком медленный.
То есть automation должна быть не просто агрессивной, а context-aware.
Как сделать похожий MVP
Вот самый практичный угол для builder’а.
MVP-цель
Не строить «новую MEV-инфраструктуру для всего рынка», а собрать execution quality control plane для узкого use case.
Хороший MVP может звучать так:
Сервис, который принимает крупные swap/rebalance requests для treasury или managed vault и автоматически выбирает public, private или RFQ route на основе симуляции, policy и historical execution quality.
Компоненты MVP
1. Backend
Практичный стек:
- Go или TypeScript/NestJS для API и routing logic;
- PostgreSQL для хранения requests, quotes, fills, route decisions и audit trail;
- Redis для quote cache, distributed locks и очередей;
- воркеры для RPC polling, simulation и transaction tracking.
2. Quote adapters
Подключить минимум три источника:
- публичный DEX aggregator quote;
- private relay / protected RPC / wallet-routing provider;
- один RFQ / solver endpoint.
Уже на этом уровне можно делать meaningful route comparison.
3. Execution simulator
Нужен модуль, который считает:
- expected output;
- gas-adjusted output;
- slippage under stressed liquidity;
- вероятность fail на основе route history;
- heuristic MEV exposure score.
Это не идеальный predictor, но уже очень полезный операторский инструмент.
4. Policy layer
Примеры полей policy:
- max notional per route;
- min liquidity score;
- require_private_above_usd;
- preferred providers;
- manual_approval_threshold;
- deadline_tightness_by_action_type.
5. Dashboard
Нужно показывать не только status, но и economics:
- выбранный route;
- quoted vs achieved outcome;
- estimated leakage avoided;
- route latency;
- provider fail rate;
- historical performance by pair / notional / chain.
6. Optional settlement helper
Если продукт работает не как аналитика, а как action layer, можно добавить:
- подпись и отправку транзакции через service account / AA wallet;
- execution queue;
- retry logic;
- escalation в ручной approval.
Что можно автоматизировать поверх
Вот где тема становится особенно интересной для инфраструктурного продукта.
1. Monitoring execution degradation
Нужны алерты на:
- рост slippage относительно baseline;
- увеличение fail rate у private provider;
- подозрительное расхождение quoted vs achieved output;
- route concentration в одном provider;
- всплеск MEV exposure score по отдельным парам.
2. Dynamic route policy
Automation может сама менять политику:
- включать mandatory private routing для отдельных активов;
- временно отключать provider с плохим quality score;
- ослаблять или ужесточать slippage для срочных действий;
- переводить большие ордера в RFQ-only режим.
3. Treasury and vault rebalances
Вместо тупого cron-job «сделать swap в 12:00» система может:
- проверить liquidity conditions;
- сравнить execution paths;
- разбить order на батчи;
- отправить его через private path;
- остановиться, если achieved price вышел за лимит.
Это и есть нормальный automation layer, а не просто кнопка с таймером.
4. Keeper logic для defensive actions
Для lending / leverage / vault-систем automation может:
- при падении health factor запускать защищённый unwinding route;
- использовать private path для collateral swap;
- эскалировать к человеку, если execution risk слишком высокий;
- логировать причину, почему action был исполнен или заблокирован.
5. Anomaly detection
Даже без «AI-магии» можно ловить полезные отклонения:
- провайдер внезапно перестал давать конкурентные quotes;
- одна сеть показывает unusually bad inclusion latency;
- large trades системно недополучают outcome;
- по определённым токенам public route стабильно хуже private route на X bps.
Это уже достаточно, чтобы продукт выглядел как серьёзный control plane.
Где здесь реальная продуктовая ценность
Главная ошибка — думать, что MEV-инфраструктура интересна только searcher’ам и исследователям микроструктуры. На практике она всё чаще полезна именно тем, кто строит обычные прикладные вещи:
- кошельки;
- treasury tooling;
- vault control planes;
- strategy execution bots;
- analytics dashboards;
- managed DeFi products.
Потому что для них вопрос не в том, «существует ли MEV», а в том, сколько value они каждый день теряют на плохом execution.
Итог
MEV-инфраструктура — это не тёмная магия и не отдельный маргинальный рынок рядом с DeFi. Это часть базовой execution-механики: кто увидел order flow, кто получил право его исполнить, кто забрал возникшую value и сколько издержек осталось у пользователя.
Если объяснять совсем коротко:
- public mempool делает order flow видимым и конкурентным;
- private order flow пытается превратить хаотичный leakage в управляемый execution market;
- builders, searchers и relays — это инфраструктура распределения этой ценности;
- wallets, vaults и treasury-команды могут поверх этого строить нормальный product/control plane.
Для builder’а здесь хороший и очень практичный угол: не нужно делать новый протокол. Можно собрать MVP из intake API, quote adapters, simulation engine, policy layer, execution router, monitoring и dashboard — и получить систему, которая реально уменьшает leakage, улучшает outcome и даёт команде осознанный контроль над тем, как деньги двигаются по цепочке.