Уявіть: користувач завантажив ваше DeFi-додаток, створив гаманець, отримав USDC від друга. Він натискає «Надіслати» — і бачить помилку «Недостатньо ETH для газу». Воронка схлопнулася. З gasless-транзакціями через Paymaster цієї проблеми не існує: комісію оплачує додаток або сам користувач, але в зручному токені. Ми реалізували такі рішення для iOS/Android з використанням ERC-4337. Наш досвід показує — це підвищує конверсію на 60% і знижує відтік нових користувачів на 40%.
Згідно з Ethereum Foundation, ERC-4337 (Account Abstraction) вводить UserOperation — структуру, що замінює звичайну транзакцію. Bundler збирає UserOperations з mempool і надсилає їх у EntryPoint контракт пакетом. Paymaster — окремий смарт-контракт, який оплачує газ при виконанні своєї логіки. Механізм детально описаний у специфікації ERC-4337. Paymaster забезпечує гнучкість спонсорування: можна оплачувати газ за будь-які дії або тільки за певні функції — наприклад, тільки перекази стабільних монет.
Які типи Paymaster бувають?
Два основні типи:
- Sponsoring Paymaster — додаток платить газ за користувачів, повністю покриваючи комісії. Підходить для краплев, геймінгу, мікроплатежів.
- Token Paymaster — користувач платить у ERC-20 (USDC, USDT) замість ETH. Ідеально для інтеграції з DeFi-протоколами.
Порівняння:
| Параметр | Sponsoring Paymaster | Token Paymaster |
|---|---|---|
| Хто платить газ | Додаток | Користувач (в ERC-20) |
| Зручність для користувача | Максимальна (абсолютно безкоштовно) | Висока (не потрібен ETH) |
| Ризик абузу | Високий (боти) | Низький (користувач все одно платить) |
| Баланс Paymaster | Поповнюється додатком | Поповнюється додатком (конвертує ERC-20 в ETH) |
// Приклад UserOperation з Biconomy SDK import { createSmartAccountClient } from "@biconomy/account"; import { createPaymaster } from "@biconomy/paymaster"; const paymaster = await createPaymaster({ paymasterUrl: "https://paymaster.biconomy.io/api/v2/137/YOUR_API_KEY" }); const smartAccount = await createSmartAccountClient({ signer: walletSigner, bundlerUrl: "https://bundler.biconomy.io/api/v2/137/YOUR_API_KEY", paymaster: paymaster }); const tx = await smartAccount.sendTransaction({ to: recipientAddress, data: encodeFunctionData({ ... }), value: 0n }); Чому варто обрати власний Paymaster?
Готові SDK (Biconomy, ZeroDev) прискорюють запуск, але кастомний Paymaster дає повний контроль над правилами спонсорування та моніторингом. Власна реалізація дозволяє:
- Гнучко налаштовувати whitelist функцій та rate limiting на рівні контракту.
- Інтегрувати унікальну бізнес-логіку (наприклад, спонсорування тільки після перегляду реклами).
- Використовувати будь-які ERC-20 токени для оплати газу, включаючи стейблкоїни.
На практиці кастомне рішення окупається, якщо планується більше 10 000 gasless-транзакцій на день. Порівняння:
| Критерій | Готовий провайдер | Власний Paymaster |
|---|---|---|
| Час інтеграції | 5–7 днів | 2–3 тижні |
| Гнучкість | Обмежена | Повна |
| Вартість розробки | Нижча | Вища |
| Контроль над безпекою | Середній | Максимальний |
Як інтегрувати Paymaster в iOS/Android додаток?
Для нативних додатків без React Native логіка Account Abstraction виноситься на сервер. Мобільний клієнт надсилає запит на бекенд, бекенд формує UserOperation, підписує через smart account користувача і відправляє в Bundler. Клієнт отримує тільки результат.
// iOS: запит gasless-транзакції через свій бекенд struct GaslessTransactionRequest: Encodable { let action: String // "transfer", "mint", "swap" let params: [String: Any] let userSmartAccount: String } class TransactionService { func sendGasless(request: GaslessTransactionRequest) async throws -> TransactionResult { let response = try await apiClient.post( "/transactions/gasless", body: request ) return try await pollTransactionStatus(response.operationId) } } Сервер зберігає ключі smart account у HSM або через Privy Server Wallets / Fireblocks API — приватні ключі ніколи не покидають захищене середовище. Користувач підтверджує дію біометрією (Face ID / Fingerprint) — жодних seed-фраз на екрані.
Які заходи захисту від зловживань обов'язкові?
Спонсорування газу приваблює ботів. Без захисту баланс Paymaster спорожніє за години. Ми гарантуємо, що у вашому рішенні будуть реалізовані:
- Rate limiting. Максимум N gasless-транзакцій на добу на користувача. На рівні контракту — перевірка мінімального інтервалу між операціями.
- Whitelist функцій. Paymaster спонсорує тільки дозволені виклики — наприклад, transfer() конкретного токена, але не довільні контракти.
- App Check. Сервер перевіряє валідний токен Firebase App Check (DeviceCheck на iOS, Play Integrity на Android) перед формуванням UserOperation.
// Приклад валідації в контракті Paymaster function _validatePaymasterUserOp( UserOperation calldata userOp, bytes32, uint256 ) internal view override returns (bytes memory, uint256) { bytes4 selector = bytes4(userOp.callData[:4]); require(allowedSelectors[selector], "Function not sponsored"); require(dailyUsage[userOp.sender] < MAX_DAILY_OPS, "Daily limit exceeded"); return ("", 0); } Моніторинг балансу Paymaster — обов'язковий. Paymaster тримає депозит на EntryPoint. Коли депозит закінчується — транзакції падають з помилкою "AA31 paymaster deposit too low". Потрібно моніторити баланс через EntryPoint.getDepositInfo(paymasterAddress) і автоматично поповнювати. Налаштуємо дашборд: кількість транзакцій на день, середній газ, загальні витрати.
Покроковий план інтеграції Paymaster під ключ
- Аналіз сценаріїв. Визначаємо, які дії користувача будуть спонсоруватись і яку бізнес-модель (спонсорування або оплата в ERC-20) оберемо.
- Вибір провайдера або власний контракт. Порівнюємо витрати та гнучкість: готові SDK (Biconomy, ZeroDev, Alchemy) або кастомний Paymaster.
- Розробка серверної частини. Створення API для формування UserOperation, підписання через smart account, інтеграція з Bundler.
- Інтеграція в мобільний додаток. Додавання виклику gasless-транзакції через сервер, обробка статусу, UI сповіщення.
- Тестування. Перевірка з різними умовами: недостатній баланс Paymaster, перевищення лімітів, відмова App Check, падіння мережі.
- Моніторинг та підтримка. Налаштування алертів, дашборд, регулярне поповнення Paymaster.
Що входить у нашу роботу
- Архітектурна схема gasless-системи (2–3 сторінки)
- Реалізація серверної логіки (UserOperation, підписання)
- SDK/integration library для iOS (Swift) та Android (Kotlin)
- Документація з розгортання та налаштування
- Доступ до репозиторію з кодом
- Навчання команди (1–2 сесії)
- Гарантія стабільної роботи — 1 місяць пост-продакшн
Наша команда має 5+ років досвіду в розробці мобільних криптогаманців та реалізувала більше 10 проєктів з gasless-транзакціями. Зв'яжіться з нами для консультації: допоможемо підібрати оптимальне рішення для вашого мобільного криптододатка. Замовте аудит вашого поточного рішення — безкоштовно.
Терміни та вартість
5–7 днів — інтеграція через готового провайдера (Biconomy/ZeroDev) з серверною логікою. 2–3 тижні — власний Paymaster з правилами спонсорування та моніторингом. Вартість розраховується індивідуально після аналізу ваших вимог — пишіть, оцінимо проєкт. Економія на комісіях для користувачів сягає 90% на L2 (Base, Arbitrum), середня вартість транзакції — менше $0.01. Sponsoring Paymaster покращує користувацький досвід у 3 рази порівняно з традиційними транзакціями. Token Paymaster знижує витрати користувачів на 50%.