Розробка системи batch-аукціонів (CoW-стиль)

Розроблення системи пакетних аукціонів (CoW-стиль)

CoW Protocol вирішив завдання, яке AMM не розв'язує: коли користувач A хоче продати ETH за USDC, а користувач B хоче продати USDC за ETH — навіщо йти в пул і платити LP комісії, якщо можна поєднати ордери напрямо? Coincidence of Wants (CoW) — це прямий розрахунок без AMM переходу. Пакетний аукціон — механізм, який агрегує ордери протягом періоду часу та знаходить оптимальне виконання. Реалізація такої системи складніша за AMM, але механіка захищає користувачів від фронт-раннінгу та MEV sandwich атак.

Як працює пакетний аукціон: механіка всередину

Період пакету та уніфікована clearing price

Кожні N секунд (у CoW Protocol — ~30 секунд) пакет закривається. Всі ордери, подані протягом цього періоду, виконуються за уніфікованою clearing price — одна ціна для всіх ордерів в пакеті.

Це принципово відрізняється від постійної торгівлі: неможливо фронт-ранити конкретний ордер, якщо всі ордери виконуються одночасно за однією ціною. MEV sandwich неможливий — немає перед/після конкретної транзакції, є один момент розрахунку.

Уніфікована clearing price визначається як ціна, яка максимізує торговельний об'єм: максимальна кількість ордерів на продаж та покупку, які можна поєднати за заданою ціною.

Архітектура Solver

Знаходження оптимальної clearing price та маршрутизації — це NP-складне завдання при великій кількості ордерів. CoW Protocol вирішує це через відкриту конкуренцію solverів: будь-хто може запустити solver, який пропонує рішення для поточного пакету. Найкраще рішення (максимальний surplus для користувачів) перемагає.

Для власної системи пакетних аукціонів ви можете:

1. Спрощений on-chain solver — реалізувати базовий алгоритм прямо в контракті. Працює для невеликих пакетів (< 50 ордерів), обмежено газом.
2. Off-chain solver + on-chain розрахунок — solver розраховує off-chain, подає рішення до контракту. Контракт перевіряє коректність (ордери виконані за цінами не гіршими за лімітні) та виконує трансферти. Це підхід CoW.
3. Гібридний з AMM fallback — CoW matching для перетинаючих ордерів, остача маршрутизується в Uniswap/Curve.

Структура ордера та підпис

Off-chain limit ордер у стилі CoW: користувач підписує структуру (EIP-712), не платить газ за сам ордер. Settlement контракт виконує пакет ордерів за один платіж газу від solver.

struct Order {
    address sellToken;
    address buyToken;
    address receiver;
    uint256 sellAmount;
    uint256 buyAmount;     // мінімальна сума покупки (ліміт)
    uint32  validTo;       // дедлайн
    bytes32 appData;       // метаданні
    uint256 feeAmount;     // компенсація газу solver
    bytes32 kind;          // SELL або BUY ордер
    bool    partiallyFillable;
    bytes32 sellTokenBalance; // erc20 / internal / external
    bytes32 buyTokenBalance;
}

Підпис через EIP-712 + EIP-1271 (для контрактних гаманців). Settlement контракт перевіряє підпис через isValidSignature під час виконання пакету.

Захоплення лишку: як користувачі перемагають

Якщо clearing price краща, ніж користувач указав у своєму лімітному ордері — лишок (surplus) повертається користувачеві. Приклад: користувач хоче продати 1 ETH за мінімум 3000 USDC. Clearing price — 3050 USDC. Користувач отримує 3050, не 3000. 50 USDC surplus.

У CoW Protocol частина лишку йде solver як стимул. Це створює правильні стимули: solver максимізує surplus користувачів, отримує частку.

Реалізація settlement контракту

On-chain верифікація рішення

Контракт отримує від solver масив виконань ордерів та список трансферів. Верифікація:

1. Для кожного ордера: executedSellAmount * buyPrice >= order.buyAmount (користувач отримав не менше ліміту)
2. Закон збереження: sum(sellAmounts) >= sum(buyAmounts) в базовому токені (баланс збережений)
3. Всі підписи ордерів дійсні
4. validTo не минув

Якщо верифікація пройшла — розрахунок: трансферти всіх токенів через GPv2SafeERC20.transfer (спеціальна безпечна обгортка від CoW).

Flash accounting

CoW Protocol використовує flash accounting для розрахунку: замість послідовних трансферів з проміжним зберіганням, всі баланси розраховуються як net flow. Settlement контракту потрібно знати лише остаточні суми трансфертів, а не проміжні стани. Це зменшує газ у 2-3 рази порівняно з наївною реалізацією.

Реалізація: внутрішня книга в mapping(address token => mapping(address account => int256 balance)). Позитивне = повинні виплатити, негативне = повинні отримати. Після всіх обчислень net — остаточні ERC-20 трансферти лише для ненульових балансів.

Стек розроблення

Solidity 0.8.x для settlement контракту + OpenZeppelin для верифікації підписів (ECDSA, EIP-1271). TypeScript для логіки solver — npm пакет @cowprotocol/cow-sdk як еталон. Foundry для тестування з fuzz на коректність розрахунків surplus.

Для off-chain зберігання orderbook: PostgreSQL + REST API. WebSocket для real-time оновлень очікуючих ордерів.

Процес роботи

Проектування (3-5 днів). Структура ордера, архітектура solver (on-chain vs off-chain), модель комісій.

Settlement контракт (2-3 тижні). Верифікація ордерів, flash accounting, інтеграція AMM fallback.

Off-chain компоненти (1-2 тижні). Orderbook API, базовий алгоритм solver, реле підписів.

Тестування (1 тиждень). Fuzz тести на виходи solver, інтеграційні тести з Uniswap v3 fallback.

Орієнтири по строкам

Спрощений пакетний аукціон з on-chain solver (невеликий об'єм): 2-3 тижні. Повна система з off-chain конкуренцією solver та AMM fallback: 4-6 тижнів.