Розробка Account Abstraction Paymaster під ключ

Розробка Account Abstraction Paymaster

ERC-4337 Account Abstraction усуває головний бар'єр — залежність від нативного токена для газових комісій. Paymaster — це контракт, який бере оплату газу на себе, дозволяючи користувачам взаємодіяти з dApp без необхідності мати ETH. Перехід на gasless UX збільшує конверсію на 40% і знижує відтік користувачів на 30%. Наша команда з досвідом у блокчейн-розробці створює Paymaster-рішення під ключ, гарантуючи оптимальну газову ефективність та захист від атак. Ми використовуємо перевірені патерни та забезпечуємо безшовний UX для ігор, DeFi та соціальних додатків. Отримайте консультацію щодо вашого проєкту — пишіть, оцінимо безкоштовно.

Чому Paymaster критичний для gasless UX?

Без Paymaster користувачі зобов'язані купувати та тримати ETH для кожної транзакції. Це знижує конверсію в 2-3 рази порівняно з gasless досвідом. Paymaster вирішує проблему: він спонсорує газ або приймає оплату в будь-якому ERC-20 токені. Економія на газі для користувачів досягає 100%, а для бізнесу — зниження відтоку на 40%.

Як Paymaster вписується в ERC-4337

У стандартній транзакції: користувач → підписує транзакцію → платить gas в ETH. В ERC-4337 flow: користувач підписує UserOperation (не транзакцію) → Bundler збирає UserOps в батч → EntryPoint контракт викликає validatePaymasterUserOp → якщо Paymaster схвалює — платить gas → postOp викликається після виконання.

UserOperation { sender, // smart account користувача callData, // що виконати paymasterAndData, // адреса Paymaster + його дані signature, // підпис користувача ...gasFields } 

paymasterAndData — це address(paymaster) + bytes(paymasterSpecificData). Paymaster декодує свої дані з цього поля.

Типи Paymaster та їх архітектура

Verifying Paymaster (sponsored gas)

Найпоширеніший патерн: off-chain сервіс вирішує, чи спонсорувати конкретну UserOperation, і підписує дозвіл. Paymaster контракт верифікує цей підпис. EIP-4337 описує сигнатуру _validatePaymasterUserOp.

function _validatePaymasterUserOp( UserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost ) internal override returns (bytes memory context, uint256 validationData) { // Декодуємо дані: підпис backend-а + термін дії (uint48 validUntil, uint48 validAfter, bytes calldata signature) = abi.decode(userOp.paymasterAndData[20:], (uint48, uint48, bytes)); // Хеш для верифікації = хеш UserOp + validUntil + validAfter bytes32 hash = ECDSA.toEthSignedMessageHash( keccak256(abi.encode(userOpHash, validUntil, validAfter)) ); // Якщо підпис від verifyingSigner — спонсоруємо if (ECDSA.recover(hash, signature) != verifyingSigner) { return ("", _packValidationData(true, validUntil, validAfter)); } return ("", _packValidationData(false, validUntil, validAfter)); } 

Backend отримує UserOp від frontend, перевіряє умови (користувач в whitelist? чи досяг ліміту безкоштовних транзакцій? чи тип операції дозволений?), підписує та повертає paymasterAndData. Frontend підставляє в UserOp і відправляє Bundler-у.

ERC-20 Paymaster (gas в токенах)

Користувач платить gas в USDC/USDT замість ETH. Paymaster приймає ERC-20 і поповнює свій ETH депозит в EntryPoint з власних коштів.

function _validatePaymasterUserOp(...) internal override returns (bytes memory context, uint256 validationData) { (address token, uint256 exchangeRate) = abi.decode(userOp.paymasterAndData[20:], (address, uint256)); uint256 tokenCost = (maxCost * exchangeRate) / 1e18; // Перевіряємо allowance користувача require( IERC20(token).allowance(userOp.sender, address(this)) >= tokenCost, "Insufficient allowance" ); // context передаємо в postOp для реального списання return (abi.encode(userOp.sender, token, tokenCost), 0); } function _postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost) internal override { (address sender, address token, uint256 maxTokenCost) = abi.decode(context, (address, address, uint256)); // Реальна вартість може бути менше maxCost uint256 actualTokenCost = (actualGasCost * exchangeRate) / 1e18; IERC20(token).transferFrom(sender, address(this), actualTokenCost); } 

Ключова складність ERC-20 Paymaster — exchange rate. Потрібен актуальний курс ETH/token на момент транзакції. Варіанти: Chainlink oracle, TWAP з Uniswap V3, або централізований price feed від backend.

Порівняння Verifying та ERC-20 Paymaster

Verifying Paymaster за продуктивністю в 2 рази швидше в інтеграції, але потребує жорстких лімітів. ERC-20 Paymaster дає гнучкість, але дорожчий у розробці. Вибір залежить від бізнес-моделі.

Як налаштувати rate limiting для Paymaster?

Без обмежень один користувач може дренувати весь бюджет через спам. Стратегії:

1. Per-user spending limit. Off-chain в Verifying Paymaster backend: кожен адреса має місячний ліміт в USD. Backend відмовляє у підписі при перевищенні.
2. Cooldown період. Не більше N транзакцій на годину на адресу. Зберігається в Redis з TTL.
3. Transaction type whitelist. Backend перевіряє callData userOp: спонсоруються лише виклики конкретних контрактів.
4. Reputation system. Нові акаунти отримують мінімальний ліміт, який зростає після верифікації (Worldcoin, Sign In With Ethereum + email).

Для per-user limit використовуємо Redis з ключем user:{address}:spent та TTL місяць. Cooldown реалізуємо через Redis з лічильником за годину. Whitelist зберігаємо в базі PostgreSQL. Backend підписує тільки якщо всі перевірки пройдені.

Депозит та управління балансом

Paymaster повинен тримати ETH депозит в EntryPoint контракті. EntryPoint списує gas з цього депозиту після кожної спонсорованої UserOperation.

// Поповнення депозиту entryPoint.depositTo{value: 1 ether}(address(paymaster)); // Перегляд балансу uint256 balance = entryPoint.balanceOf(address(paymaster)); // Виведення (unstake period для staked Paymaster) entryPoint.withdrawTo(payable(owner), amount); 

Для production потрібен моніторинг балансу та автоматичне поповнення. Якщо депозит вичерпається — всі UserOp через цей Paymaster почнуть ревертитися. Рекомендуємо: alert при балансі нижче порогу + auto-topup з treasury через Chainlink Automation або кастомний keeper.

Стек та інфраструктура

Вибір Bundler провайдера

Bundler — сервіс, що приймає UserOperations та включає їх в блок. Варіанти:

• Alchemy — найпростіший старт, хороша документація, платний при масштабі
• Stackup — open-source bundler, можна self-host
• Pimlico — спеціалізується на AA, зручний Paymaster API
• Self-hosted (go-bundler) — повний контроль, потрібна інфраструктура

Що входить в роботу?

• Аудит архітектури та вибір типу Paymaster
• Розробка смарт-контракту з тестами (Foundry)
• Backend signer сервіс з API та rate limiting
• Інтеграція з frontend (SDK)
• Моніторинг балансу та автоматичне поповнення
• Документація та навчання команди
• Гарантія 6 місяців на контракти

Процес розробки

Аналітика (2-3 дні). Тип Paymaster (sponsored vs ERC-20), цільові мережі, ліміти та політики спонсорування, вибір Bundler провайдера.

Розробка контракту (1-2 тижні). Verifying або ERC-20 Paymaster, тести на EntryPoint v0.6/v0.7, deposit management.

Backend signer сервіс (1 тиждень). API для підпису UserOp, rate limiting, rate oracle (для ERC-20). Інтеграція з frontend (3-5 днів). SDK підключення, UserOperation побудова, моніторинг статусу.

Моніторинг та операції (3-5 днів). Алерти на баланс, auto-topup, dashboard витрат.

Базовий Verifying Paymaster з rate limiting — 3-4 тижні. ERC-20 Paymaster з oracle та full моніторингом — 5-7 тижнів.

Замовте розробку Paymaster під ключ: залиште заявку, ми розрахуємо вартість та терміни протягом робочого дня. Зв'яжіться з нами для безкоштовної консультації щодо вашого проєкту.