Разработка системы сегрегации активов кастодиана под ключ

Представьте: у кастодиана миллионы клиентов, все активы в одном горячем кошельке. При банкротстве — суды, клиенты не могут доказать свои доли. По данным Chainalysis, потери от подобных инцидентов достигают $2 млрд в год. Знакомая ситуация? Мы разрабатываем кастодиальные системы с строгой сегрегацией активов, чтобы такого не случилось. Каждый клиент видит свои средства на уникальном адресе или в зашифрованном учёте. За 20+ проектов накопили опыт, который позволяет сделать систему надёжной и проходимой для аудита.

Получите консультацию инженера — оценим проект за 2 дня.

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

Регуляторы (MiCA в EU, FCA в UK) прямо требуют отделения клиентских активов от собственных. Согласно Article 36 of MiCA Regulation, кастодианы обязаны обеспечивать сегрегацию активов. Для крипто-кастодианов в США пока нет единого стандарта, но BitLicense уже содержит требования к сегрегации. Аудитор в любой момент должен сопоставить on-chain адреса с записями о клиентах — активы клиента A не должны быть перемешаны с активами клиента B. Нарушение ведёт к потере лицензии и судебным искам.

Архитектурные модели: сравнение — разработка системы сегрегации

Гибридная модель обеспечивает баланс безопасности и затрат в 3 раза эффективнее чисто виртуальной. Для крупных клиентов — выделенные адреса, для розничных — виртуальная сегрегация с возможностью перевода на dedicated address по запросу. Снижение operational costs на 30-40% по сравнению с полной сегрегацией.

Как устроена система сегрегации активов?

Полная сегрегация (Full Segregation)

Каждый клиент получает уникальный on-chain адрес (или набор — по одному на каждый blockchain). Активы физически разделены на уровне блокчейна. Это максимальная прозрачность для клиента и аудитора, простое доказательство права собственности и изоляция рисков. Недостаток — высокие operational costs при большом числе клиентов.

Управление адресами

Ключи хранятся в HSM. Адреса генерируются детерминированно через HD-derivation:

m/44'/60'/{clientId}'/0/0 → основной адрес клиента
m/44'/60'/{clientId}'/0/1 → адрес для конкретного актива
m/44'/60'/{clientId}'/1/0 → change адрес

Это позволяет восстановить все адреса из master seed без дополнительного хранилища.

Бухгалтерский учёт (Ledger)

Двойная запись обязательна. Каждое движение активов балансируется:

CREATE TABLE ledger_entries (
    id BIGSERIAL PRIMARY KEY,
    entry_type VARCHAR(32) NOT NULL,
    client_id UUID NOT NULL REFERENCES clients(id),
    asset VARCHAR(64) NOT NULL,
    blockchain VARCHAR(32) NOT NULL,
    amount NUMERIC(36, 18) NOT NULL CHECK (amount > 0),
    balance_after NUMERIC(36, 18) NOT NULL,
    reference_type VARCHAR(32),
    reference_id UUID,
    tx_hash VARCHAR(66),
    block_number BIGINT,
    created_at TIMESTAMPTZ DEFAULT NOW() NOT NULL,
    created_by VARCHAR(64) NOT NULL,
    CONSTRAINT no_negative_balance CHECK (balance_after >= 0)
);

Reconciliation — ежедневная сверка on-chain балансов с записями в ledger. Если расхождение превышает допустимый порог (0.1% от общего баланса), система отправляет alert.

Мониторинг входящих депозитов

Система отслеживает все входящие транзакции на адреса клиентов через WebSocket-подписку на новые блоки. Для ERC-20 отслеживаются Transfer события. После подтверждения (12-20 блоков) средства зачисляются в ledger. Обрабатываем до 10 000 депозитов в час на один blockchain.

Вывод средств

Вывод требует multi-approval workflow. После одобрения: проверка баланса, резервирование, подпись в HSM, broadcast, ожидание подтверждения (6-12 блоков), финальное списание. Каждый запрос имеет уникальный idempotency key — повтор с тем же ключом не создаёт новый вывод.

Как реализовать Proof of Reserves?

Для публичного подтверждения платёжеспособности строим Merkle tree на основе client balances:

async function generateProofOfReserves(): Promise<ProofOfReserves> {
  const balances = await db.getAllClientBalances();
  const leaves = balances.map(b => 
    keccak256(encode(['address', 'uint256'], [b.address, b.balance]))
  );
  const tree = new MerkleTree(leaves, keccak256, { sort: true });
  await proofOfReservesContract.updateRoot(tree.getRoot());
  return {
    root: tree.getRoot(),
    totalBalance: balances.reduce((sum, b) => sum + b.balance, 0n),
    timestamp: Date.now(),
    proofs: balances.map((b, i) => ({
      clientId: b.clientId,
      proof: tree.getProof(leaves[i]),
    })),
  };
}

Каждый клиент получает доказательство включения своего баланса в дерево без раскрытия данных других клиентов. Корень публикуется on-chain, что позволяет проводить независимый аудит. Гарантируем проходимость аудита в 99.9% случаев.

Compliance, аудит и отчётность

Аудит trail — все операции с неизменяемой историей. Логи хранятся в append-only хранилище (PostgreSQL с audit triggers или AWS QLDB). Ежемесячные отчёты для клиентов, ежеквартальные для аудиторов: reconciliation reports, proof of reserves.

KYT (Know Your Transaction) — интеграция с Chainalysis Reactor API для проверки входящих транзакций на связь с санкционными адресами и mixer-ами. Это обязательное требование для прохождения compliance-проверок.

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

1. Архитектурная документация (HLD, LLD, ER-диаграммы)
2. Исходный код системы (ledger, мониторинг, API, администрирование)
3. HSM-конфигурации и политики доступа
4. CI/CD пайплайны (GitHub Actions + Docker)
5. Тесты безопасности (penetration testing, smart contract audit)
6. Обучение команды (2 недели)
7. Поддержка 3 месяца после запуска

Стек технологий

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

• Core ledger + address management: 6–8 недель
• Deposit monitoring + withdrawal flow: 4–6 недель
• Reconciliation + proof of reserves: 3–4 недели
• KYT интеграция + compliance reporting: 3–4 недели
• Security audit: обязателен, 4–8 недель

Оценим ваш проект за 2 дня. Свяжитесь с нами для консультации. Гарантируем соответствие требованиям регуляторов и безопасность на каждом этапе.

Мы разрабатываем криптокошельки под ключ — от 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 месяц

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

Стоимость рассчитывается индивидуально под ваш проект. Оценим за 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.

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