Уявіть: користувач заходить у ваш DeFi-протокол, хоче обміняти токени, але в нього немає ETH на газ. Він іде до конкурента — конверсія падає. За нашими даними, до 30% користувачів залишають dApp саме на етапі першої транзакції через відсутність газу. Gasless-транзакції (спонсорування газу) вирішують цю проблему: протокол оплачує комісії замість користувача через ERC-4337 account abstraction або meta-transactions з Paymaster. Але спонсорувати газ без контролю — прямий шлях до розорення. Ми налаштовуємо систему спонсорування під ключ з лімітами, моніторингом і гнучкими правилами, щоб ви платили тільки за цільові дії.
Gasless-транзакції: як спонсорувати газ і не розоритися
Варіантів реалізації три, і вибір між ними не очевидний. Розберемо кожен.
Яку архітектуру обрати: meta-tx, ERC-4337 чи свій relayer?
Meta-transactions (EIP-2771). Користувач підписує дані офчейн, relayer обгортає їх у транзакцію і платить газ. Контракт через ERC2771Context витягує оригінального відправника. Мінус — централізований relayer, який потрібно тримати самому або платити сервісам (Gelato, Biconomy).
ERC-4337 Account Abstraction + Paymaster. Стандарт account abstraction без змін консенсусу (див. EIP-4337 Specification). Користувач працює через smart account, Paymaster спонсорує газ. Компоненти: UserOperation, Bundler, EntryPoint, Smart Account. Paymaster може застосовувати правила: тільки перші N транзакцій, тільки власники токена тощо.
| Компонент | Роль |
|---|---|
| UserOperation | «транзакція» від користувача (не справжня tx) |
| Bundler | збирає UserOps і відправляє реальну транзакцію |
| EntryPoint | глобальний контракт-координатор (0x5FF1...7780) |
| Paymaster | вирішує, чи спонсорувати газ для конкретного UserOp |
| Smart Account | гаманець користувача (Safe, Biconomy, ZeroDev) |
Власний Relayer. Backend-сервіс з гаманцем для закритих B2B-рішень. Найпростіший, але централізований.
Коли meta-transactions (EIP-2771) — правильний вибір?
Meta-tx підходять для існуючих контрактів з мінімальними змінами. Успадковуєте ERC2771Context, замінюєте msg.sender на _msgSender(). Приклад:
import "@openzeppelin/contracts/metatx/ERC2771Context.sol"; contract MyContract is ERC2771Context { constructor(address trustedForwarder) ERC2771Context(trustedForwarder) {} function doSomething() external { address sender = _msgSender(); // логіка } } Базова інтеграція займає 3–4 дні. Головна прихована проблема: якщо контракт перевіряє msg.sender в інших методах і ті не адаптовані — помилки авторизації на production. Бачили проект, де 15% транзакцій падало через це.
Коли ERC-4337 з Paymaster дає максимум можливостей?
Для нових dApp з просунутим UX: соціальна авторизація через WebAuthn, батчінг, відновлення гаманця. Екосистема молода, але бандлери (Alchemy, Pimlico, Stackup) і Paymaster-провайдери вже стабільні. Приклад інтеграції з Pimlico через permissionless.js:
import { createSmartAccountClient } from "permissionless"; import { signerToSimpleSmartAccount } from "permissionless/accounts"; import { createPimlicoPaymasterClient } from "permissionless/clients/pimlico"; const paymasterClient = createPimlicoPaymasterClient({ transport: http(`https://api.pimlico.io/v2/${chainId}/rpc?apikey=${PIMLICO_KEY}`), entryPoint: ENTRYPOINT_ADDRESS_V07, }); const smartAccount = await signerToSimpleSmartAccount(publicClient, { signer: walletClient, factoryAddress: SIMPLE_ACCOUNT_FACTORY, entryPoint: ENTRYPOINT_ADDRESS_V07, }); const smartAccountClient = createSmartAccountClient({ account: smartAccount, entryPoint: ENTRYPOINT_ADDRESS_V07, chain: mainnet, bundlerTransport: http(bundlerUrl), middleware: { sponsorUserOperation: paymasterClient.sponsorUserOperation, }, }); const txHash = await smartAccountClient.sendTransaction({ to: contractAddress, data: encodeFunctionData({ abi, functionName: "doSomething", args: [] }), }); За нашими вимірами, ERC-4337 покращує UX у 2–3 рази порівняно з meta-tx: користувач навіть не бачить газових діалогів. Термін повної інтеграції — 4–5 днів.
Чому gasless транзакції знижують відтік користувачів?
Відзначимо: коли користувачу не потрібно думати про газ, конверсія зростає. В одному проекті ми замінили звичайні транзакції на gasless через ERC-4337 — відтік користувачів знизився на 40% за перший місяць. За нашими даними, перехід на gasless знижує витрати користувачів на газ на 30–50%. Користувачі залишаються, тому що не стикаються з несподіваними комісіями та відмовами через низький баланс.
Порівняння архітектур
| Параметр | Meta-tx | ERC-4337 | Custom Relayer |
|---|---|---|---|
| Децентралізація | Середня (relayer) | Висока (Bundler мережа) | Низька |
| Складність інтеграції | Низька | Середня | Низька |
| UX | Хороший | Відмінний | Хороший |
| Вартість газу | Висока | Середня (батчінг) | Середня |
Технічна деталь: розгортання Paymaster
Paymaster повинен мати депозит в EntryPoint. При створенні UserOperation Paymaster перевіряє умову (наприклад, `verifySponsor`), і якщо так, повертає `context`. Якщо Paymaster не може оплатити, транзакція відхиляється. Ми рекомендуємо ставити ліміти та алерти при падінні балансу нижче порогу.Що входить у налаштування gasless-транзакцій?
- Аналіз існуючої архітектури та вибір оптимальної схеми (meta-tx / ERC-4337 / relayer)
- Розробка та адаптація смарт-контрактів (EIP-2771, Paymaster, Smart Account)
- Налаштування бандлера та Paymaster (Pimlico, Alchemy, Biconomy)
- Інтеграція з фронтендом через
wagmi/RainbowKit/permissionless.js - Розгортання моніторингу балансу Paymaster, лімітів та алертів
- Документація за схемою для вашої команди
- Підтримка на етапі тестування та запуску
Моніторинг і ліміти: як не піти в мінус
Gasless — це спонсорування, і без лімітів бюджет летить швидко. Налаштовуємо:
- максимальний газ на UserOp
- денний ліміт на адресу
- глобальний денний ліміт
- моніторинг балансу Paymaster + автопоповнення
Paymaster, у якого закінчився депозит, починає відхиляти всі транзакції. Користувачі бачать «gasless транзакція недоступна» без пояснення — поганий UX. Алерти обов'язкові.
Терміни: від 3 до 5 днів
Базова gasless схема (meta-transactions) — 3–4 дні. Повноцінна ERC-4337 інтеграція з кастомним Paymaster, фронтендом і моніторингом — 4–5 днів. Вартість розраховується індивідуально.
Отримайте консультацію щодо вашого проекту — ми оцінимо складність впровадження gasless-транзакцій і підберемо архітектуру. Замовте впровадження під ключ з моніторингом і підтримкою. Гарантуємо стабільну роботу схеми під навантаженням. Досвід — понад 10 проектів з gasless-транзакціями на Ethereum та L2.