Інтеграція з 1inch API

Інтеграція з 1inch API

Написати самостійний routing по DEX — це тижні роботи: потрібно агрегувати ліквідність Uniswap v2/v3, Curve, Balancer, SushiSwap, знаходити оптимальний шлях через graph algorithm, враховувати gas cost кожного hop. 1inch вирішує це через Aggregation Protocol, який сплітує swap між кількома джерелами ліквідності. Інтеграція займає дні, а не тижні — якщо зробити правильно.

Де інтеграція зазвичай ломається

Застарілий quote та slippage при виконанні

GET /v6.0/1/quote повертає toAmount — очікувану кількість токенів на виході. Між моментом отримання quote та виконанням транзакції проходить час. На волатильному ринку за 10-30 секунд ціна може сдвинутися на 0.5-2%.

Якщо передавати в POST /v6.0/1/swap параметр slippage=1 (1%), при реальному русі ринку на 1.5% транзакція зареверсується — користувач заплатив газ і ничого не отримав. Правильно: динамічно встановлювати slippage на основі волатильності пари, 0.5% для stable-пар, 1-3% для волатильних.

Ще одна проблема: toAmount з /quote не збігається з toAmount з /swap. Це нормально — /swap будує фінальний calldata з урахуванням поточного стану пулів. Показувати користувачу цифру з /quote, а підписувати транзакцію з /swap — правильна практика.

Approve та permit: два патерни

1inch Aggregation Router v6 приймає токени через стандартний ERC-20.approve. Але для кращого UX підтримується також permit (EIP-2612) — gasless approve через підпис. Якщо токен реалізує EIP-2612 (DAI, USDC на Ethereum, більшість сучасних ERC-20), потрібно використовувати /approve/transaction endpoint тільки як fallback.

Перевірка підтримки permit: викликати token.nonces(address) — якщо не reverting, permit підтримується.

Другий тип approve — 1inch Permit2 (аналог Uniswap Permit2). Якщо користувач уже дав approve в Permit2 для іншого протоколу, повторний approve не потрібен. Це поліпшує UX при частих свопах.

Як ми інтегруємо 1inch

Структура запитів

Базовий флоу для swap віджета:

1. GET /v6.0/{chainId}/tokens — кешуємо список підтримуваних токенів (раз у годину достатньо)
2. GET /v6.0/{chainId}/quote?src=...&dst=...&amount=... — отримуємо quote, показуємо користувачу
3. GET /v6.0/{chainId}/approve/allowance?tokenAddress=...&walletAddress=... — перевіряємо поточний allowance
4. Якщо allowance < amount: GET /v6.0/{chainId}/approve/transaction → підписуємо approve
5. POST /v6.0/{chainId}/swap → отримуємо calldata, відправляємо транзакцію

Для мультичейн підтримки використовуємо chainId у URL. 1inch підтримує Ethereum (1), Polygon (137), Arbitrum (42161), Optimism (10), BSC (56), Avalanche (43114), Base (8453).

Обробка помилок API

1inch v6 повертає HTTP 400 з JSON body при будь-якій помилці бізнес-логіки. Типові коди:

• "Cannot estimate" — недостатньо ліквідності для запрошеної суми
• "Insufficient liquidity" — те ж саме, явно
• "fromTokenAddress cannot be equal to toTokenAddress" — UI баг
• Код 429 — rate limit. Free tier: 1 RPS, Growth: 10 RPS, Enterprise: без обмежень

Rate limiting потрібно обробляти через exponential backoff, не відправляти запити повторно негайно.

Fusion mode vs Classic

1inch Fusion (v5+) — orderbook-based execution через resolvers. Користувач підписує order off-chain (gasless), resolver виконує транзакцію та платить газ. Користувач платить через slippage. Це кращий UX, але потребує інтеграції через @1inch/fusion-sdk, не REST API.

Для простої інтеграції (swap віджет, агрегатор у dApp) — Classic mode через REST API. Для продвинутого UX з gasless транзакціями — Fusion.

Перевірка calldata

Перед відправкою транзакції користувачем — завжди симулювати через eth_call. Це дозволяє поймати revert до трат газу. У wagmi/viem:

const { data } = await publicClient.call({
  account: userAddress,
  to: swapData.tx.to,
  data: swapData.tx.data,
  value: BigInt(swapData.tx.value),
});

Якщо call reverting — показуємо користувачу помилку, не транзакцію.

Стек інтеграції

viem + wagmi для TypeScript/React додатків — нативна підтримка TypeScript, tree-shaking, хороша інтеграція з WalletConnect та MetaMask. Альтернатива — ethers.js v6 для Node.js бекенду.

Для кешування quote даних — React Query з staleTime: 10_000 (10 секунд). Більш старий quote не показуємо, запрошуємо заново.

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

Аналіз вимог (0.5 дня). Які чейни, які токени, Classic або Fusion, потрібен власний UI чи embed віджет.

Розроблення (2-3 дні). API шар з типізацією, React хуки для quote/swap flow, обробка allowance, error handling.

Тестування (0.5-1 день). Тесты на testnet (1inch підтримує Sepolia). Перевірка edge cases: нема ліквідності, insufficient balance, expired quote.

Орієнтири за часом

Базова інтеграція swap функціональності у існуючий dApp: 2-3 дні. Повноцінний swap віджет з мультичейн підтримкою, історією транзакцій та Fusion mode: 1-1.5 тижня.