Розробка системи non-custodial стейкингу
Non-custodial стейкинг — це стейкинг де користувач зберігає повний контроль над своїми ключами. Провайдер забезпечує інфраструктуру, але не може розпоряджатися активами користувача без його участі. Це принципова різниця від кастодіальних сервісів (Coinbase Earn, Binance Staking) де біржа тримає ключи.
Технічна реалізація non-custody
Ethereum native staking (non-custodial)
Користувач генерує ключи сам, провайдер запускає ноду:
- Користувач генерує BLS signing key (offline, air-gapped)
- Користувач робить deposit в Ethereum deposit contract своїми withdrawal credentials
- Провайдер отримує лише signing key для запуску ноди
- 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 реалізує це через:
- Користувач створює
SafeEthNFT що представляє його 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.







