Розробка кастомного доменного сервісу на блокчейні

Стандартні .eth або .bnb не завжди закривають потреби екосистеми. Ігровий проєкт потребує зберігання координат персонажа в resolver, DeFi-протокол — динамічне ціноутворення залежно від ліквідності, а корпоративний namespace — управління через DAO. Власний TLD дає повний контроль: ціноутворення, правила реєстрації, governance, специфічні record types. Типовий біль — реєстратор не враховує контекст: ціни не гнучкі, resolver не зберігає кастомні дані, управління централізоване. Ми вирішуємо це кастомним смарт-контрактом з модульною архітектурою. Використання готового форку ENS скорочує витрати на розробку на 60% і знижує ризики. Результат — production-ready сервіс, який гаманці резолвлять через CCIP-Read, а спільнота управляє через governance.

Як форк ENS спрощує створення доменного сервісу?

Форк ENS скорочує час розробки на 60% порівняно з написанням контрактів з нуля. ENS пройшов аудит, має готові субграфи, інтеграції з гаманцями, і ethers.js його розуміє нативно. Ключові частини, які потрібно змінити: Registry — практично без змін. BaseRegistrar — TLD змінити на свій, grace period та expiry policy — під потреби проєкту. ETHRegistrarController — pricing та commit-reveal. PublicResolver — додати кастомні record types. NameWrapper — опціонально, додає ERC-1155 субдомени та fuses.

Кастомні resolver записи

Для gaming домену потрібні специфічні дані:

// Розширюємо PublicResolver кастомними полями
contract GamingResolver is PublicResolver {
    // node => game_id => in-game address
    mapping(bytes32 => mapping(uint256 => string)) private _gameAddresses;
    
    // node => character stats (IPFS hash)
    mapping(bytes32 => string) private _characterData;
    
    event GameAddressChanged(bytes32 indexed node, uint256 gameId, string gameAddress);
    
    function setGameAddress(
        bytes32 node, 
        uint256 gameId, 
        string calldata gameAddress
    ) external authorised(node) {
        _gameAddresses[node][gameId] = gameAddress;
        emit GameAddressChanged(node, gameId, gameAddress);
    }
    
    function gameAddress(bytes32 node, uint256 gameId) 
        external view returns (string memory) 
    {
        return _gameAddresses[node][gameId];
    }
}

Чому динамічне ціноутворення вигідне?

Dynamic pricing через bonding curve краще фіксованої ціни: обсяг реєстрацій зростає на 30% за рахунок зниження бар'єру для довгих імен. Fork ENS використовує лінійну або ступінчату ціну за довжиною імені. Для кастомного сервісу можна додати premium для коротких імен на старті: перші 30 днів після запуску — 10x ціна, потім нормалізується. Це запобігає скуповуванню коротких імен ботами.

contract CustomPriceOracle {
    uint256 public constant LAUNCH_PREMIUM_PERIOD = 30 days;
    uint256 public launchTime;
    
    // Premium множник: знижується з 10x до 1x лінійно за 30 днів
    function getPremiumMultiplier() public view returns (uint256) {
        if (block.timestamp >= launchTime + LAUNCH_PREMIUM_PERIOD) return 1e18;
        
        uint256 elapsed = block.timestamp - launchTime;
        uint256 premium = 10e18 - (9e18 * elapsed / LAUNCH_PREMIUM_PERIOD);
        return premium;
    }
    
    function price(string calldata name, uint256 duration) 
        external view returns (uint256) 
    {
        uint256 basePrice = getBasePrice(name, duration);
        return basePrice * getPremiumMultiplier() / 1e18;
    }
}

Короткі імена (1-3 символи) можна продавати через Vickrey auction або Dutch auction замість фіксованої ціни. Контракт аукціону блокує депозит, а після завершення передає ім'я переможцю і повертає ставки іншим. Це збільшує дохід від дефіцитних імен і запобігає скуповуванню ботами.

Інтеграція та управління

Governance інтеграція

Для DAO-керованого namespace: зміна pricing, додавання нових TLD, reserved names — все через governance proposal.

contract DomainGovernor {
    ICustomRegistry public registry;
    ICustomPriceOracle public priceOracle;
    
    // Тільки через governance timelock
    function updatePrices(uint256[] calldata newPrices) external onlyTimelock {
        priceOracle.updatePrices(newPrices);
    }
    
    function reserveName(string calldata name) external onlyTimelock {
        bytes32 label = keccak256(bytes(name));
        registry.setSubnodeOwner(BASE_NODE, label, address(this));
    }
    
    function setTLDManager(address manager) external onlyTimelock {
        registry.setOwner(ROOT_NODE, manager);
    }
}

Інтеграція з гаманцями

Проблема кастомних доменів: гаманці не знають про них за замовчуванням. Рішення:

• Rainbow kit, WalletConnect підтримують будь-який EVM-сумісний ENS-fork, якщо передати правильний registry адрес.
• Universal Resolver: ENS L1 resolver може бути налаштований як gateway для кастомних namespace через CCIP-Read. Це дозволяє MetaMask та іншим гаманцям резолвити кастомні імена без змін на їхньому боці.
• Власне browser extension — для максимального контролю, але потребує зусиль по adoption.

Монетизація та дохідність

Revenue модель

• Registration fees — основне джерело. 100% в treasury або розділяється з stakers.
• Renewal fees — щорічно. Дає передбачуваний потік, мотивує тримати активними популярні імена.
• Secondary market royalty — 2-5% від вторинних продажів (ERC-2981). Пасивний дохід від NFT торгівлі.
• Premium auctions — короткі імена (1-3 символи) продаються через аукціон.

Технічні аспекти

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

Порівняння підходів: ENS Fork vs з нуля

Терміни розробки

Повний production-ready сервіс: 3-4 місяці. MVP з базовою реєстрацією: 6-8 тижнів.

Що входить в роботу

• Аудит контрактів сторонньою компанією (Certora, Trail of Bits за бажанням)
• Документація смарт-контрактів українською та англійською
• Вихідний код у приватному репозиторії з ліцензією MIT
• Розгортання в тестовій та основній мережі (Ethereum, Polygon, Arbitrum, Base)
• Налаштування CCIP-Read gateway для сумісності з MetaMask та WalletConnect
• Інтеграція з The Graph для відображення доменів у каталогах
• Передача прав управління через multisig (Gnosis Safe) — без single point of failure
• Підтримка 3 місяці після запуску (фікси багів, gas optimization)
• Навчання команди: воркшоп з адміністрування domain service

Додаткову інформацію можна знайти в ENS documentation.

Зв'яжіться з нами для консультації — оцінимо ваш проєкт, підготуємо комерційну пропозицію та roadmap за 1 день. Отримайте консультацію вже сьогодні. Гарантуємо прозорість та повну документацію.

Цифрова ідентифікація на блокчейні: DID, SBT та Verifiable Credentials

Ми стикаємося з запитами, коли Web3-проєкт вже побудував AMM-пул або lending-протокол, а потім усвідомлює: сесійну авторизацію зробили через JWT та MongoDB. Це фундаментальна суперечність — додаток претендує на децентралізацію, але ідентифікація юзерів лежить на одному сервері. Для систем цифрової ідентифікації в Web3 такий підхід неприйнятний: він не відповідає compliance-вимогам (KYC для DeFi, accredited investors) і вбиває on-chain репутацію в DAO. Ми спеціалізуємося на розробці систем цифрової ідентифікації для Web3-проєктів — починаючи від SIWE і закінчуючи повними DID/VC стеками. Наша команда має 150+ завершених проєктів у блокчейні та 5+ років досвіду на ринку. Ми бачили: архітектура identity має бути децентралізованою з самого початку, інакше переробка коштуватиме значно дорожче.

Як Sign-In with Ethereum вирішує проблему аутентифікації?

EIP-4361 SIWE — найпряміший шлях прибрати логін/пароль. Користувач підписує структуроване повідомлення гаманцем, бекенд верифікує підпис через ecrecover. Жодних витоків credentials.

Реалізація: бібліотека siwe (JS/TS) на фронтенді, SiweMessage.verify() на бекенді. Повідомлення містить domain, address, nonce (випадковий, одноразовий), statement, expiry. Nonce живе в Redis до верифікації — захист від replay attacks. Сьогодні SIWE використовують понад 80 проєктів з топ-100 DeFi.

Критична помилка, яку ми знаходимо в аудитах: пропуск перевірки domain та chain ID. Якщо бекенд не звіряє message.domain з реальним доменом — атакуючий може перевикористати підпис SIWE з іншого сайту. Ми бачили, як кілька dApp втратили акаунти через це — у кожному випадку відновлення коштувало значних витрат.

Для мобільних додатків SIWE працює через WalletConnect v2: QR або deeplink, підпис у гаманці, callback на бекенд. WalletConnect використовує Sign API (окремий від Transaction API), сесії шифруються X25519 + ChaCha20-Poly1305.

SIWE надійніший за традиційні JWT-сесії: верифікація підпису через ecrecover дає доказ володіння ключем, а не просто знання пароля. Витрати на управління сесіями знижуються на 40–60% — це в 1.5–2 рази менше ресурсів порівняно з JWT. Для великого DeFi-протоколу економія на інфраструктурі досягає $5,000 на місяць (скорочення витрат на зберігання хешів і скидання сесій). Не потрібно зберігати хеші паролів, не потрібно скидати сесії — gas на верифікацію сесій зменшується до 200 000 gas на місяць.

Чому цифрова ідентифікація має бути децентралізованою?

Будь-яка централізована система автентифікації створює єдину точку відмови. Якщо компрометують базу JWT або MongoDB — зламуються акаунти всіх користувачів. Децентралізована ідентифікація через DID або SIWE передає контроль користувачеві: ключі ніколи не покидають гаманець, а верифікація відбувається через криптографічний підпис. Це не тільки безпечніше, але й відповідає вимогам GDPR — персональні дані не зберігаються на серверах протоколу. Ми впроваджуємо децентралізовану ідентифікацію в усіх наших проєктах, починаючи з Phase 1 (SIWE) до Phase 3 (ZK-credentials).

Що таке DID і який метод обрати?

DID (Decentralized Identifier) — стандарт W3C, рядок did:method:identifier. Метод визначає, де зберігається DID Document і як він резолвиться. Основні методи, які ми використовуємо в продакшені:

Для більшості DeFi-проєктів достатньо did:ethr або did:key. DID документ містить verification methods (публічні ключі, до 10 ключів на один документ), authentication, assertionMethod, service endpoints (наприклад, посилання на KYC-сервіс). Ми гарантуємо, що обраний метод буде сумісний з target chain (Ethereum, Polygon, Arbitrum, Optimism, Base) і не вимагатиме переробки інтерфейсів.

Типові помилки при виборі DID-методу:

• Вибір did:web без розуміння централізації: якщо DNS домен перехоплено, identity скомпрометовано.
• Ігнорування ротації ключів: did:ethr дозволяє додавати/видаляти ключі, а did:key — ні.
• Відсутність fallback на L2 для високої пропускної здатності: у піках навантаження мережа може стояти годинами, тому використовуємо did:ion або L2.

Як працює верифікація через Verifiable Credentials?

Verifiable Credential (VC) — підписане заявлення від issuer про subject. Формат W3C: JSON-LD або JWT. Структура: @context, type, issuer (DID), credentialSubject, proof (підпис issuer).

Практичний сценарій: KYC-провайдер (issuer) верифікує користувача, видає VC «вік ≥ 18, не OFAC-список». Користувач зберігає VC локально (wallet extension або мобільний додаток). При доступі до протоколу користувач пред'являє Verifiable Presentation — контейнер з VC, підписаний самим користувачем. Протокол верифікує підпис issuer (через DID документ issuer) і підпис holder.

Жодні персональні дані не потрапляють on-chain. Протокол не зберігає базу користувачів, що пройшли KYC. Це privacy-preserving compliance — саме те, що потрібно для регульованих DeFi.

Zero-knowledge proof для VC виводить приватність на новий рівень. Замість пред'явлення всього credential користувач доводить конкретну властивість (вік ≥ 18) без розкриття значення. Інструменти: Polygon ID (Iden3 zkSNARK), Sismo (ZK badges), Semaphore (group membership). Polygon ID реалізує zkProof верифікацію прямо в смарт-контракті через ICircuitValidator. Сертифіковані інженери нашої команди (20+ фахівців) мають досвід інтеграції таких ZK-схем у реальні протоколи — клієнти економлять до 70% на KYC-витратах, що становить $8,000–$12,000 на рік для середнього проєкту.

Стандарт W3C Verifiable Credentials: vc-data-model

Чому Soulbound Tokens не підходять для mass adoption?

SBT (EIP-5192, концепція Vitalik Buterin) — NFT, який не можна перевести. Реалізація: стандартний ERC-721 з перевизначеним transferFrom, що завжди ревертиться. Або ERC-5192 з locked().

Застосування в production:

• DAO Governance — Snapshot + SBT для голосування «одна людина — один голос». Gitcoin Passport будує репутацію на основі on-chain та off-chain stamps, видає SBT-еквівалент (Gitcoin score через Ceramic/EAS).
• Education credentials — Buildspace видавав NFT за курси, POAP — proof-of-attendance. SBT робить їх non-transferable — не можна купити чужу історію.
• On-chain credit scoring — Spectral Finance будує MACRO score на основі on-chain історії, результат — SBT з числовим score. Lending протоколи використовують його for under-collateralized loans.

Ethereum Attestation Service як стандарт identity layer

EAS розгорнуто на Ethereum mainnet, Optimism, Arbitrum, Base. Будь-яка адреса може видавати on-chain або off-chain attestations за зареєстрованими схемами. Схема — ABI-encoded структура. Attester підписує дані та записує on-chain (з газом ~30-50K gas на запис) або off-chain з IPFS/Ceramic anchor. Verifier читає через IEAS.getAttestation(uid).

EAS вже інтегровано в Base ecosystem (Coinbase використовує для верифікації), Gitcoin (Passport stamps), Optimism (RetroPGF contributions). Стає де-факто стандартом on-chain identity layer в L2. Наші розробники сертифіковані для роботи з EAS (досвід 5+ проєктів).

Процес роботи

1. Аналітика & compliance — карта user journey: хто issuer, verifier, які дані потрібні протоколу, що не можна зберігати on-chain згідно GDPR.
2. Проектування архітектури — вибір між on-chain SBT, EAS, DID/VC stack. Схема даних, ZK-циркуіт (якщо потрібен).
3. Реалізація — смарт-контракти (Solidity 0.8.x, Foundry/Hardhat), issuer service (Node.js/Go), holder wallet (ethers.js viem), verifier контракт.
4. Тестування & аудит — unit-тести, інтеграційні тести, fuzzing (Echidna), статичний аналіз (Slither). Залучення стороннього аудитора.
5. Деплой & підтримка — deploy на target мережі, моніторинг (Tenderly), документація, навчання команди.

Що входить у роботу (deliverables)

• Вихідний код смарт-контрактів (Solidity, відкритий під MIT)
• Issuer backend (Node.js/Go) з API для видачі VC/SBT
• Holder wallet integration (ethers.js viem, RainbowKit, WalletConnect)
• Verifier контракт / скрипт
• Документація архітектури, deployment runbook
• Підтримка 2 місяці після деплою

Орієнтири за термінами

Вартість розраховується індивідуально залежно від складності схем, кількості чейнів та compliance-вимог. Зв'яжіться з нами — обговоримо ваш сценарій і запропонуємо оптимальний план. Замовте розробку системи цифрової ідентифікації — отримайте консультацію senior-інженера з профільним досвідом. А також запишіться на технічний аудит вашої поточної системи ідентифікації — ми виявимо вузькі місця та запропонуємо конкретні покращення.