Разработка системы управления кошельками для 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 для каждого отслеживаемого проекта и даёт рекомендации.
Пример расчёта airdrop score
Score может включать взвешенные метрики: объём (35%), количество транзакций (25%), уникальные протоколы (20%), дни активности (20%). Веса настраиваются под конкретный проект.Почему газовая оптимизация критична?
При работе с 200 кошельками, 3-5 транзакциями в день на кошелёк важна газовая оптимизация. Транзакции на L2 (Arbitrum, Base, Optimism) в 10-50 раз дешевле mainnet: средняя стоимость газа на L2 составляет $0.02–0.05 за транзакцию против $2–5 на L1. Мы используем batching, где поддерживается multicall, мониторинг gas price для выбора низких периодов и автоматический расчёт минимального баланса ETH на каждом кошельке.
| Параметр | Ethereum L1 | Arbitrum L2 | Optimism L2 | Base L2 |
|---|---|---|---|---|
| Средняя стоимость транзакции | $2–5 | $0.02–0.05 | $0.01–0.03 | $0.02–0.04 |
| Кол-во транзакций на 1 ETH | 200–500 | 10 000–25 000 | 15 000–30 000 | 12 000–20 000 |
Процесс разработки
- Аналитика — разбираем требования: количество кошельков, протоколы, бюджеты, RPC.
- Проектирование — архитектура, схема базы данных, выбор стека.
- Реализация — генерация кошельков, разработка handlers, планировщика, дашборда.
- Тестирование — симуляция на тестнете, проверка anti-sybil метрик.
- Деплой и запуск — развертывание, настройка мониторинга, документирование.
Получите консультацию по вашему проекту — мы подберём оптимальную архитектуру и стек.
Что входит в работу
- Полный набор документации (архитектура, инструкция по эксплуатации).
- Доступ к исходному коду с лицензией на использование.
- Обучение операторов.
- Поддержка на этапе запуска (до 2 недель).
- Гарантия отсутствия backdoors в коде (аудит ключевых частей).
Стек
Наши инженеры имеют многолетний опыт в DeFi и автоматизации. Система построена на production-ready стеке с отказоустойчивостью и мониторингом.
| Компонент | Технология |
|---|---|
| Backend | Node.js + TypeScript, Fastify |
| Task queue | Bull + Redis |
| Database | PostgreSQL + TimescaleDB |
| Blockchain | ethers.js v6, viem |
| RPC | Alchemy, Infura (с failover) |
| Proxy | SOCKS5 rotation (Bright Data, Oxylabs) |
| Frontend | React + TanStack Query |
| Monitoring | Grafana + Prometheus |
Если вам нужна автоматизация airdrop-фарминга — свяжитесь с нами для консультации и оценки вашего проекта.