Розробка системи non-custodial стейкінгу

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Розробка системи non-custodial стейкінгу
Складний
від 1 тижня до 3 місяців
Часті запитання

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

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

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1285
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1198
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    902
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1120
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    588
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    854

Розробка системи non-custodial стейкингу

Non-custodial стейкинг — це стейкинг де користувач зберігає повний контроль над своїми ключами. Провайдер забезпечує інфраструктуру, але не може розпоряджатися активами користувача без його участі. Це принципова різниця від кастодіальних сервісів (Coinbase Earn, Binance Staking) де біржа тримає ключи.

Технічна реалізація non-custody

Ethereum native staking (non-custodial)

Користувач генерує ключи сам, провайдер запускає ноду:

  1. Користувач генерує BLS signing key (offline, air-gapped)
  2. Користувач робить deposit в Ethereum deposit contract своїми withdrawal credentials
  3. Провайдер отримує лише signing key для запуску ноди
  4. Withdrawal credentials залишаються у користувача → провайдер не може вивести ETH

Проблема: користувач має генерувати ключи сам. Технічно складно для non-technical users. Wagyu Key Gen (GUI інструмент) спрощує процес.

DVT-based non-custodial

Distributed Validator Technology (Obol, SSV Network) дозволяє розділити signing key між кількома операторами. Жоден оператор не володіє повним ключем. Це одночасно non-custodial (ніхто не може одноосібно вивести кошти) і fault-tolerant (один оператор offline — валідатор працює).

Ключ валідатора користувача → розділ через DKG ceremony
    ├── Key share 1 → Operator A
    ├── Key share 2 → Operator B  
    ├── Key share 3 → Operator C
    └── Key share 4 → Operator D

3-of-4 threshold для підписання

Smart contract-based non-custodial

Для liquid staking non-custodial модель складніша. EtherFi реалізує це через:

  • Користувач створює SafeEth NFT що представляє його validator ownership
  • Withdrawal credentials = адреса користувацького EigenPod або контракту
  • Провайдер управляє операційно, але не може вивести ETH без взаємодії з контрактом

Ключові компоненти системи

Key generation ceremony: процес що користувач проходить для створення ключів. UI має бути максимально простим, але безпечним. Offline key generation — ідеал.

Distributed Key Generation (DKG) для DVT: якщо використовувати Obol або SSV:

  • Оператори збираються для DKG ceremony
  • Кожен отримує key share
  • Ніхто не бачив повного ключа

Управління адресою вивіду: користувач повинен розуміти важливість withdrawal credentials. Якщо втрачено — ETH втрачено назавжди (або до validator exit).

Transparency dashboard: користувач бачить on-chain статус свого валідатора напрямку. Посилання на beaconcha.in по публічному ключу.

Виклики UX

Non-custodial стейкинг технічно правильний, але UX гірше:

  • Користувач несе відповідальність за backup ключів
  • Генерація ключів вимагає розуміння процесу
  • Відновлення при втраті ключів обмежено

Рішення:

  • Керований onboarding: покрокові інструкції з поясненням кожного кроку
  • Верифікація backup ключів: перевірка що користувач дійсно зберіг backup
  • Інтеграція hardware wallet: Ledger/Trezor для зберігання withdrawal credentials

Non-custodial стейкинг — правильний вибір для технічно грамотних користувачів і institutional клієнтів що вимагають segregated custody.