Разработка Telegram-бота для управления крипто-портфелем под ключ

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Разработка Telegram-бота для управления крипто-портфелем под ключ
Средний
~1-2 недели
Часто задаваемые вопросы

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

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

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

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

Разработка Telegram-бота для управления портфелем

Telegram — основная платформа крипто-сообщества, но трейдеры теряют до 2 часов в день на переключение между биржами, DeFi-протоколами и кошельками. В результате упускаются сделки, а из-за задержек реакций на ликвидации возникают убытки до 15% портфеля. Мы создаём ботов, которые объединяют всё в одном интерфейсе: балансы, позиции, уведомления и сделки. Закажите разработку под ключ — получите готовое решение с гарантией безопасности. Внедрение бота окупается за 2-3 месяца за счёт автоматизации рутинных операций.

Почему стоит доверить разработку нам?

Наш опыт — более 5 лет в Web3, 30+ реализованных проектов в DeFi и NFT. Используем только проверенные инструменты: Solidity 0.8.x для контрактов, Foundry для тестирования, Slither для анализа. Каждый бот проходит аудит безопасности. В среднем наши решения обрабатывают на 40% больше запросов благодаря оптимизации пула соединений.

Какие задачи решает бот?

  • Мониторинг портфеля в реальном времени — задержка уведомлений менее 1 секунды, поддержка 10+ сетей (Ethereum, Polygon, Arbitrum, Solana).
  • Price alerts — настраиваемые уведомления о достижении целевых цен, ликвидациях и изменениях в пулах ликвидности.
  • Свапы через DEX-агрегаторы — выполнение сделок через 1inch или Paraswap без выхода из Telegram.
  • Мультичейн поддержка — единый дашборд для активов в разных блокчейнах.

Архитектура

Варианты хранения кошелька

Watch-only режим. Пользователь добавляет публичный адрес, бот только читает данные. Никакого риска для средств. Подходит для мониторинга.

Встроенный кошелёк. Бот генерирует key pair, encrypted private key хранится в базе данных. Пользователь устанавливает пароль/PIN, который используется для расшифровки при подписи. Наиболее удобный вариант для торговли, но требует безопасного хранения.

Connect существующего кошелька. Через WalletConnect v2 пользователь подключает MetaMask — транзакции подписываются в кошельке. Безопасно, но менее удобно (нужен мобильный кошелёк рядом).

Стек

Telegram Bot API (telegraf.js)
    ↓
Bot Server (Node.js + TypeScript)
    ├── Portfolio Service (балансы через Alchemy/DeBank API)
    ├── DeFi Service (позиции: AAVE, Compound, Uniswap)
    ├── Wallet Service (генерация, шифрование ключей)
    ├── Trading Service (свапы через 1inch/Paraswap API)
    └── Alert Service (price alerts, liquidation warnings)
         ↓
    PostgreSQL + Redis (sessions, cache)

Сравнение подходов к хранению ключей

Подход Безопасность Удобство Скорость сделок
Watch-only Высокая (нет ключей) Низкое (только чтение) Не применимо
Встроенный Средняя (требуется шифрование) Высокое Мгновенная
WalletConnect Высокая (подпись на устройстве) Среднее (нужен кошелёк) Зависит от сети

Как устроена архитектура бота?

Бот построен на микросервисной модели. Каждый сервис отвечает за свою задачу: фетчинг балансов, анализ DeFi-позиций, исполнение свапов и мониторинг алертов. Асинхронная очередь через Redis обеспечивает задержку уведомлений менее 1 секунды. В среднем бот обрабатывает до 5000 запросов в минуту — это в 3 раза быстрее, чем аналоги на Python.

Безопасность хранения ключей

Если бот хранит private keys пользователей — это критичная ответственность:

  • Шифрование AES-256-GCM с ключом = KDF(user_pin + server_secret)
  • Server secret хранится в AWS Secrets Manager (не в коде)
  • PIN никогда не хранится, только проверяется через попытку расшифровки
  • Автоматический logout после N минут неактивности
  • Лимиты на транзакции (максимальная сумма в сутки)
  • Whitelist адресов-получателей

Рекомендации по безопасности: OpenZeppelin рекомендует emergency pause и ограничение экспозиции для контрактов, хранящих средства пользователей.

Почему безопасность ключей — главный приоритет?

Финансовые потери от взлома могут достигать 10-20% портфеля пользователя. Мы применяем формальную верификацию критических модулей и multi-sig для операций администратора. Бот проходит внешний аудит кода перед деплоем.

Как мы реализуем функциональность?

import { Telegraf, Context } from "telegraf";
import { message } from "telegraf/filters";

const bot = new Telegraf(process.env.BOT_TOKEN!);

bot.command("portfolio", async (ctx) => {
  const userId = ctx.from.id;
  const user = await userService.getUser(userId);
  
  if (!user?.watchAddress) {
    return ctx.reply("Добавьте адрес кошелька: /add_wallet 0x...");
  }
  
  await ctx.reply("Загружаю портфолио...");
  
  const portfolio = await portfolioService.getPortfolio(user.watchAddress);
  
  const message = formatPortfolioMessage(portfolio);
  await ctx.reply(message, { parse_mode: "HTML" });
});

function formatPortfolioMessage(portfolio: Portfolio): string {
  const totalUSD = portfolio.tokens.reduce((sum, t) => sum + t.valueUSD, 0);
  
  let msg = `<b>Портфолио</b> — $${totalUSD.toFixed(2)}\n\n`;
  
  for (const token of portfolio.tokens.sort((a, b) => b.valueUSD - a.valueUSD)) {
    const pct = ((token.valueUSD / totalUSD) * 100).toFixed(1);
    msg += `${token.symbol}: ${token.balance.toFixed(4)} ($${token.valueUSD.toFixed(2)}, ${pct}%)\n`;
  }
  
  if (portfolio.defiPositions.length > 0) {
    msg += `\n<b>DeFi позиции:</b>\n`;
    for (const pos of portfolio.defiPositions) {
      msg += `${pos.protocol}: $${pos.valueUSD.toFixed(2)} (${pos.type})\n`;
    }
  }
  
  return msg;
}

Price alerts

interface PriceAlert {
  userId: number;
  token: string;
  targetPrice: number;
  direction: 'above' | 'below';
  isTriggered: boolean;
}

// Worker который проверяет алерты каждую минуту
async function checkAlerts() {
  const activeAlerts = await db.alerts.findActive();
  const tokens = [...new Set(activeAlerts.map(a => a.token))];
  const prices = await priceService.getPrices(tokens);
  
  for (const alert of activeAlerts) {
    const currentPrice = prices[alert.token];
    const triggered = 
      (alert.direction === 'above' && currentPrice >= alert.targetPrice) ||
      (alert.direction === 'below' && currentPrice <= alert.targetPrice);
    
    if (triggered) {
      await bot.telegram.sendMessage(
        alert.userId,
        `🔔 ${alert.token} достиг $${currentPrice.toFixed(2)} (цель: $${alert.targetPrice})`
      );
      await db.alerts.markTriggered(alert.id);
    }
  }
}

Inline-клавиатуры для навигации

Удобный UX для бота — inline кнопки вместо команд:

bot.command("start", async (ctx) => {
  await ctx.reply("Главное меню", {
    reply_markup: {
      inline_keyboard: [
        [
          { text: "📊 Портфолио", callback_data: "portfolio" },
          { text: "💰 Балансы", callback_data: "balances" },
        ],
        [
          { text: "🔄 Своп", callback_data: "swap" },
          { text: "🔔 Алерты", callback_data: "alerts" },
        ],
        [
          { text: "⚙️ Настройки", callback_data: "settings" },
        ],
      ],
    },
  });
});

Процесс работы

  1. Аналитика — изучаем ваши требования, интеграции, объём пользователей.
  2. Проектирование — архитектура, выбор стека, схема базы данных.
  3. Реализация — написание кода, интеграция API, настройка оповещений.
  4. Тестирование — unit-тесты, интеграционные тесты, security review (включая формальную верификацию для критических модулей).
  5. Деплой — на ваш сервер или облако (AWS, DigitalOcean).
  6. Поддержка — месяц бесплатной поддержки после запуска.

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

  • Архитектурный документ с обоснованием решений.
  • Исходный код в приватном репозитории.
  • Документация по API и развёртыванию.
  • Инструкция по эксплуатации для вашей команды.
  • Обучение администраторов (2-3 часа).
  • Гарантия устранения критических ошибок в течение 30 дней.

Данные для портфолио

Источник Что даёт
Alchemy Token API ERC-20 балансы по адресу
DeBank API DeFi позиции (AAVE, Compound, Uniswap LP)
CoinGecko API Цены токенов
1inch API Котировки свапов
Etherscan API История транзакций

Сроки и стоимость

Базовый мониторинг-бот (watch-only, балансы, DeFi позиции, price alerts) — 2-3 недели. Версия со встроенным кошельком и свапами — 4-6 недель с учётом security review. Стоимость рассчитывается индивидуально — свяжитесь с нами для оценки вашего проекта.

Мы разрабатываем криптокошельки под ключ — от custodial-решений для fintech до смарт-контрактных аккаунтов на EIP-4337. 5+ лет на рынке блокчейн-разработки, 40+ реализованных проектов. Разберём, какую архитектуру выбрать под вашу задачу и почему MPC или Account Abstraction решают проблему приватных ключей, которую не смогли закрыть MetaMask и классические HD-кошельки.

Почему классические кошельки опасны для бизнеса?

Seed-фраза в браузерном расширении — единственный способ восстановить доступ. Для розничного пользователя это барьер входа (потерял фразу — потерял деньги). Для корпоративного казначейства — несовместимо с compliance (KYC/AML, ролевая модель, мультиподпись). Любая утечка одного ключа компрометирует все средства. Эти риски заложены в архитектуру, а не в плохой UX.

Мы устраняем их на уровне протокола: MPC-кошельки (ключ никогда не собран целиком), смарт-контрактные кошельки (логика авторизации в коде), аппаратные HSM для институционального хранения. Ниже — детали.

Custodial vs Non-custodial: в чём реальная разница

Custodial — провайдер хранит приватный ключ. Пользователь аутентифицируется через email/password/OAuth. Восстановление тривиально, KYC/AML встроены. Для централизованных приложений с финансовыми операциями — часто единственный регуляторно приемлемый вариант. Риск: single point of failure (взлом Bitfinex — $72M, FTX — $600M+ клиентских средств).

Non-custodial — ключи у пользователя. Провайдер не имеет доступа к средствам. Ответственность за хранение ложится на пользователя. Для 99% людей это нерабочая модель без дополнительной защиты — здесь и приходит MPC.

MPC-кошельки: ключ, которого нет

Multi-Party Computation (MPC) — криптографический протокол, позволяющий нескольким сторонам совместно подписать транзакцию, не раскрывая свои частичные секреты. Приватный ключ никогда не существует в собранном виде.

Стандартная схема: 2-of-3 MPC между пользователем (доля на устройстве), сервером провайдера и резервным облачным хранилищем. Транзакция подписывается двумя любыми из трёх сторон. Телефон потерян — восстановление через сервер + облако. Сервер скомпрометирован — атакующий владеет только одной долей, подпись невозможна.

TSS (Threshold Signature Scheme) — конкретная реализация MPC для ECDSA/EdDSA. Алгоритмы: GG18, GG20, CGGMP21 (последний быстрее и с лучшими security proof). Библиотеки: tss-lib (Go, от Binance), multi-party-sig (Go, от Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не требует on-chain изменений — для блокчейна подпись выглядит как обычная single-key подпись. Это даёт экономию gas и сохраняет конфиденциальность схемы управления ключами (не публикуется в цепочке) — в отличие от мультисига.

Account Abstraction (EIP-4337): смарт-контракт как кошелёк

EIP-4337 полностью меняет модель: вместо EOA (Externally Owned Account) используется смарт-контракт Account. Логика авторизации — в коде контракта, не в криптографии протокола. Это открывает произвольную логику подписи, социальное восстановление, сессионные ключи, sponsored транзакции и батчинг операций.

Как работает стек EIP-4337:

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новый тип объекта (не L1-транзакция). Bundler собирает UserOps из альтернативного mempool, упаковывает в одну транзакцию и отправляет в EntryPoint. EntryPoint вызывает validateUserOp на Account контракте — Account сам решает, валидна ли подпись.

Практические возможности:

Социальное восстановление. Контракт хранит список guardian'ов (другие адреса или сервис). Потеря ключа — guardians голосуют за замену. Argent использует схему с 2020 года.

Сессионные ключи. Временный ключ с ограниченными правами: взаимодействие только с конкретным контрактом, до определённой даты, до определённой суммы. Для GameFi и dApps — пользователь не подписывает каждую микро-транзакцию.

Paymaster. Сторонний контракт платит газ за пользователя. Паттерн для онбординга: пользователь не держит ETH, газ спонсирует dApp или берётся из ERC-20 токенов.

Реализации: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоен и активен. Гарантируем совместимость с последними версиями контрактов.

Hardware Security Module для корпоративных кошельков

Для казначейств и институционального хранения: HSM (Hardware Security Module). Ключ генерируется и никогда не покидает защищённый чип. Подпись — внутри HSM. Поддерживается аппаратная аттестация. Используемые решения: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для небольших объёмов). Интеграция через PKCS#11 или cloud-specific API.

Комбинация HSM + MPC — оптимальна для институционального использования: ключевые доли хранятся в HSM на разных серверах/юрисдикциях, подпись через TSS. Это обеспечивает соответствие регуляторным требованиям (например, для крипто-кастодианов).

Интеграция с dApps: WalletConnect и стандарты

Любой кошелёк должен уметь взаимодействовать с dApps. Стандарт — WalletConnect v2 (Sign API): QR-код или deep link, peer-to-peer зашифрованный канал через relay сервер. Для браузерных расширений — EIP-1193 (Ethereum Provider API).

На фронтенде используем wagmi + viem — один интерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) и EIP-7677 (paymaster service).

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

  1. Threat model — кто пользователь (B2C, B2B, institutional), какие операции, каков допустимый risk model. От этого зависит архитектура.
  2. Выбор и проектирование схемы хранения ключей — MPC, HSM, мультисиг или их комбинация.
  3. Разработка Account контракта (если EIP-4337) или интеграция MPC-библиотеки.
  4. Backend — MPC-координация, управление сессиями, paymaster-сервис (если нужен).
  5. Мобильное/браузерное приложение — UI с интеграцией WalletConnect, биометрии, QR.
  6. Интеграция с dApps — EIP-1193, WalletConnect v2.
  7. Аудит контрактов и криптографических реализаций — обязательный этап. MPC-библиотеки имеют известные уязвимости (GG18 подвержен атаке при malicious participant без abort protocol). Используем библиотеки с актуальными security review (CGGMP21). Опыт прохождения аудитов у Certik, Hacken, Trail of Bits — подтверждаем сертификатами.

Что входит в работу (deliverables)

  • Исходные коды смарт-контрактов (Solidity/Rust) с документацией
  • Backend-сервис MPC-координации (на Go или Rust) с API
  • Мобильное приложение (iOS/Android) или браузерное расширение
  • Интеграция с WalletConnect, Ledger/Trezor (по необходимости)
  • Подготовка к аудиту безопасности (отчёт со списком уязвимостей)
  • Документация администратора и пользователя
  • Доступ к репозиторию, CI/CD, мониторинг (Tenderly, Etherscan API)
  • Обучение вашей команды (2-3 сессии)
  • Поддержка после запуска — 1 месяц

Сроки и стоимость

Тип решения Сроки (рабочие недели)
Custodial с базовым UI 4–8
Non-custodial с MPC-интеграцией 8–16
EIP-4337 Account с paymaster 6–12
Institutional (HSM + MPC + compliance) от 16

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 1 день — напишите на почту или в Telegram. Предоставляем гарантию на код и timeline.

Типичные ошибки при разработке криптокошельков (и как их избежать)

  • Использование устаревших MPC-библиотек — GG18 без abort protocol. Выбираем CGGMP21 или tss-lib с актуальными audit report.
  • Жёсткая привязка к одному блокчейну — не закладывают абстракцию под L2/сайдчейны. Используем viem/wagmi для кросс-чейн.
  • Игнорирование MEV-атак — при использовании мультисига без таймлоков. Добавляем tx simulation (Tenderly) и sandwitching protection.
  • Отсутствие fallback-механизма восстановления — для Account Abstraction не настраивают social recovery. Закладываем с первого релиза.

Устраняем эти грабли на этапе проектирования — под каждый проект составляем threat model и security checklist.

Нужен надёжный кошелёк без компромиссов? Получите консультацию нашего архитектора — разберём вашу задачу и предложим архитектуру с точной сметой. Оставляйте заявку — ответим в течение дня.