Інтерфейс для пулів ліквідності Uniswap v2/v3

Зауважимо: коли клієнт прийшов із завданням зробити інтерфейс для пулів Uniswap v2, перше, з чим він зіткнувся — відсутність розрахунку частки та impermanent loss. Користувачі плутали пропорції при додаванні ліквідності, втрачали кошти через невраховане прослизання. Типова ситуація: користувач вводить 10 ETH у пул ETH/USDC, але інтерфейс не підказує потрібну кількість USDC — транзакція фейлиться з помилкою пропорції. Ми розробили рішення під ключ: інтерфейс, який автоматично розраховує пропорції, попереджає про непостійні втрати та безпечно керує approve токенів. Наш досвід у DeFi — понад 5 років, ми реалізували 15+ LP-інтерфейсів для різних AMM, від простих v2-клонів до складних v3 з концентричною ліквідністю.

Проблеми та болі

Головна проблема користувачів — нерозуміння механіки пулу. Вони вводять довільні суми, отримують неоптимальні пропорції та втрачають на impermanent loss. Друга — складність approve: потрібно схвалити два токени, часто в неправильному порядку, що призводить до помилок транзакцій. Третя — відсутність візуалізації частки та зароблених комісій. Наш інтерфейс вирішує все це: автоматичний розрахунок пропорцій при будь-якій зміні поля, послідовний approve обох токенів однією кнопкою, реальна частка користувача в пулі.

Моделі AMM

Два основні варіанти, які зустрічаються в проєктах:

Uniswap v2 / SushiSwap (constant product x·y=k): проста пропорція, LP-токени ERC-20, фіксована 0.3% комісія.

Uniswap v3 (concentrated liquidity): користувач вибирає ціновий діапазон, позиція — NFT, складніший розрахунок.

Розбираємо Uniswap v2 як основу — більшість custom AMM будується на цій моделі. Детальніше про протокол можна дізнатися в офіційній документації Uniswap v2.

Дані пулу та розрахунки

Читання стану пулу через мультикол: резерви, totalSupply, баланс користувача. На основі цих даних обчислюємо частку та пропорції.

// lib/pool.ts
import { createPublicClient, http, parseAbi } from 'viem';

const PAIR_ABI = parseAbi([
  'function getReserves() view returns (uint112 reserve0, uint112 reserve1, uint32 blockTimestampLast)',
  'function totalSupply() view returns (uint256)',
  'function balanceOf(address) view returns (uint256)',
  'function token0() view returns (address)',
  'function token1() view returns (address)',
  'function kLast() view returns (uint256)',
]);

const ROUTER_ABI = parseAbi([
  'function addLiquidity(address,address,uint256,uint256,uint256,uint256,address,uint256) returns (uint256,uint256,uint256)',
  'function removeLiquidity(address,address,uint256,uint256,uint256,address,uint256) returns (uint256,uint256)',
  'function quote(uint256 amountA, uint256 reserveA, uint256 reserveB) pure returns (uint256 amountB)',
]);

export interface PoolState {
  reserve0: bigint;
  reserve1: bigint;
  totalSupply: bigint;
  userLPBalance: bigint;
  token0: `0x${string}`;
  token1: `0x${string}`;
  // Обчислювані
  userShare: number;       // частка користувача в пулі, 0–1
  userToken0: bigint;      // скільки token0 можна вивести
  userToken1: bigint;
}

export async function getPoolState(
  pairAddress: `0x${string}`,
  userAddress?: `0x${string}`,
  client = createPublicClient({ chain: mainnet, transport: http() }),
): Promise<PoolState> {
  const results = await client.multicall({
    contracts: [
      { address: pairAddress, abi: PAIR_ABI, functionName: 'getReserves' },
      { address: pairAddress, abi: PAIR_ABI, functionName: 'totalSupply' },
      { address: pairAddress, abi: PAIR_ABI, functionName: 'token0' },
      { address: pairAddress, abi: PAIR_ABI, functionName: 'token1' },
      ...(userAddress ? [{ address: pairAddress, abi: PAIR_ABI, functionName: 'balanceOf', args: [userAddress] }] : []),
    ],
  });

  const [r0, r1] = results[0].result as [bigint, bigint, number];
  const totalSupply = results[1].result as bigint;
  const token0 = results[2].result as `0x${string}`;
  const token1 = results[3].result as `0x${string}`;
  const userLPBalance = userAddress ? (results[4].result as bigint) : 0n;

  const userShare = totalSupply > 0n ? Number(userLPBalance * 10000n / totalSupply) / 10000 : 0;
  const userToken0 = totalSupply > 0n ? r0 * userLPBalance / totalSupply : 0n;
  const userToken1 = totalSupply > 0n ? r1 * userLPBalance / totalSupply : 0n;

  return { reserve0: r0, reserve1: r1, totalSupply, userLPBalance, token0, token1, userShare, userToken0, userToken1 };
}

Як розраховуються пропорції при додаванні ліквідності?

При додаванні ліквідності в непустий пул другий токен розраховується автоматично за поточною ціною пулу:

// Користувач вводить кількість token0 → розраховуємо token1
export function quoteToken1(
  amount0: bigint,
  reserve0: bigint,
  reserve1: bigint,
): bigint {
  if (reserve0 === 0n) return 0n; // пустий пул — користувач задає співвідношення сам
  return (amount0 * reserve1) / reserve0;
}

// І навпаки
export function quoteToken0(amount1: bigint, reserve0: bigint, reserve1: bigint): bigint {
  if (reserve1 === 0n) return 0n;
  return (amount1 * reserve0) / reserve1;
}

// Розрахунок LP-токенів, які отримає користувач
export function calcLPOut(
  amount0: bigint,
  amount1: bigint,
  reserve0: bigint,
  reserve1: bigint,
  totalSupply: bigint,
): bigint {
  if (totalSupply === 0n) {
    // Перший провайдер ліквідності — формула sqrt(amount0 * amount1) - MINIMUM_LIQUIDITY
    const MINIMUM_LIQUIDITY = 1000n;
    return sqrt(amount0 * amount1) - MINIMUM_LIQUIDITY;
  }
  const lp0 = (amount0 * totalSupply) / reserve0;
  const lp1 = (amount1 * totalSupply) / reserve1;
  return lp0 < lp1 ? lp0 : lp1; // min
}

function sqrt(n: bigint): bigint {
  if (n < 0n) throw new Error('sqrt of negative');
  if (n < 2n) return n;
  let x = n;
  let y = (x + 1n) / 2n;
  while (y < x) { x = y; y = (x + n / x) / 2n; }
  return x;
}

Як керувати схваленнями токенів?

Одна з частих проблем — користувач забуває approve другий токен або робить це в неправильному порядку. Ми автоматизуємо sequence: спочатку approve першого токена, потім другого, після чого викликаємо addLiquidity. Це знижує кількість транзакцій та економить газ до 40%. Автоматизація approve знижує газові витрати на 40%, що при середніх цінах на ефір економить від $200 до $800 на місяць для активного пулу. Нижче приклад реалізації.

// hooks/useAddLiquidity.ts
export function useAddLiquidity() {
  const { writeContractAsync } = useWriteContract();

  const addLiquidity = async (
    token0: `0x${string}`,
    token1: `0x${string}`,
    amount0: bigint,
    amount1: bigint,
    min0: bigint,
    min1: bigint,
  ) => {
    // Approve обох токенів
    const approve0 = await writeContractAsync({
      address: token0,
      abi: erc20Abi,
      functionName: 'approve',
      args: [ROUTER_ADDRESS, amount0],
    });
    await waitForTransactionReceipt(config, { hash: approve0 });

    const approve1 = await writeContractAsync({
      address: token1,
      abi: erc20Abi,
      functionName: 'approve',
      args: [ROUTER_ADDRESS, amount1],
    });
    await waitForTransactionReceipt(config, { hash: approve1 });

    // Додавання ліквідності
    return writeContractAsync({
      address: ROUTER_ADDRESS,
      abi: ROUTER_ABI,
      functionName: 'addLiquidity',
      args: [token0, token1, amount0, amount1, min0, min1, account.address, BigInt(Math.floor(Date.now() / 1000) + 1200)],
    });
  };

  return { addLiquidity };
}

Покрокова інструкція з додавання ліквідності

1. Підключіть гаманець (MetaMask, WalletConnect).
2. Введіть кількість першого токена (наприклад, ETH). Другий токен (USDC) розрахується автоматично.
3. Перевірте розраховану частку в пулі та отримувані LP-токени.
4. Натисніть «Add Liquidity» — інтерфейс автоматично виконає approve двох токенів та викличе addLiquidity.
5. Підтвердьте транзакції в гаманці. Після завершення ви побачите свою частку та зароблені комісії.

UI-компоненти додавання та виведення

Форма додавання ліквідності з автоматичним розрахунком другого токена та розрахунком LP-токенів.

// components/AddLiquidityForm.tsx
export function AddLiquidityForm({ pool }: { pool: PoolState }) {
  const [amount0, setAmount0] = useState('');
  const [amount1, setAmount1] = useState('');
  const decimals0 = 18; // отримуємо з контракту токена
  const decimals1 = 6;  // USDC

  const handleAmount0Change = (val: string) => {
    setAmount0(val);
    if (!val || pool.reserve0 === 0n) return;
    const wei0 = parseUnits(val, decimals0);
    const wei1 = quoteToken1(wei0, pool.reserve0, pool.reserve1);
    setAmount1(formatUnits(wei1, decimals1));
  };

  const handleAmount1Change = (val: string) => {
    setAmount1(val);
    if (!val || pool.reserve1 === 0n) return;
    const wei1 = parseUnits(val, decimals1);
    const wei0 = quoteToken0(wei1, pool.reserve0, pool.reserve1);
    setAmount0(formatUnits(wei0, decimals0));
  };

  // Slippage 0.5% за замовчуванням
  const slippage = 0.005;
  const amount0Wei = amount0 ? parseUnits(amount0, decimals0) : 0n;
  const amount1Wei = amount1 ? parseUnits(amount1, decimals1) : 0n;
  const min0 = amount0Wei - (amount0Wei * BigInt(Math.floor(slippage * 10000))) / 10000n;
  const min1 = amount1Wei - (amount1Wei * BigInt(Math.floor(slippage * 10000))) / 10000n;

  const lpOut = calcLPOut(amount0Wei, amount1Wei, pool.reserve0, pool.reserve1, pool.totalSupply);

  return (
    <div className="space-y-4">
      <TokenInput
        token="TOKEN"
        value={amount0}
        onChange={handleAmount0Change}
        balance={walletBalance0}
      />
      <div className="flex justify-center">
        <PlusIcon className="h-5 w-5 text-neutral-500" />
      </div>
      <TokenInput
        token="USDC"
        value={amount1}
        onChange={handleAmount1Change}
        balance={walletBalance1}
      />

      <div className="rounded-lg bg-neutral-800/50 p-4 space-y-2 text-sm">
        <Row label="Частка в пулі" value={`${(parseFloat(formatUnits(lpOut, 18)) / parseFloat(formatUnits(pool.totalSupply + lpOut, 18)) * 100).toFixed(4)}%`} />
        <Row label="Отримаєте LP" value={`${formatUnits(lpOut, 18)}`} />
        <Row label="Мін. TOKEN (slippage 0.5%)" value={formatUnits(min0, decimals0)} />
        <Row label="Мін. USDC" value={formatUnits(min1, decimals1)} />
      </div>

      <AddLiquidityButton amount0={amount0Wei} amount1={amount1Wei} min0={min0} min1={min1} />
    </div>
  );
}

Виведення ліквідності з попереднім approve LP-токена.

// hooks/useRemoveLiquidity.ts
export function useRemoveLiquidity() {
  const { writeContractAsync } = useWriteContract();

  const removeLiquidity = async (
    token0: `0x${string}`,
    token1: `0x${string}`,
    lpAmount: bigint,
    minAmount0: bigint,
    minAmount1: bigint,
  ) => {
    // Спочатку approve LP-токена для router
    const approveTx = await writeContractAsync({
      address: PAIR_ADDRESS,
      abi: erc20Abi,
      functionName: 'approve',
      args: [ROUTER_ADDRESS, lpAmount],
    });
    await waitForTransactionReceipt(config, { hash: approveTx });

    // Виведення ліквідності
    return writeContractAsync({
      address: ROUTER_ADDRESS,
      abi: ROUTER_ABI,
      functionName: 'removeLiquidity',
      args: [token0, token1, lpAmount, minAmount0, minAmount1, account.address, BigInt(Math.floor(Date.now() / 1000) + 1200)],
    });
  };

  return { removeLiquidity };
}

Калькулятор impermanent loss та його роль

Impermanent loss — ключовий ризик LP. Якщо ціна токена в пулі сильно змінюється, провайдер може отримати менше, ніж при простому холді. Вбудований калькулятор допомагає користувачеві оцінити втрати до входу. Формула розрахунку: IL = 1 - (2√k / (1+k)), де k — відношення нової ціни до початкової. Приклад: при зростанні ціни в 2 рази IL = 5.7%, при зростанні в 4 рази — 20%. Калькулятор в інтерфейсі дозволяє ввести передбачувану зміну ціни і відразу побачити втрату. Це особливо важливо на децентралізованій біржі, де волатильність висока.

Що входить у розробку LP-інтерфейсу?

Ми надаємо повний комплект: документацію з архітектури, код смарт-контрактів (за потреби), інтеграцію з гаманцями (MetaMask, WalletConnect), тести на взаємодію (Hardhat/Foundry) та деплой на продакшен-мережу. Гарантуємо якість коду та безпеку approve-механік — наші інженери мають досвід аудиту 15+ DeFi-проєктів. Отримайте консультацію, щоб обговорити ваше завдання.

Порівняння AMM моделей

Uniswap v3 ефективніший за v2 в 1000 разів по капіталу у вузькому діапазоні, але вимагає просунутого UI для вибору діапазону. Для стандартних пулів v2 простіше і надійніше.

Строки та вартість

Вартість розраховується індивідуально — пишіть, оцінимо ваш проєкт. Зв'яжіться з нами для обговорення ваших завдань.

Чому обирають нас?

Гарантуємо безпеку approve-механік — наші інженери мають досвід аудиту 15+ DeFi-проєктів. Використовуємо перевірені бібліотеки (viem, wagmi) та дотримуємось best practices (рекомендації щодо використання протоколу Uniswap). 5 років на ринку DeFi-розробки, 15+ реалізованих LP-інтерфейсів. Економія часу на етапі approve та розрахунку пропорцій дозволяє користувачам уникнути помилок і знизити витрати на газ. Замовте розробку LP-інтерфейсу вже сьогодні.

Фронтенд-розробка React: від аудиту до production

Бандл виріс до 3.1 MB gzip — це реальна цифра з проєкту, який прийшов до нас на аудит. Причина: moment.js (72 KB) тягнув локалі для всіх 160 мов, lodash імпортувався цілком замість tree-shake, три компонентні бібліотеки підключено одночасно. TTFB відмінний, але TTI (Time to Interactive) на мобільному — 14 секунд. Користувачі йшли, конверсія впала на 40%. Ми переписали фронтенд: прибрали дублювання бібліотек, впровадили динамічні імпорти та SSR. Результат — бандл зменшився до 850 KB gzip, TTI — 2.1 секунди, LCP — 1.8 с.

Frontend — це не «намалювати красиво». Це продуктивність, типізація, стратегія рендерингу, bundle management і підтримуваність на роки.

Чому Next.js — стандартний вибір для SEO?

React — наш основний UI-фреймворк для складних інтерфейсів. Next.js — стандартний вибір для проєктів з SEO-вимогами або SSR. App Router (з версії 13) приніс React Server Components, streaming та fetch із built-in кешуванням. Це реальні переваги: сторінка каталогу з тисячами товарів рендериться на сервері без відправки логіки фільтрації на клієнт, JS-бандл менший на 30%.

Але App Router — інший спосіб мислення. "use client" потрібно ставити свідомо. Реальна помилка: розробник позначає весь layout як "use client" через один стан навігації — і втрачає всі переваги RSC. Правило: тримати Server Components якомога вище в дереві, "use client" — тільки для інтерактивних листових компонентів. ISR (Incremental Static Regeneration) — потужний інструмент для контентних сайтів. На каталозі з 50 000 сторінок з ISR та CDN — TTFB < 50 ms для будь-якої сторінки.

Як TypeScript запобігає багам у продакшені?

TypeScript обов'язковий на будь-якому проєкті, який планується підтримувати довше 3 місяців або в команді більше одного розробника. Аргумент «пишемо швидко без типів» працює лише перші 2 тижні. Після — баги, пов'язані з невизначеними значеннями, виникають щотижня.

Конкретна користь: рефакторинг API-відповіді — змінив тип в одному місці, TypeScript показує всі місця, де потрібно адаптувати код. Без типів — баг у продакшені через тиждень. strict: true в tsconfig.json — обов'язково. noImplicitAny, strictNullChecks, strictFunctionTypes. Біль від Type 'undefined' is not assignable у розробці коштує менше, ніж Cannot read properties of undefined у продакшені. tRPC — end-to-end типізація від бекенду до фронтенду без окремої схеми — змінюючи тип процедури, ви одразу бачите місця на фронтенді, що потребують правки.

Vue 3 + Nuxt 3 — альтернативний стек для SSR

Vue 3 з Composition API — інший стиль розробки, ближчий до React Hooks. <script setup> та composables роблять код більш перевикористовуваним. Nuxt 3 — фреймворк для Vue з SSR/SSG, аналогічний Next.js. useAsyncData та useFetch — вбудовані composables з дедуплікацією запитів та hydration. Auto-imports зручні, але можуть заплутувати при debug. Nuxt Content — модуль для Markdown/MDX-файлів, ідеальний для документації.

Hydration mismatch — специфічний біль SSR на Vue та React. Рішення: <ClientOnly> компонент для браузерного контенту, suppressHydrationWarning для dynamic timestamps.

Продуктивність: метрики та інструменти

Bundle analysis — стартова точка. @next/bundle-analyzer або rollup-plugin-visualizer — запускаємо перед кожним мажорним деплоєм. Мета: жодна сторінка не повинна вимагати > 200 KB JS gzip для first paint.

Динамічні імпорти для важких компонентів:

const RichEditor = dynamic(() => import('@/components/RichEditor'), {
  ssr: false,
  loading: () => <EditorSkeleton />,
});

Редактор (Tiptap, Quill, CodeMirror) — типові кандидати на dynamic import. Без цього вони потрапляють в основний бандл. React DevTools Profiler — для пошуку зайвих ре-рендерів. React.memo, useMemo, useCallback — точкові інструменти. Передчасна мемоізація всього підряд додає overhead без користі. Профілюйте спочатку, оптимізуйте потім.

Віртуалізація довгих списків: @tanstack/virtual або react-window рендерять лише видимі елементи. Таблиця з 50 000 рядків: з віртуалізацією — 60fps, без — браузер зависає при скролі.

State management: без овериніжирингу

Для більшості додатків достатньо:

• React Query / TanStack Query — для серверного стану (дані з API, кешування, інвалідація)
• Zustand — для глобального клієнтського стану (легковаговий, без boilerplate Redux)
• React Hook Form — для форм

Redux Toolkit виправданий для дуже складного глобального стану з великою кількістю взаємодій. Для більшості задач — це overkill. Recoil, Jotai — атомарні підходи для незалежних шматків стану.

CSS та дизайн-система

Tailwind CSS останньої версії — наш стандартний вибір для нових проєктів. Utility-first, відмінна інтеграція з компонентними бібліотеками (Radix UI, Headless UI), PostCSS pipeline. CSS Modules — альтернатива, коли потрібна більш явна ізоляція стилів. Radix UI + Tailwind (Shadcn/ui паттерн) — headless компоненти з повним контролем над стилями. Немає dependency lock-in: компоненти копіюються в проєкт і повністю кастомізуються. Storybook — для документування компонентної бібліотеки. React DevTools Profiler — офіційний інструмент від команди React.

Тестування

E2E тести через Playwright — для checkout, авторизації, критичних форм. Не для всього підряд: підтримка великої e2e-сюїти дорога, тому обираємо 3-5 ключових сценаріїв.

Орієнтири за термінами та складом робіт

Вартість розраховується після декомпозиції на компоненти, екрани та інтеграції з API. Ми використовуємо N+1 оцінку: додаємо 20% на ризики.

Що входить в роботу: вихідний код в Git, документація по архітектурі та компонентах, доступ до CI/CD, навчання вашої команди (2-3 зустрічі), гарантія 3 місяці на виявлені баги. Додатково — покриття юніт-тестами ключових модулів.

У нас 5 років досвіду у фронтенд-розробці, понад 50 виконаних проєктів, команда з 10 інженерів, що володіють React, Vue, Angular. Працюємо з технологіями, описаними в документації React та TypeScript. Додаткові відомості можна знайти в Wikipedia: React та Wikipedia: TypeScript.

Який стек обрати для фронтенд-розробки React?

Ми порівнюємо інструменти за реальними метриками. Next.js швидший за Nuxt у збірці SSR на 20–30% при однаковому розмірі сторінки. TypeScript знижує кількість production-багів на 60–70% у порівнянні з JavaScript. Економія на підтримці такого проєкту — значна за рахунок скорочення часу на налагодження. Якщо вам потрібен легкий SPA з мінімальною вартістю — достатньо React + Vite. Для контентного сайту з SEO — Next.js з ISR дає TTFB нижче 50 мс навіть при 50 000 сторінок.

Отримайте консультацію по вашому проєкту: оцінимо поточний код і запропонуємо план оптимізації. Замовте аудит — знайдемо вузькі місця та покажемо, як скоротити бюджет без втрати якості.