Интеграция Biconomy: gasless-транзакции и Account Abstraction в dApp

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Интеграция Biconomy: gasless-транзакции и Account Abstraction в dApp
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1189
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929

Пользователь нажимает «Mint» в вашем dApp — и видит MetaMask с запросом 0.003 ETH на газ. У него нет ETH, только NFT и USDC. Конверсия падает. Это не гипотетический сценарий: именно это убивает onboarding в большинстве Web3 приложений для массовой аудитории. Biconomy решает это через аккаунт-абстракцию. Мы внедряем Biconomy SDK в ваш проект под ключ, чтобы пользователи забыли про газ.

Что такое Biconomy и как это работает

Biconomy — это реализация ERC-4337 (Account Abstraction) с собственной инфраструктурой: bundler, Paymaster, и Smart Account контракты. Пользователь не подписывает Ethereum транзакцию — он подписывает UserOperation (структурированный объект), bundler упаковывает несколько UserOperation в одну транзакцию и отправляет в mempool. Paymaster оплачивает газ.

Для разработчика это означает: backend или Paymaster-контракт платит за газ вместо пользователя, пользователь только подписывает intent. Конверсия растёт на 30–50% — реальные цифры из наших проектов.

Три ключевых компонента интеграции

Smart Account

Smart Account — это смарт-контракт, который является кошельком пользователя. В отличие от EOA, он может:

  • Объединять несколько вызовов в одну транзакцию (batch)
  • Поддерживать сессионные ключи (пользователь подписывает один раз, следующие N транзакций — без подписи)
  • Иметь логику восстановления аккаунта
  • Верифицировать подписи через кастомную логику (WebAuthn, passkey)

Biconomy предоставляет Modular Smart Account (v3), который совместим со стандартом ERC-7579 (модульные аккаунты). Деплой Smart Account для нового пользователя происходит автоматически при первом использовании через counterfactual deployment — контракт деплоится только при первой транзакции, а адрес вычисляется детерминированно заранее.

Paymaster

Paymaster — это контракт, который берёт на себя оплату газа. Biconomy предоставляет Sponsorship Paymaster (спонсируемые транзакции) и Token Paymaster (пользователь платит токенами вместо ETH).

Для Sponsorship Paymaster нужно:

  1. Зарегистрировать проект в Biconomy Dashboard
  2. Пополнить баланс MATIC/ETH для покрытия газа
  3. Настроить whitelist контрактов и функций, которые спонсируются

Token Paymaster позволяет пользователю платить USDC, DAI, или любым ERC-20, поддерживаемым Paymaster. Конвертация в нативный токен для оплаты газа происходит внутри UserOperation.

Bundler

Bundler — это нода, которая принимает UserOperation от пользователей, валидирует их, упаковывает в batch и отправляет в сеть. Biconomy предоставляет hosted bundler через API. Для production важен выбор bundler по следующим параметрам:

  • Latency (время от UserOperation до включения в транзакцию)
  • Поддерживаемые чейны
  • Rate limits и надёжность

Как проходит интеграция Biconomy в dApp?

Интеграция начинается с аудита вашего смарт-контракта на совместимость с аккаунт-абстракцией. Мы проверяем, нет ли блокировок вроде tx.origin == msg.sender, и подбираем оптимальную конфигурацию Paymaster.

Стек: @biconomy/sdk v4, viem, wagmi.

import { createSmartAccountClient } from "@biconomy/sdk";
import { createWalletClient, custom } from "viem";
import { polygon } from "viem/chains";

// Создаём Smart Account для пользователя
const walletClient = createWalletClient({
  chain: polygon,
  transport: custom(window.ethereum),
});

const smartAccount = await createSmartAccountClient({
  signer: walletClient,
  bundlerUrl: "https://bundler.biconomy.io/api/v2/137/nJPK7B3ru...",
  paymasterUrl: "https://paymaster.biconomy.io/api/v1/137/Tpk8nuCU...",
  paymasterTokens: [{ address: USDC_ADDRESS, decimal: 6, symbol: "USDC" }],
});

// Batch транзакция: approve + deposit за одну подпись
const txs = [
  { to: TOKEN_ADDRESS, data: approveCalldata },
  { to: PROTOCOL_ADDRESS, data: depositCalldata },
];

const userOpResponse = await smartAccount.sendTransaction(txs, {
  paymasterServiceData: { mode: PaymasterMode.SPONSORED },
});

const { transactionHash } = await userOpResponse.waitForTxHash();

Сессионные ключи

Сессионные ключи — одна из наиболее мощных возможностей Smart Account. Пользователь подписывает политику один раз: «разрешить адресу X вызывать функцию Y контракта Z с суммой не более N токенов в течение 24 часов». После этого сессионный ключ выполняет транзакции без участия пользователя — идеально для игр, автоматических стратегий, подписок.

const sessionModule = await createSessionKeyManagerModule({
  moduleAddress: SESSION_KEY_MANAGER_MODULE_ADDRESS,
  smartAccountAddress: smartAccount.accountAddress,
});

// Создаём сессию с ограничениями
const sessionData = await createSession(
  smartAccount,
  [{ sessionValidationModule: ERC20_SESSION_VALIDATION_MODULE, sessionKeyData }],
  null, // хранение в памяти или IPFS
  { paymasterServiceData: { mode: PaymasterMode.SPONSORED } }
);

Поддерживаемые сети

Сеть Bundler Paymaster Gas token
Ethereum Mainnet Да Да ETH, ERC-20
Polygon Да Да MATIC, USDC
Arbitrum One Да Да ETH
Optimism Да Да ETH
Base Да Да ETH
BSC Да Да BNB
Avalanche Да Да AVAX

Типичные проблемы при интеграции

UserOperation reverts без понятной ошибки. Biconomy bundler валидирует UserOperation перед отправкой, но ошибки из calldata (например, revert в целевом контракте) возвращаются в hex без decode. Используем ethers.utils.parseError() или cast для decode revert reason.

Несовместимость контракта с Smart Account. Некоторые контракты проверяют msg.sender == tx.origin для защиты от контрактных вызовов. Smart Account — это контракт, поэтому tx.origin != msg.sender всегда. Такие проверки блокируют gasless транзакции. Нужно либо убирать проверку в контракте, либо использовать EntryPoint как trusted forwarder.

Counterfactual адрес не совпадает с ожидаемым. Smart Account адрес зависит от версии фабрики, salt, и signerAddress. При смене сети или версии SDK адрес может измениться. Всегда используем smartAccount.getAccountAddress() как единственный источник правды.

Что входит в работу по интеграции Biconomy

  • Аудит существующих контрактов на совместимость с ERC-4337
  • Настройка Paymaster (Sponsorship и/или Token)
  • Разработка слоя UserOperation на фронтенде (SDK + viem)
  • Реализация сессионных ключей, если требуется
  • Тестирование в Testnet и Mainnet (включая fuzzing)
  • Документация по эксплуатации и поддержка 30 дней

Мы работаем с Biconomy с 2022 года — 5+ успешных интеграций в DeFi и NFT проектах. Наши инженеры в курсе последних обновлений SDK и стандартов.

Сравнение: Biconomy vs самостоятельная реализация ERC-4337

Параметр Biconomy Самостоятельно
Время настройки 1-3 дня 2-4 недели
Поддержка сетей 7+ сетей только одна
Мониторинг Dashboard самописный
Безопасность Аудированный codebase свой аудит

Готовы оценить ваш проект? Свяжитесь — за 1 день сделаем анализ и прикинем сроки. Базовая интеграция занимает от 1 до 3 рабочих дней, с сессионными ключами — до 5 дней. Стоимость рассчитывается индивидуально и зависит от сложности контрактов и необходимых доработок.

Не теряйте конверсию из-за газа — внедрите gasless-транзакции уже сейчас.

Разработка смарт-контрактов

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $800k. Смотрим транзакцию в Tenderly: атакующий вызвал deposit(), внутри callback на ERC-777 повторно вызвал withdraw() — баланс обновился только после второго выхода. Классическая reentrancy, но не через ETH transfer, а через хук ERC-777. ReentrancyGuard стоял только на withdraw().

Такие случаи — не редкость. Смарт-контракт — это финансовая логика без возможности пропатчить её ночью. Наша команда разрабатывает контракты под ключ, встраивая защиту от reentrancy, MEV и gas-атак на ранних этапах.

Как мы разрабатываем смарт-контракты под ключ

Начинаем с аудита бизнес-логики и выбора стека. Solidity 0.8.x — стандарт для EVM-совместимых чейнов: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana используем Rust и Anchor: модель аккаунтов и программ требует явного объявления всех ресурсов. Для проектов с формальной верификацией подходит Move (Aptos, Sui) — линейные типы языка исключают копирование ресурсов на уровне компилятора. Vyper выбираем для контрактов, где критична простота аудита (Curve Finance).

Язык Модель исполнения Типичная область Риски
Solidity 0.8.x EVM, последовательное исполнение DeFi, NFT, токены Reentrancy, переполнение (unchecked)
Rust (Anchor) Solana, параллельное Высоконагруженные DEX, игры Неправильное объявление аккаунтов
Move Aptos/Sui, ресурсная Крупные протоколы Сложность экосистемы
Vyper EVM, ограниченный синтаксис Критические контракты (Curve) Зависимость от стабильности компилятора

Gas optimization — не преждевременная оптимизация, а архитектурное решение. На Ethereum mainnet деплой плохо спроектированного контракта может стоить 2–5 ETH только из-за неоптимального storage layout. Переупаковка структуры Proposal с 7 слотов до 4 сэкономила 18k gas на каждом голосовании — около $1.5 при gas price 30 gwei. Экономия на масштабе протокола с тысячами голосований в день даёт ощутимую годовую выгоду.

Типичные ошибки в gas: передача массивов через memory вместо calldata в external функциях (дороже в 2–3 раза); использование require с длинными строками вместо custom error error InsufficientBalance(...). Кастомные ошибки дешевле на 50–200 gas на revert и передают структурированные данные фронтенду.

Почему аудит смарт-контрактов критичен для безопасности

Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:

  1. Статический анализSlither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
  2. Фаззинг и invariant тестыFoundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
  3. Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.

Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.

Какие паттерны апгрейда выбираем

Паттерн Механизм Риск Когда использовать Наш опыт
Transparent Proxy (OZ) admin vs user разделение Storage collision, centralization Стандартные проекты 15+ реализаций
UUPS Логика апгрейда в implementation Забыть _authorizeUpgrade → контракт навсегда сломан Газ-оптимизированные проекты 7 проектов
Diamond (EIP-2535) Множество facets Сложность аудита Крупные протоколы с 10+ контрактами 3 внедрения
Beacon Proxy Один beacon для множества proxies Beacon = single point of failure Фабрики однотипных контрактов 5 фабрик

Storage collision — главная опасность прокси. Implementation v2 не должен добавлять переменные перед существующими. OpenZeppelin Upgrades plugin для Hardhat и Foundry проверяет это автоматически, но только при использовании его API.

Как защитить контракт от MEV и front-running

На Ethereum mainnet транзакции в mempool видны всем. MEV-боты проводят sandwich-атаки на DEX, фронтраннинги минтинга и governance. Решение: commit-reveal scheme для аукционов, приватная отправка через Flashbots PROTECT RPC. EIP-7702 и PBS (proposer-builder separation) меняют картину, но пока не массово.

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

  1. Аналитика — спецификация функций, диаграмма вызовов, анализ edge cases. Без этого кодинг начинается впустую.
  2. Разработка — Solidity/Rust с тестами параллельно. Тест → код → рефакторинг. Используем Foundry для fuzz и invariant тестов.
  3. Внутренний аудит — Slither + Echidna + ручной code review. Foundry invariant tests для протокольных инвариантов.
  4. Внешний аудит — для проектов с реальными деньгами. Срок: 2–4 недели.
  5. Деплой — Foundry scripts или Hardhat Ignition с verify на Etherscan. Gnosis Safe для ownership transfer сразу после деплоя.
  6. Мониторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Что входит в работу

  • Документация на архитектуру и спецификацию контракта (NatSpec).
  • Исходный код с репозиторием и CI (Slither, Foundry, coverage).
  • Развёрнутая версия контракта с verify на блокчейн-эксплорере.
  • Результаты аудита (внутреннего и внешнего по запросу).
  • Доступы к мониторингу и управлению (Gnosis Safe).
  • Гарантия на код: фиксы критических багов в течение месяца после деплоя.
  • Консультация по интеграции с веб-интерфейсом (wagmi, RainbowKit).

Сроки ориентировочно

  • ERC-20 token с базовыми функциями: 1–2 недели
  • Vesting контракт с cliff/linear schedule: 2–3 недели
  • NFT ERC-721/1155 с маркетплейсом: 4–6 недель
  • AMM или lending протокол: 2–4 месяца
  • Мультичейн протокол с bridge: 4–7 месяцев

Аудит добавляет 3–6 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.

Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.