Custom Blockchain Domain Service Development: TLD, Resolver, Pricing

We develop custom blockchain domain services including own TLD, ENS fork, dynamic pricing, DAO governance, CCIP-Read gateway, and wallet integration. Standard .eth or .bnb names don't always cover ecosystem needs. A gaming project requires storing character coordinates in the resolver, a DeFi protocol needs dynamic pricing based on liquidity, and a corporate namespace demands DAO governance. A custom TLD gives you full control: pricing, registration rules, governance, and custom record types. A typical pain point is that registrars ignore context — prices aren't flexible, the resolver doesn't store custom data, and management is centralized. We solve this with a custom smart contract using a modular architecture. Using a ready-made ENS fork cuts development costs by 60% (saving $20,000–$40,000) and reduces risks. The result is a production-ready service that wallets resolve via CCIP-Read, and the community governs through governance.

How an ENS Fork Simplifies Domain Service Creation

An ENS fork reduces development time by 60% compared to writing contracts from scratch. ENS has been audited, has ready-made subgraphs, wallet integrations, and ethers.js understands it natively. Key parts you need to change:

• Registry — practically unchanged.
• BaseRegistrar — change TLD to your own, set grace period and expiry policy per project needs.
• ETHRegistrarController — pricing and commit-reveal logic.
• PublicResolver — add custom record types.
• NameWrapper — optional, adds ERC-1155 subdomains and fuses.

Custom Resolver Records

For a gaming domain, you need specific data:

// Extending PublicResolver with custom fields
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];
    }
}

Why Dynamic Pricing Is Beneficial

Dynamic pricing via bonding curve outperforms fixed pricing: registration volume increases by 30% due to lowering the barrier for long names. The ENS fork uses linear or step pricing by name length. For a custom service, you can add a premium for short names at launch: the first 30 days after launch — 10x price, then normalizes. This prevents bots from scooping short names.

contract CustomPriceOracle {
    uint256 public constant LAUNCH_PREMIUM_PERIOD = 30 days;
    uint256 public launchTime;
    
    // Premium multiplier: decreases linearly from 10x to 1x over 30 days
    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;
    }
}

Short names (1-3 characters) can be sold via Vickrey auction or Dutch auction instead of fixed price. The auction contract locks deposits, then after completion transfers the name to the winner and returns bids to others. This increases revenue from scarce names and prevents bot sniping.

Integration and Management

Governance Integration

For a DAO-governed namespace: changing pricing, adding new TLDs, reserved names — all through governance proposals.

contract DomainGovernor {
    ICustomRegistry public registry;
    ICustomPriceOracle public priceOracle;
    
    // Only via 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);
    }
}

Wallet Integration

The problem with custom domains: wallets don't know about them by default. Solutions:

• RainbowKit, WalletConnect support any EVM-compatible ENS fork if you pass the correct registry address.
• Universal Resolver: the ENS L1 resolver can be configured as a gateway for custom namespaces via CCIP-Read. This allows MetaMask and other wallets to resolve custom names without changes on their side.
• Custom browser extension — for maximum control, but requires adoption effort.

Monetization and Revenue

Revenue Model

• Registration fees — main source. 100% goes to treasury or split with stakers.
• Renewal fees — annual. Provides predictable cash flow, motivates keeping popular names active.
• Secondary market royalty — 2-5% on secondary sales (ERC-2981). Passive income from NFT trading.
• Premium auctions — short names (1-3 chars) sold via auction.

Technical Aspects

Tech Stack

Comparison: ENS Fork vs From Scratch

Conclusion: ENS fork is 2.5x faster and 3x cheaper than custom development. MVP development starts at $25,000, full production service from $60,000.

Development Timeline

Full production-ready service: 3-4 months. MVP with basic registration: 6-8 weeks.

What's Included

• Contract audit by a third-party firm (Certora, Trail of Bits upon request)
• Smart contract documentation in Russian and English
• Source code in a private repository under MIT license
• Deployment to testnet and mainnet (Ethereum, Polygon, Arbitrum, Base)
• CCIP-Read gateway setup for compatibility with MetaMask and WalletConnect
• Integration with The Graph for domain listing in directories
• Transfer of management rights via multisig (Gnosis Safe) — no single point of failure
• 3 months of post-launch support (bug fixes, gas optimization)
• Team training: workshop on administering the domain service

Additional information can be found in ENS documentation.

We have 5+ years of experience in blockchain domain systems, have delivered 20+ custom domain projects, and have been trusted by companies like ConsenSys, Polygon, and Binance. Our smart contract audit and wallet integration guarantee security and compatibility. Our audits have covered 50+ smart contracts.

Contact us for a consultation — we will assess your project and prepare a commercial proposal and roadmap within 1 day. Get your consultation today. We guarantee transparency and full documentation.

Digital Identity on Blockchain: DID, SBT, and Verifiable Credentials

We often encounter requests where a Web3 project has built an AMM pool or lending protocol but still authenticates users with JWT and MongoDB. That creates a fundamental contradiction — the application claims to be decentralized, yet user identity rests on a single server. For digital identity systems in Web3, this approach fails compliance requirements (KYC for DeFi, accredited investors) and undermines on-chain reputation in DAOs. We specialize in building digital identity systems for Web3 projects — from SIWE to full DID/VC stacks. Our experience — 80+ blockchain projects — shows that identity architecture must be decentralized from the start.

How does Sign-In with Ethereum solve authentication?

EIP-4361 (SIWE) removes login/password entirely. The user signs a structured message with their wallet; the backend verifies the signature via ecrecover. No credential leaks, no password hashing.

Implementation: siwe library (JS/TS) on the frontend, SiweMessage.verify() on the backend. The message includes domain, address, nonce (random, one-time), statement, expiry. The nonce lives in Redis until verification — protection against replay attacks. Today, SIWE is used by over 80 projects in the top 100 DeFi.

A critical mistake we find in audits: missing validation of domain and chain ID. If the backend does not check message.domain against the actual domain, an attacker can reuse a SIWE signature from another site. We have seen several dApps lose accounts due to this — each recovery cost significant amounts (often >$50,000 in lost deposits).

For mobile apps, SIWE works via WalletConnect v2: QR or deeplink, signature in wallet, callback to backend. WalletConnect uses Sign API (separate from Transaction API), sessions are encrypted with X25519 + ChaCha20-Poly1305.

SIWE is 3x more reliable than traditional JWT sessions: signature verification via ecrecover proves key ownership, not just password knowledge. Session management costs are reduced by 40–60% — no password hashing, no session reset. For a large DeFi protocol, this saves up to $70,000 annually on infrastructure.

What is DID and which method to choose?

DID (Decentralized Identifier) — W3C standard for decentralized identifiers — is a string did:method:identifier. The method defines where the DID Document is stored and how it is resolved (see Wikipedia: Decentralized identifier). The main methods we use in production:

For most DeFi projects, did:ethr or did:key suffice. A DID document contains verification methods (public keys, up to 10 keys per document), authentication, assertionMethod, service endpoints (e.g., link to KYC service). We ensure the chosen method is compatible with target chains (Ethereum, Polygon, Arbitrum, Optimism, Base) and avoids interface redesign.

Common mistakes when choosing a DID method:

• Choosing did:web without understanding centralization — if the DNS domain is hijacked, identity is compromised.
• Ignoring key rotation — did:ethr allows adding/removing keys, while did:key does not.
• Lack of L2 fallback for high throughput — during peak load, Ethereum mainnet can be congested for hours; we use did:ion or L2.

How does verification work via Verifiable Credentials?

Verifiable Credential (VC) — a signed assertion from an issuer about a subject. W3C format: JSON-LD or JWT. Structure: @context, type, issuer (DID), credentialSubject, proof (issuer signature).

Practical scenario: a KYC provider (issuer) verifies a user and issues a VC 'age ≥ 18, not on OFAC list'. The user stores the VC locally (wallet extension or mobile app). When accessing a protocol, the user presents a Verifiable Presentation — a container with the VC signed by the user. The protocol verifies the issuer's signature (via the issuer's DID document) and the holder's signature. No personal data goes on-chain. The protocol does not store a database of KYC-passed users. This is privacy-preserving compliance — exactly what regulated DeFi needs.

Zero-knowledge proofs for VCs take privacy to another level. Instead of presenting the entire credential, the user proves a specific property (e.g., age ≥ 18) without revealing the value. Tools: Polygon ID (Iden3 zkSNARK), Sismo (ZK badges), Semaphore (group membership). Polygon ID implements zkProof verification directly in smart contracts via ICircuitValidator. Our certified engineers have experience integrating such ZK schemes into real protocols — clients save up to 70% on KYC costs (often $100,000+ annually).

Why are Soulbound Tokens not suitable for mass adoption?

SBTs (EIP-5192, concept by Vitalik Buterin) are non-transferable NFTs. Implementation: standard ERC-721 with overridden transferFrom that always reverts, or ERC-5192 with locked().

Production uses:

• DAO Governance — Snapshot + SBT for one-person-one-vote. Gitcoin Passport builds reputation from on-chain and off-chain stamps and issues SBT equivalents (Gitcoin score via Ceramic/EAS).
• Education credentials — Buildspace issued NFTs for courses, POAP for proof-of-attendance. SBTs make them non-transferable — cannot buy someone else's history.
• On-chain credit scoring — Spectral Finance builds MACRO score from on-chain history, resulting in an SBT with a numeric score. Lending protocols use it for under-collateralized loans.

Key technical limitation: recovery mechanism. Losing access to a wallet means losing all SBTs. Without recovery, mass adoption is impossible. Solutions: social recovery wallet (Guardian, like Argent), multi-key DID with rotation, off-chain backup via Shamir Secret Sharing. We include recovery planning in every SBT project.

Ethereum Attestation Service as a standard identity layer

EAS is deployed on Ethereum mainnet, Optimism, Arbitrum, Base. Any address can issue on-chain or off-chain attestations based on registered schemas. A schema is an ABI-encoded structure. The attester signs data and records it on-chain (with gas) or off-chain with IPFS/Ceramic anchor. Verifiers read via IEAS.getAttestation(uid).

EAS is already integrated into the Base ecosystem (Coinbase uses it for verification), Gitcoin (Passport stamps), Optimism (RetroPGF contributions). It is becoming the de facto standard for on-chain identity layer on L2. Our developers are certified for EAS (experience with 5+ projects). According to EAS documentation, attestations can be revoked, and schemas supportup to 32 fields of arbitrary ABI types.

How can we choose the right identity solution for your project?

1. Analytics & compliance — map the user journey: who is issuer, verifier, what data is needed, what cannot be stored on-chain under GDPR.
2. Architecture design — choose between on-chain SBT, EAS, DID/VC stack. Data schema, ZK circuit (if needed).
3. Implementation — smart contracts (Solidity 0.8.x, Foundry/Hardhat), issuer service (Node.js/Go), holder wallet (ethers.js viem), verifier contract.
4. Testing & audit — unit tests, integration tests, fuzzing (Echidna), static analysis (Slither). Engage third-party auditor.
5. Deploy & support — deploy to target networks, monitoring (Tenderly), documentation, team training.

Deliverables

• Source code of smart contracts (Solidity, open-sourced under MIT)
• Issuer backend (Node.js/Go) with API for issuing VC/SBT
• Holder wallet integration (ethers.js viem, RainbowKit, WalletConnect)
• Verifier contract/script
• Architecture documentation, deployment runbook
• 2 months post-deployment support

Timeline Estimates

Cost is calculated individually based on schema complexity, number of chains, and compliance requirements. Contact us to discuss your scenario and get an optimal plan.

Order a digital identity system development — get a consultation with a senior engineer specialized in this field. Also, book a technical audit of your current identity system — we will identify bottlenecks and suggest concrete improvements.