Разработка системы управления кошельками для airdrop-фарминга

Разработка системы управления кошельками для airdrop-фарминга

Airdrop-фарминг — это профессиональная деятельность, требующая управления сотнями кошельков, систематических on-chain транзакций и одновременной работы с десятками протоколов. Ручное управление сотнями кошельков требует сотен часов в месяц и неизбежно ведёт к ошибкам: забытые транзакции, неоптимальный gas, корреляция паттернов, которая приводит к sybil-банам. По статистике, при ручном управлении около 30% фармеров сталкиваются с sybil-детектом хотя бы раз. Автоматизация решает эти проблемы, позволяя сосредоточиться на стратегии, а не на кликах. Наш опыт в этой сфере позволяет избежать типичных ошибок, которые ведут к потере airdrop-квалификации. Система автоматизации — обязательный инструмент для серьёзного фармера. Свяжитесь с нами, чтобы обсудить ваши задачи и получить индивидуальный проект автоматизации.

Что такое профессиональный airdrop-фарминг

Анализ крупных airdrop-кампаний (Arbitrum, Optimism, ZkSync, LayerZero, EigenLayer) показывает паттерны, которые награждались: регулярная активность в течение многих месяцев, разнообразие протоколов, нативные транзакции (не только bridging), держание токенов, участие в governance. Система должна автоматизировать именно эти паттерны, сохраняя органичность активности.

Архитектура системы

Иерархия кошельков

Профессиональный фармер работает с несколькими уровнями ключей:

Master wallet — холодный кошелёк (Ledger/Trezor или air-gapped machine). Хранит основной капитал. Никогда не используется напрямую в протоколах.

Fund wallets (2-5 штук) — промежуточные кошельки для распределения средств. Получают ETH/USDC от master, распределяют по farming wallets.

Farming wallets (50-500 штук) — рабочие кошельки, которые непосредственно взаимодействуют с протоколами. Каждый генерируется как отдельный HD-путь от одной или нескольких seed фраз.

Master Wallet ↓ (manual transfers) Fund Wallets [1-5] ↓ (automated distribution) Farming Wallets [50-500] ↓ (automated interactions) DeFi Protocols 

Важно: farming wallets не должны иметь прямых on-chain связей с master wallet. Цепочка fund wallet → farming wallet с разными временными интервалами снижает корреляцию.

Генерация и хранение ключей

Все farming wallets генерируются детерминированно из seed фраз по спецификации BIP44:

import { HDNodeWallet, Mnemonic } from "ethers"; function generateFarmingWallets( mnemonic: string, count: number, startIndex: number = 0 ): WalletInfo[] { const masterNode = HDNodeWallet.fromMnemonic( Mnemonic.fromPhrase(mnemonic) ).derivePath("m/44'/60'/0'/0"); return Array.from({ length: count }, (_, i) => { const wallet = masterNode.deriveChild(startIndex + i); return { index: startIndex + i, address: wallet.address, privateKey: wallet.privateKey, derivationPath: `m/44'/60'/0'/0/${startIndex + i}`, }; }); } 

Хранение ключей: никогда не храним private keys в открытом виде. Варианты — шифрование через AES-256-GCM с паролем (KDF: Argon2id), хранение только seed phrase + on-demand derivation или HashiCorp Vault для командного использования.

База данных кошельков и активности

CREATE TABLE wallets ( id SERIAL PRIMARY KEY, address VARCHAR(42) UNIQUE NOT NULL, derivation_path VARCHAR(64), wallet_group VARCHAR(64), created_at TIMESTAMPTZ DEFAULT NOW(), last_active_at TIMESTAMPTZ, total_gas_spent NUMERIC(30, 18) DEFAULT 0, notes TEXT, tags TEXT[] ); CREATE TABLE protocol_interactions ( id BIGSERIAL PRIMARY KEY, wallet_id INTEGER REFERENCES wallets(id), protocol VARCHAR(128) NOT NULL, chain_id INTEGER NOT NULL, tx_hash VARCHAR(66), action_type VARCHAR(64), amount NUMERIC(30, 18), gas_used NUMERIC(30, 18), executed_at TIMESTAMPTZ DEFAULT NOW(), status VARCHAR(16) DEFAULT 'pending', metadata JSONB ); CREATE TABLE farming_tasks ( id BIGSERIAL PRIMARY KEY, wallet_id INTEGER REFERENCES wallets(id), task_type VARCHAR(128) NOT NULL, protocol VARCHAR(128) NOT NULL, chain_id INTEGER NOT NULL, parameters JSONB NOT NULL, scheduled_at TIMESTAMPTZ, executed_at TIMESTAMPTZ, status VARCHAR(16) DEFAULT 'pending', retry_count INTEGER DEFAULT 0, error_message TEXT ); 

Как мы автоматизируем взаимодействия?

Task Runner

Система выполнения задач имитирует человеческое поведение: случайные задержки между транзакциями, вариативное время суток, разные gas prices.

class FarmingTaskRunner { async executeTask(task: FarmingTask): Promise<TxReceipt> { const wallet = await this.walletManager.getWallet(task.walletId); const provider = this.getProvider(task.chainId); // Случайная задержка 30с - 5 мин перед транзакцией const delay = randomBetween(30_000, 300_000); await sleep(delay); // Случайное изменение gas price в пределах ±10% const gasPrice = await this.getGasWithVariance(provider, 0.1); const handler = this.handlers.get(task.taskType); if (!handler) throw new Error(`Unknown task type: ${task.taskType}`); return handler.execute(wallet, task.parameters, { gasPrice }); } private async getGasWithVariance(provider: Provider, variance: number) { const feeData = await provider.getFeeData(); const base = feeData.maxFeePerGas!; const multiplier = 1 + (Math.random() * 2 - 1) * variance; return base * BigInt(Math.round(multiplier * 100)) / 100n; } } 

Protocol Handlers

Для каждого протокола — отдельный handler. Пример для Uniswap V3:

class UniswapV3SwapHandler implements ProtocolHandler { async execute( wallet: Wallet, params: SwapParams, options: ExecutionOptions ): Promise<TxReceipt> { const router = new Contract(UNISWAP_V3_ROUTER, ROUTER_ABI, wallet); const deadline = Math.floor(Date.now() / 1000) + 1800; // 30 мин const tx = await router.exactInputSingle({ tokenIn: params.tokenIn, tokenOut: params.tokenOut, fee: params.fee, recipient: wallet.address, deadline, amountIn: params.amountIn, amountOutMinimum: params.minAmountOut, sqrtPriceLimitX96: 0, }, { maxFeePerGas: options.gasPrice, maxPriorityFeePerGas: options.maxPriorityFeePerGas, }); return tx.wait(); } } 

Аналогичные handlers создаются для Curve, AAVE, GMX, Stargate, Wormhole/LayerZero bridge, Pendle и других протоколов.

Как защититься от sybil-детекта?

Современные airdrop-системы активно борются с sybil-атаками. Мы учитываем несколько факторов:

• Уникальность активности. Не копируем паттерны между кошельками: разные суммы, разные протоколы, разные временные паттерны.
• IP rotation. Каждый кошелёк работает через отдельный proxy/VPN. Общий IP — сильный sybil-сигнал.
• Source of funds. Цепочка финансирования не должна прослеживаться к одному источнику. CEX withdrawals на разные кошельки — хорошо, прямой перевод — плохо.
• Age of wallet. Старые кошельки ценятся больше. Система создаёт кошельки заблаговременно и даёт им «историю» до целевого дедлайна.

Согласно аналитике Nansen, корреляция IP-адресов является одним из главных факторов sybil-детекта в крупных airdrop-кампаниях.

Мониторинг и аналитика

Для каждого кошелька система показывает: on-chain активность по протоколам (с датами), потраченный gas (в USD), текущие позиции, score по известным метрикам (объём, количество транзакций, уникальные протоколы, дни активности) и текущий баланс по цепям. Система автоматически рассчитывает estimated airdrop score для каждого отслеживаемого проекта и даёт рекомендации.

Почему газовая оптимизация критична?

При работе с 200 кошельками, 3-5 транзакциями в день на кошелёк важна газовая оптимизация. Транзакции на L2 (Arbitrum, Base, Optimism) в 10-50 раз дешевле mainnet: средняя стоимость газа на L2 составляет $0.02–0.05 за транзакцию против $2–5 на L1. Мы используем batching, где поддерживается multicall, мониторинг gas price для выбора низких периодов и автоматический расчёт минимального баланса ETH на каждом кошельке.

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

1. Аналитика — разбираем требования: количество кошельков, протоколы, бюджеты, RPC.
2. Проектирование — архитектура, схема базы данных, выбор стека.
3. Реализация — генерация кошельков, разработка handlers, планировщика, дашборда.
4. Тестирование — симуляция на тестнете, проверка anti-sybil метрик.
5. Деплой и запуск — развертывание, настройка мониторинга, документирование.

Получите консультацию по вашему проекту — мы подберём оптимальную архитектуру и стек.

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

• Полный набор документации (архитектура, инструкция по эксплуатации).
• Доступ к исходному коду с лицензией на использование.
• Обучение операторов.
• Поддержка на этапе запуска (до 2 недель).
• Гарантия отсутствия backdoors в коде (аудит ключевых частей).

Стек

Наши инженеры имеют многолетний опыт в DeFi и автоматизации. Система построена на production-ready стеке с отказоустойчивостью и мониторингом.

Если вам нужна автоматизация airdrop-фарминга — свяжитесь с нами для консультации и оценки вашего проекта.