Разработка 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 под ключ: оставьте заявку, мы рассчитаем стоимость и сроки в течение рабочего дня. Свяжитесь с нами для бесплатной консультации по вашему проекту.