This guide walks you through every step of the whitelist minting process on dotHYPE.

What you'll Need

Before you begin, make sure you’ve got:

• A wallet (like MetaMask, Rabby, or Frame)

• Some $HYPE on HyperEVM (You'll use $HYPE to pay for your name based on USD-pegged pricing)

• A name in mind (Availability will be checked during the process)

Step-by-Step: How to Mint a Name

Now that you have your .hype name, see what you can do today

🔍 Reverse Resolution

At launch, .hype lets you choose how much (or how little) you want to share. Whether you're privacy-focused and just want a human-readable name for receiving funds, or you're building a full public identity with links, metadata, and delegation - you control what’s visible, meaningful, and connected.

Each feature you use becomes part of a larger identity graph over time to enhance discoverability, coordination, and trust - when you choose to lean into it.

✅ Replace Your 0x Address with a Name

Long wallet addresses are unreadable and impersonal. Sharing them feels cold—and checking them is error-prone. With .hype, your wallet becomes human:

• Instead of 0x1f7a…e4A9, you send and receive using <yourname>.hype

• You can reference people by name in leaderboards and dashboards if the dApp has integrated .hype resolution

“Where does this work?” If a HyperEVM dApp supports .hype resolution, your .hype name resolves automatically.

🔍 Example: A HyperEVM explorer or DeFistaking dashboard that uses .hype resolution will display your .hype name natively instead of your wallet address.

🎨 Customize Your Identity Metadata

“Why would I care about metadata?” Think of it like filling in your profile on LinkedIn or GitHub. Except this profile is onchain - portable, provable, and composable:

• Add a Twitter handle, GitHub link, or bio

• Set an avatar image that becomes your identity across apps

• Attach a website or project link that makes it easier to find or trust you

“Why does this matter now?” Even if there aren’t rich profile pages at launch, you’re creating a discoverable surface for integrations and tools down the line. It’s your identity seed.

🔗 Delegate Control Across Wallets

“Why split name and wallet?” Most people use different wallets for different things - cold storage, trading, DAO voting, etc. dotHYPE lets you:

• Assign your .hype name to a secondary wallet for safety

• Represent a DAO, multi-sig, or protocol with one name, while operations happen from different addresses

“What does that unlock?” This is key for teams, devs, and pseudonymous users. You stay consistent without tying everything to one key.

Coming Soon in Phase 2:

• .hype-aware partner dApps

• Enhanced Metadata Custimization

• Community leaderboard for early holders

• Embedded .hype lookups in HyperEVM dashboards

In Web3, we’ve built protocols for speed, liquidity, and composability - but identity is still stuck in the past. Wallets remain anonymous strings. Roles are implied, not declared. And on-chain coordination still lacks a shared, human-readable interface.

dotHYPE changes that. It’s starts with the naming service and evolves into a foundational infrastructure for how users, protocols, and agents identify and interact on HyperEVM.

Every .hype name is a container: structured to evolve, personalize, and coordinate.

This isn’t strictly just about making addresses human-readable.

It’s about making systems human-comprehensible.

dotHYPE gives you a .hype name that is:

• ✅ Human-readable (like you.hype)

• ✅ Fully on-chain and ENS-compatible

• ✅ Permissionless to mint

• ✅ Modular and programmable for expansion

Designed for today and tomorrow.

• In a modular blockchain like HyperEVM, coordination happens across many contracts, dashboards, and UIs.

• dotHYPE helps tie these elements together into one readable identity.

This quickstart will help you:

1. Claim your name

2. Use it in real ways

3. Understand where the product is heading

Let’s get started.

What is dotHYPE?

dotHYPE transforms names into modular, programmable identity containers built for the HyperEVM era. Whether you’re here to claim your first .hype name, integrate identity into your dApp, or explore the architecture behind it all, we’ve designed dotHYPE to meet you where you are clear, composable, and future-ready. It starts with naming, then becomes identity infrastructure.

Begin your dotHYPE journey based on your intent:

🔰New to dotHYPE? → Quickstart Guide

🔧Building or integrating? → Builder Toolkit

🤿Curious about how it works? → Explore the Architecture

🔧 Inside our first-principles thinking → Explore the philosophy behind dotHYPE

📚Explore Our Guides

Navigate our system based on what you want to do - whether you're just getting started or building something new..

Add HyperEVM to Your Wallet

To interact with apps and assets on HyperEVM, you’ll first need to add it to your wallet (e.g. MetaMask).

Easiest Option: Use - one click, and you’re in.

Manual Setup: Go to your wallet > “Add Network” or “Custom RPC” and enter:

• Network Name: Hyperliquid

• Chain ID: 999; any other number will land to testnet

• RPC URL:

• Currency Symbol: HYPE

• Block Explorers (optional):

  • (preferred)

As we grow, we’re focused on building structured identity, where your name is not only an address, but also reflection of your role, reputation, and connections across the ecosystem. These are all things you can choose to opt-into as we develop the identity focused infrastructure to make your HyperEVM more seamless and secure.

We’re ultimately expanding .hype into powerful tools for coordination and identity:

🧩 Composable Identity Layers

We're designing identity primitives that allow protocols to define and delegate structure: team namespaces, DAO roles, multi-vault operations wrapped into readable, queryable sub-identities.

🧠 Interoperable Metadata

Future phases will introduce contextual, role-aware metadata. Think of .hype names as smart containers that express what a user or entity does, not just who they are, that will unlock new levels of interaction, incentives, and UX focused usability across the ecosystem.

🔎 Legibility Across Ecosystems

We're exploring ways to surface name-linked behavior and alignment, so .hype becomes a trusted signal of activity, contribution, or governance standing across dashboards, bots, and smart contracts.

🔐 Access & Permissions Made Simple

We’re researching flexible tools that let protocols use .hype names to manage access, delegate permissions, and trigger actions without needing complex smart contracts.

The future of dotHYPE is intentionally modular and composable. Our roadmap is guided by ecosystem need from the voice of the end user.

🏆 Leaderboard system

More details to come soon ;)

Want to help shape what’s next? Join our community →

Infrastructure should do more than serve today’s needs. It should shape tomorrow’s possibilities.

dotHYPE is built with modularity at its core. We chose to reimagine, in particular respecting what worked well and forgoing what didn't with more modern approaches. ENS set a strong precedent, but its router-based model strains under evolving demands. We retained the essentials such as its resolution standards, ERC-721 NFT-based ownership and left behind the baggage that hindered progress.

Our starting point is dialogue that's deeply immersed with builders in the ecosystem. We met with protocol founders, infra architects, and dApp developers to understand the real bottlenecks they faced. The signal was clear: the ecosystem didn’t need another vanity layer. It needed structure, legibility, and durable trust to build a user experience worthy in the Hyperliquid ecosystem aiming to be the "Future of Finance".

Use .hype Names in Your App

The dotHYPE resolver is fully ENS-compatible, making integration simple for developers already familiar with Ethereum naming systems. You can use standard addr(), getName(), and text() calls to resolve identity information from .hype domains. No proprietary logic required.

Basic Usage

To resolve .hype names, use the dotHYPEResolver contract and the following standard functions:

Note: The node refers to the ENS-compatible namehash of the .hype domain.

Naming in Web3 has been reduced to vanity. We believe it should be about legibility, structure, and coordination. At dotHYPE, we returned to first principles: what does identity infrastructure require in a modular, high-performance ecosystem like HyperEVM?

Our conclusions shaped every layer of our stack:

• Modularity: Registry, controller, and resolver are isolated components - independently upgradeable and designed to avoid monolithic bloat.

• Composability > Coupling: We respect ENS where it enhances interoperability, but discard legacy router patterns and static assumptions.

• Permissionless by Default: Access is fair, cryptographically verifiable, and free from gatekeeping.

• Community-Aligned: Roadmap is shaped in partnership with builders. Feedback is and keeping a close pulse to the voice of the user is paramount.

Names in dotHYPE aims to transcend its familiar limitations. They are containers for metadata, anchors of reputation, and primitives for coordination. We believe defaults encode values. That’s why our architecture reflects a moral stance as much as a technical one: sustainability over speculation, openness over opacity, structure over chaos.

Most systems retrofitted identity into rigid models. We started clean: modular, interoperable, and extensible from day one.

The future of identity isn't something we expect to achieve in a single release. It’s a long-term, purpose-driven journey. What launches today is the foundational layer of a much broader vision: a modular identity protocol that can evolve alongside the HyperEVM ecosystem. We’ve intentionally focused on doing the basics right: clean architecture, standard resolution, principled minting so that future layers can be built with confidence and without compromise.

Real identity infrastructure is iterative. It needs to be tested, stressed, and informed by how people actually use it. That’s why post-launch, our priorities shift toward listening, integrating, and extending.

Here’s what comes next:

• Integration Support for HyperEVM Protocols We’re working closely with our launch and post-launch partners to embed .hype resolution across their respective applications. This means leaderboard visibility, dashboard presence, user filtering, and other ways to give names real semantic weight. Every integration brings us closer to making identity actionable and legible by default.

• Infrastructural and Metadata Refinement Our next major technical layer involves subgraph indexing and schema standardization. This unlocks structured metadata for names, enabling things like role tagging, reputation, and credential-based coordination. Think of this as the second foundation: not just who you are, but what you represent, fully onchain.

• UX and Design Optimization Identity should be intuitive and we recognize that needs to be developed with an active userbase. We’ll be refining our mint flows, profile displays, and SDK integration points so that .hype names are functional, frictionless, and expressive in every interface that supports it.

• Deeper Integration with Strategic Partners Our beta-phase R&D begins here. We’ll work hand-in-hand with key partners to explore advanced identity use cases such as delegation flows, vault-level trust, and even digital passports that evolve over time. These partnerships will shape how identity in HyperEVM moves from static label to living credential.

By building modularly and deploying iteratively, we’re ensuring that dotHYPE launches with a product first focus that is informed by true UX necessity. The next chapter is about layering meaning, trust, and utility into every name.

🔧 The Modular Backbone of dotHYPE

dotHYPE is built for a modular blockchain future. Instead of one giant smart contract, we designed a clean, composable system split across four core contracts—each responsible for a specific piece of functionality.

This modularity gives us:

• 🚀 Flexibility to iterate without hardcoding everything into one place

• 🔐 Better security through limited scopes and cleaner audits

• 🤝 Easier integrations for developers and protocols

These components are designed to work independently, but connect seamlessly through permissioned interfaces and shared standards.

🧱 Core Contracts at a Glance

🔄 How They Work Together

Here’s the typical mint flow for a .hype name:

1. You search for a name on the frontend.

2. The frontend checks the name’s status via the Registry.

3. If available, you sign a minting intent via EIP-712 (handled by the Controller).

4. The Controller processes the request, confirms allowlist or auction state, and passes it to the Registry to mint.

5. Once minted, your name can be personalized and resolved using the Resolver.

one is described in detail in the sections that follow.

🔍 Why This Design Matters

Other systems often bundle all logic into one contract or rely on legacy ENS-style routers. We didn’t do that.

Our approach:

• ✅ Separates business logic from storage and resolution

• ✅ Respects ENS standards where they matter (like resolution)

• ✅ Enables protocol-level upgrades and partner modules without rewrites

This structure allows dotHYPE to evolve from a minting system into a programmable identity layer.

📚 What’s Next

Explore the core contracts:

• → Tracks ownership and expirations

• → Handles minting access and pricing

• → Makes your name usable across Web3

This component enhances your RainbowKit wallet connection UX by displaying the user's primary .hype name (if set) instead of a truncated address. It works seamlessly across HyperEVM mainnet and testnet, supports loading states, and falls back to address when no name is set.

Step 1. Overview & Purpose

This custom component:

• Replaces wallet addresses with .hype domains

• Uses the DotHypeResolver.name(address) function

• Falls back to the address if no primary name is set

• Detects network automatically via chain ID

• Supports full styling customization

⚠️ Important: Replace the placeholder contract addresses in the code with your actual deployed resolver addresses (see /info page for details).

Step 2. CustomConnectButton.tsx

Step 3. CSS Styles

Step 4. Usage Example

⚠️Pro Tip

The component automatically detects the network based on the chain Id prop. Chain ID 999 is used for HyperEVM mainnet, while any other value defaults to testnet.

Regardless of whether you're minting via whitelist, reserved access, or public signature, the registration process moves through the same stages.

High-Level Flow

1. Search a name → Check availability and pricing

2. Validate eligibility → Based on mint phase (whitelist, reserved, or public)

3. Submit transaction → Confirm duration and pay with $HYPE

4. Mint NFT → Registry issues the .hype name as an ERC-721 token

5. Record expiration → Expiry timestamp is stored in the Registry

The Controller contract orchestrates all of this and ensures only valid requests make it through.

UX Flow Example

Let’s walk through what happens when a user mints a name:

1. User connects wallet to the mint UI

2. User types a name (e.g. artist.hype)

3. UI checks name availability via available(name)

4. UI fetches price for 1-year term via getPrice(name, duration)

5. Depending on the phase:

   • If whitelisted: user submits a Merkle proof

   • If reserved: contract verifies the address matches

   • If public: user signs an EIP-712 message and submits it

6. Controller processes payment in $HYPE

7. Registry mints the name and logs expiration

8. UI shows confirmation, name dashboard becomes active

On-chain Processing Summary

Behind the scenes:

• All logic is routed through the dotHYPEController

• The Controller ensures:

  • The name meets eligibility criteria

  • Duration and price are valid

  • Payment is processed and refunded if overpaid

• Once verified, the Controller:

  • Calls the Registry to mint the NFT

  • Sets expiration timestamp (now + duration)

Duration and Pricing

All names:

• Must be registered for at least 365 days

• Can be extended in 1-year increments

• Are priced according to character length:

  • 3 characters → higher tier

  • 4 characters → mid tier

  • 5+ characters → base tier

Pricing is in USD and converted to $HYPE using an oracle at time of mint.

Payment Details

• All mint payments are made in $HYPE

• Overpayments are refunded automatically

• A designated recipient receives mint funds (e.g. treasury multisig)

No approvals or token swaps needed—users only need $HYPE in their wallet.

Mint Result

Once minting is complete:

• The user owns a .hype name NFT

• It appears in their wallet

• It can be resolved across Web3 using the Resolver

• Expiration is stored and can be extended via renewal

We understand that building naming infrastructure is a long-term commitment to the clarity, agency, and composability of an entire ecosystem. Mistakes are inevitable. But accountability, transparency, and principled iteration are how we navigate tradeoffs.

At dotHYPE, we’ve paced our rollout in conversation with the ecosystem - not to engineer momentum, but to deepen alignment. From DeFi vault architects to middleware builders, we’ve gathered insights not from retrospectives, but from the road itself.

We believe identity is an enabling surface, a protocol primitive. We believe names can be used to encode purpose, designate function, and streamline interactions between agents, humans, and protocols alike.

Rather than chasing early attention, we focused on credibility. That meant engineering for clarity. Listening before declaring. Designing with others, not just for them.

We are a team that values precision. Not in pursuit of perfection, but to avoid the silent drift that erodes systems over time. The result is infrastructure shaped by stewardship.

We’re not here to build fast. We’re here to build what lasts.

Every .hype name is an NFT—minted and stored using this registry. It’s compliant with ERC-721, but also includes extensions to manage lifecycle events like renewal, expiration, and status tracking in a way that fits naming infrastructure.

This page explains how the registry works and what matters for developers or curious users.

📘 What It Does

The Registry contract is responsible for:

• Minting .hype names as NFTs

• Assigning expiration timestamps

• Enforcing availability logic (e.g. what counts as expired)

• Preventing transfers of expired names

• Handling metadata for display

All minting and renewing must come through the Controller contract, which acts as a gatekeeper. That ensures pricing and access logic can be upgraded independently.

You can think of the Registry as the final source of truth for who owns what and for how long.

⏳ Expiration & Renewal Rules

Each name is registered for a fixed period, starting from the time of mint. Once that period ends, the name enters a 30-day grace period. During this window:

• The owner can still renew the name

• But it can’t be transferred or sold

After the grace period ends:

• The name becomes available to others

• It can be re-registered by anyone

To ensure meaningful durations, all registrations must last at least 28 days.

🔐 Availability Logic

A name is considered available if:

• It has never been registered

• OR its expiration + grace period has passed

This logic ensures names can’t be accidentally or maliciously re-claimed too early. Builders can use the available() function to check status.

function available(string calldata name) external view returns (bool);

🔁 Minting & Renewal Process (Simplified)

Names are minted and renewed through the Controller. The Registry handles the actual recording.

When a name is registered:

1. A token ID is created using the namehash algorithm

2. An expiration time is assigned

3. An NFT is minted to the user

When renewed:

• The expiration is extended based on the original expiry (not the current time)

• If the name is expired but within the grace period, it can still be renewed

function register(string calldata name, address owner, uint256 duration) external onlyController returns (uint256 expiresAt);
function renew(string calldata name, uint256 duration) external onlyController returns (uint256 expiresAt);

🧠 Token ID Generation

Each .hype name is converted into a token ID using a standard namehash algorithm—similar to ENS. This ensures uniqueness and predictability.

function nameToTokenId(string calldata name) public pure returns (uint256);

The algorithm:

• Hashes the domain label using keccak256

• Combines it with a root .hype identifier

• Outputs a 256-bit integer as the token ID

This process ensures all names are deterministically derived and collision-resistant.

🖼 Metadata & Status Queries

Each name has a metadata URI, which can be customized using an external metadata provider. This lets you:

• Display profile cards, avatars, or status in apps

• Serve dynamic visuals for first 1K mints or milestone names

The Registry also exposes read-only status functions:

function expiresAt(uint256 tokenId) external view returns (uint256);
function expiry(string calldata name) external view returns (uint256);
function isExpired(uint256 tokenId) external view returns (bool);

🚫 Transfer Restrictions

Expired names (outside the grace period) cannot be transferred. This is enforced at the contract level no UI trickery.

The Registry overrides the _update() function to block transfers of expired tokens unless they are first renewed.

This protects users and prevents accidental loss of names post-expiration.

🛠 Admin Controls

Some functions are reserved for the protocol owner or multisig governance:

function setController(address _controller) external onlyOwner;
function setMetadataProvider(address _metadataProvider) external onlyOwner;

These allow future upgrades or metadata format changes without touching the core Registry logic.

🔎 For Developers

If you’re building an integration and want to:

• Check if a name is expired

• Query expiration time

• Display metadata or avatars

...the Registry is your go-to source.

It’s not where minting logic lives—that happens in the Controller. But it’s where final ownership, expiration, and display logic is confirmed.

See the Controller Contract → to understand how minting works upstream.

Still have questions? Reach out in our dev community →

Whether you're building a wallet, dashboard, or on-chain application, integrating .hype domains helps your users move from raw addresses to structured, readable identity.

Our resolver is fully on-chain, ENS-compatible, and designed without centralized gatekeepers so you can plug-in with confidence. Everything is modular and upgrade-ready, giving us a stable foundation today and flexibility for tomorrow.

What You Can Do

• Resolve Names to Addresses

• Read On-chain Text Records (e.g. Twitter, avatar)

• Support Reverse Resolution

• Query Ownership via ERC721

Start Integrating

→ Resolver Reference Includes ABI, contract address, and example calls (addr(), text(), name()).

→ Integration Examples (Coming Soon) Code snippets for Ethers.js / Web3.js / React environments.

SDK (Coming Soon)

Our JS/TS SDK will simplify:

• Name availability + resolution

• Minting hooks

• React-ready UI components

Ready to build with dotHYPE? → Get Started with the Resolver

1. Introduction

Welcome to dotHYPE, a decentralized naming and identity protocol purpose-built for the Hyperliquid and HyperEVM ecosystems. dotHYPE allows users to register human-readable names (e.g., yourname.hype) that resolve to wallet addresses, metadata, and smart contract interactions. These names serve as onchain identifiers for individuals, DAOs, vaults, strategies, and other decentralized entities.

The Service includes:

• Immutable name registration via blockchain smart contracts,

• ENS-compatible resolution for wallets, websites, and metadata,

• Structured identity tools for decentralized applications and frontends,

• Tiered pricing for name registration based on character length.

dotHYPE is non-custodial, permissionless, and modular by design. It does not moderate or verify submitted names, nor does it arbitrate disputes. Once a name is registered and finalized on-chain, it becomes a permanent and public record.

The Service is operated by dotHYPE LLC, a Delaware-registered limited liability company. By accessing or using any part of the Service including searching, connecting a wallet, or registering a name, you agree to be bound by these Terms & Conditions. If you do not agree to be bound by these Terms and Conditions, you are prohibited from accessing, registering for, or otherwise using the Services in any manner.

For information on how we collect, use, or retain any off-chain metadata or wallet interaction logs, please refer to our Privacy Policy. This document will govern all data-related matters not addressed in these Terms.

2. Nature of the Protocol

dotHYPE is a non-custodial, decentralized, and permissionless protocol. It allows users to register human-readable identifiers (.hype names) that resolve to blockchain addresses, metadata, and other information. These identifiers are publicly visible, on-chain, and immutable.

While the protocol is permissionless in its public phases, dotHYPE may pre-reserve a limited subset of names for strategic purposes such as partnership allocations, community rewards, or technical bootstrapping. These reservations are finite, transparently managed, and do not affect the integrity or decentralization of the broader protocol.

dotHYPE does not pre-moderate user-submitted names in open minting phases. User registrations are immutable once finalized on-chain, and dotHYPE LLC does not act as a content moderator or arbitrator of naming disputes.

3. User Responsibilities

By using the Service, you agree that:

• You are solely responsible for any name, metadata, or content you submit or register.

• You will not register names that:

  • Infringe any copyright, trademark, or intellectual property rights;

  • Impersonate any person or entity;

  • Are misleading, defamatory, abusive, hateful, threatening, or otherwise unlawful.

• You acknowledge that:

  • All registrations are public and permanent;

    • dotHYPE does not remove or alter names post-registration;

• You are solely liable for any legal claims that arise from your name usage.

You agree to use the Service in compliance with all applicable laws and regulations in your jurisdiction.

4. Intellectual Property and Disputes

dotHYPE LLC:

• Does not adjudicate or resolve intellectual property disputes;

• Does not verify ownership of trademarks or brands;

• Does not endorse or approve any registered name.

• May publish a public list of reserved names for transparency.

However, we reserve the right (but not the obligation) to:

• Comply with a valid legal order by a U.S. court or government authority;

• Limit visibility or functionality of a name in cases of:

  • Proven legal infringement;

  • Fraud, impersonation, or systemic abuse.

These actions do not constitute name censorship or moderation and are implemented only in rare, clearly documented legal cases.

5. Indemnification

You agree to indemnify, defend, and hold harmless dotHYPE LLC, its developers, officers, affiliates, and agents from and against all third-party claims, damages, liabilities, losses, costs, or expenses (including reasonable legal fees) arising out of or relating to:

• Your use of the Service;

• Any name or metadata you submit or register;

• Any violation of these Terms or applicable law;

• Any claim that a name you register infringes a third party’s rights.

The provisions of this clause shall survive any termination or expiration of these Terms and shall remain in full force and effect.

6. Disclaimers

In addition to all other disclaimers provided in this document, dotHYPE disclaims responsibility for the outcomes of any interactions users may have with third-party tools or services that interface with the protocol. Users are solely responsible for ensuring the integrity of their on-chain actions and off-chain integrations.

THE SERVICE IS PROVIDED “AS IS” AND “AS AVAILABLE,” WITHOUT WARRANTIES OF ANY KIND - EXPRESS, IMPLIED, OR STATUTORY. WE DISCLAIM ALL WARRANTIES, INCLUDING BUT NOT LIMITED TO:

• MERCHANTABILITY,

• FITNESS FOR A PARTICULAR PURPOSE,

• NON-INFRINGEMENT,

• ACCURACY,

• SECURITY,

• AVAILABILITY,

• OR THAT THE SERVICE WILL BE ERROR-FREE OR UNINTERRUPTED.

You acknowledge and agree that your use of the Service is at your sole risk. The Service is provided on an 'as is' and 'as available' basis without warranties of any kind. You further understand and accept that blockchain protocols and related technologies may be subject to vulnerabilities, including but not limited to software bugs, security breaches, hacks, hard or soft forks, network downtime, or other systemic failures that are beyond the control of dotHYPE. dotHYPE shall not be held liable for any losses or damages arising from such events.

7. Limitation of Liability

To the fullest extent permitted by law:

dotHYPE LLC and its affiliates will not be liable for any indirect, incidental, special, consequential, punitive, or exemplary damages arising from:

• Your use or inability to use the Service;

• Any errors or delays in smart contract operation;

• Loss of funds, names, or digital assets;

• Third-party actions, legal claims, or service incompatibilities.

Total liability shall not exceed the amount paid by you (if any) directly to dotHYPE LLC in connection with the Service.

8. Payments and Fees

• All payments are processed in supported digital assets (e.g., $HYPE, USDTo).

• No fiat payments are accepted.

• All transactions are final. No refunds will be issued except where explicitly outlined in promotional campaigns or special programs.

• Prices and fees may fluctuate based on token price, auction mechanics, or market conditions.

9. Technical Risks & Service Availability

• dotHYPE provides no guarantees about:

  • Availability of any name;

  • Uptime or performance of the Service;

  • Compatibility with wallets, browsers, or external applications.

You acknowledge and accept the risks associated with using blockchain-based applications, including:

• Failed transactions,

• Congestion or downtime,

• Incompatibility with third-party tools,

• On-chain slippage in pricing or renewals.

10. Prohibited Conduct

You may not:

• Use bots or automated scripts to mass-register names unless explicitly authorized;

• Exploit contract vulnerabilities or front-running opportunities;

• Attempt to interfere with or harm the protocol;

• Violate applicable laws, regulations, or third-party rights.

We reserve the right to restrict access for users engaging in prohibited conduct, in accordance with applicable laws.

11. No Endorsement

dotHYPE LLC does not endorse, sponsor, or certify any user, project, or entity based on their name registration. The presence of a name in the protocol does not imply legitimacy, affiliation, or quality.

12. Governing Law & Dispute Resolution

These Terms are governed by the laws of the State of Delaware, USA, without regard to its conflict-of-law principles.

Binding Arbitration: Any dispute or claim shall be resolved exclusively through binding arbitration administered in Delaware. No Class Actions: You waive the right to participate in any class action or class-wide arbitration.

13. Changes to the Terms

dotHYPE may revise these Terms at any time. Updates will be posted with a new “Last Updated” date. Where material changes are made, we will post a notice on our website and maintain a version history log for reference. Continued use of the Service after such changes constitutes your acceptance of the revised Terms.

14. Age Restrictions

The Service is intended for individuals 18 years of age or older. We do not knowingly collect data from individuals under 18. If such data is discovered, it will be deleted promptly.

15. Entire Agreement

These Terms constitute the entire agreement between you and dotHYPE LLC concerning the use of the Service. If any provision is deemed unenforceable, the remaining terms shall remain in effect.

This agreement does not create any agency, partnership, or joint venture relationship. Any failure by dotHYPE LLC to enforce any provision shall not constitute a waiver of that provision.

16. Force Majeure

dotHYPE LLC shall not be held liable for any failure or delay in performance under these Terms due to causes beyond its reasonable control, including but not limited to: acts of God, natural disasters, war, terrorism, civil unrest, labor shortages, governmental actions, regulatory changes, blockchain network failures, smart contract exploits, or widespread internet outages.

In such events, dotHYPE reserves the right to suspend or modify parts of the Service without liability or notice until normal operations can resume.

17. Contact

For legal inquiries, including those related to trademarks, intellectual property, or arbitration notices, please contact: team@dothype.io

Mainnet

🌐 Network Information

• Current Network: HyperEVM Mainnet

• Chain ID: 999

• Block Explorer: HyperEVM Scan

🧾 Protocol Information

• Protocol Name: DotHYPE

• Top-Level Domain: .hype

• Total Contracts: 4 of 4 configured

Testnet

🌐 Network Information

• Current Network: Hyperliquid Testnet

• Chain ID: 998

• Block Explorer: HyperEVM Scan

🧾 Protocol Information

• Protocol Name: DotHYPE

• Top-Level Domain: .hype

• Total Contracts: 4 of 4 configured

Fully ENS-compatible, the Resolver contract supports multiple record types, reverse resolution, and metadata customization. It follows the standard ENS interface structure but is tightly integrated with the dotHYPE Registry to enforce domain status and expiration.

This contract does not handle ownership—it simply reflects what the Registry allows, and enables you to associate rich identity data with your name.

🔍 What It Does

The Resolver supports:

• Address resolution (EVM and multi-chain)

• Text records (socials, avatar, website, etc.)

• Content hash linking (IPFS, Swarm)

• Reverse resolution (address → name)

• Record versioning and batch updates

If your name is expired or inactive, all resolution queries return blank results. The Resolver only returns records for active .hype names.

🔗 Address Resolution

You can link your .hype name to wallet addresses using either:

• A simple EVM address (default Ethereum-style resolution)

• A multi-coin address using SLIP-0044 standards

Set via:

If no address is set, most systems default to the current domain owner.

📝 Text Records

Text records allow you to embed human-readable metadata into your .hype name.

Common uses include:

• Socials: com.twitter, com.github

• Profile: avatar, description

• Contact: email, url, website

Text records power UI display, social graphing, and indexing.

🧬 Content Hash

Use a .hype name to link to decentralized content like:

• IPFS files or websites

• Swarm hashes

• Other content-addressed systems

This is ideal for user profiles, dApp frontends, or media hubs.

🔄 Versioning System

Rather than deleting records one by one, dotHYPE enables full record resets via versioning.

Each record is linked to a version counter:

• clearRecords() bumps the version

• All previous records become invalid

Useful for refreshing a stale or incorrect profile in one transaction.

🔁 Reverse Resolution

Reverse records map wallet addresses back to .hype names. This is what makes UIs (wallets, explorers, dApps) show your name instead of a 0x address.

Key functions:

You can also:

• Query a text record via reverse: getValue(address, key)

• Check if an address has a reverse record: hasRecord(address)

🚫 Domain Expiration Enforcement

The Resolver enforces expiration checks. If a domain is expired:

• All resolution returns are blank

• Records cannot be set or updated

This ensures that only active .hype names can display metadata or resolve onchain.

🧩 Multi-call Support

To keep things gas-efficient, the resolver supports batch operations:

• Set multiple records in a single call

• Commonly used when updating profiles or migrating data

This feature inherits from the Multicallable interface standard.

🔐 Access & Authorization

Only the current name owner can set or update records.

• Ownership is checked against the Registry

• If your name is expired, you temporarily lose write access

All write functions include internal isAuthorized() checks.

📡 Interface Discovery

Applications can check whether this resolver supports a given record type using:

dotHYPE Resolver supports:

• IAddrResolver

• IAddressResolver

• ITextResolver

• IContentHashResolver

• IReverseResolver

This ensures compatibility with ENS-resolving dApps and multi-chain interfaces.

🧠 For Developers

If you're building with .hype names:

• Use addr() to resolve to a wallet or contract

• Use text() to display social or profile metadata

• Use reverseLookup() to show names for addresses

The Resolver does not store ownership—it’s a read/write utility that enhances what the Registry tracks.

• 🌐 Website:

• 💬 Discord:

• 🐦 X (Twitter):

All domain registrations and renewals are routed through the controller; it’s the decision-making contract that sits between users and the registry.

This is where pricing, access rules, signature verification, and allowlist enforcement live.

🔍 What It Does

The Controller handles:

• Enforcing registration pricing (based on name length and duration)

• Processing payments in $HYPE (based on USD-pegged prices)

• Verifying signed requests to prevent front-running (via EIP-712)

• Checking Merkle proofs for allowlisted mints

• Managing name reservations (for pre-approved addresses)

Think of it as the programmable access layer for the dotHYPE registry.

💸 Pricing Model

dotHYPE uses a simple but powerful pricing structure:

• Price is based on name length (e.g., 3-char names cost more than 5+)

• All prices are denominated in USD

• Payment is made in $HYPE, converted using an onchain oracle

• Registration and renewal are priced separately

Example (public mint):

• 3 characters: $100/year

• 4 characters: $40/year

• 5+ characters: $15/year

Pricing can be updated over time by the protocol owner, but logic is hardcoded for length-based tiers.

To fetch the price:

✍️ Signature-Based Registration

Most mints use EIP-712 structured data to ensure fair access. This prevents bots from front-running open registrations.

This flow:

1. Verifies a signed message from an authorized backend signer

2. Confirms the nonce hasn't been used

3. Calculates price and duration

4. Registers the name through the Registry

Signatures are used in public mint, premium auction, and certain reserved phases.

🌿 Merkle-Based Allowlists

For whitelist and partner-only phases, we use Merkle trees to verify whether a user can register a name:

Each address on the allowlist can register one name. Proofs are verified onchain. The Merkle root is updated periodically by the owner.

🪪 Reserved Name Access

Some names are explicitly reserved for specific addresses—partners, integrations, or founders.

Only the address that a name is reserved for can register it. No one else can front-run or bypass this.

Admin can assign or remove reservations:

🔁 Renewal

Renewals are permissionless. Anyone can renew any name by paying the correct amount.

• Duration is in seconds

• Pricing uses the renewal tier (not the first-year price)

🔐 Payment Handling

The Controller:

• Calculates price in $USD

• Converts it to $HYPE using a live price oracle

• Verifies the user paid enough

• Refunds any overpayment

• Sends funds to the treasury or designated recipient

All payments are native token compatible—no need for approval flows.

🛠 Admin Functions

The Controller can be configured by the protocol owner (via multisig):

These functions adjust pricing, set key addresses, and manage access without changing the contract itself.

📡 Events for Tracking

Events emitted for downstream analytics:

• DomainRegistered

• DomainRenewed

• ReservedNameRegistered

• MerkleProofRegistration

• SignerUpdated, PaymentRecipientUpdated, PriceOracleUpdated

These can be tracked via Subgraph or block explorer for indexers and dashboards.

🔎 For Developers

If you’re building a dApp or CLI for minting:

• Use getPrice() to fetch cost before submitting

• Use registerWithSignature() for standard public minting

• Use registerWithMerkleProof() for allowlisted flows

You don’t need to interact with the Registry directly—the Controller routes all writes.

Want to mint for users via backend signature? Check our SDK guide or integration examples.

To see how a registered name becomes usable across dApps, dashboards, and wallets, continue to the

All registration pathways ultimately result in the same outcome: a .hype name minted as an NFT, owned by the registrant, and governed by an expiration timestamp.

This page introduces the shared rules and eligibility requirements that apply to all minting methods.

For deeper implementation details, see the following subpages:

• Minting Flow

• Signature Validation (EIP-712)

• Merkle-Based Whitelisting

Key Principles of Registration

Across all registration types:

• Names are minted as ERC-721 NFTs

• Each name has a minimum 1-year registration period (365 days)

• Pricing is based on name length (shorter = more expensive)

• All payments are made in $HYPE (priced in USD via oracle)

• Registrations are recorded with expiration timestamps

Your name is yours for the full term—but must be renewed to avoid expiration.

Name Requirements

To be eligible for registration, a name must:

• Be at least 1 character in length

• Be available (never registered, or expired + grace period passed)

• Match an assigned reservation if it’s reserved

• Be registered for at least 365 days

Names that don’t meet these criteria will be rejected at the contract level.

Where to Go Next

To dive deeper into the specific mechanics and smart contract patterns behind each registration method:

Or continue exploring Registry Contract → and Controller Contract → for the underlying infrastructure.

1. Introduction

This Privacy Policy explains how dotHYPE LLC, a Delaware-registered limited liability company ("dotHYPE," "we," "our," or "us"), collects, uses, shares, and protects personal and pseudonymous data in connection with your use of the dotHYPE protocol, website, and smart contracts (collectively, the "Service").

This policy is designed to comply with:

• The General Data Protection Regulation (GDPR),

• The California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA),

• Emerging Web3 privacy expectations for decentralized and wallet-based applications.

By connecting a wallet, interacting with the protocol, or otherwise using the Service, you consent to the practices outlined herein. This Privacy Policy should be read in conjunction with our Terms & Conditions, which govern your use of the Service and include additional disclaimers and limitations relevant to your data and identity interactions.

2. Information We Collect

a. On-Chain Data (Public)

The following data is stored permanently and publicly on blockchain networks:

• Wallet addresses

• Name registrations and metadata

• Smart contract interactions (e.g., mints, renewals, transfers)

This data is immutable and accessible to anyone. dotHYPE does not control how third parties access or interpret this data.

b. Off-Chain Data (Controlled by dotHYPE)

We may collect or process limited off-chain data:

For clarity, we do not collect any directly identifiable personal information (PII) such as names, emails, physical addresses, government IDs, or account logins. All interactions occur via self-custodied wallets and are pseudonymous by design.

We do not collect names, emails, or other directly identifying information.

3. Legal Basis for Processing

In accordance with GDPR Article 6, we process personal and pseudonymous data under the following legal bases:

• Legitimate interest: to secure the protocol and prevent abuse.

• Performance of a contract: to fulfill services tied to allowlist eligibility, minting access, or smart contract execution.

4. How We Use the Data

We use collected data to:

• Verify mint eligibility during allowlist and snapshot phases.

• Enable fair access and prevent sybil attacks or wallet manipulation.

• Improve protocol security, UX, and performance.

• Comply with legal obligations or requests.

We do not use collected data for profiling, behavioral advertising, or selling.

5. Sharing & Third-Party Processors

We do not sell or rent your data.

We may share limited data under these conditions:

• With ecosystem partners who submit allowlists (e.g., wallet addresses only).

• With infrastructure vendors (e.g., snapshot services, analytics providers) who act as data processors under formal Data Processing Agreements (DPAs).

• With legal authorities if required by court order or valid legal process.

All third-party service providers are contractually bound to uphold this policy.

6. Cross-Border Data Transfers

If you are located in the European Economic Area (EEA), United Kingdom, or another jurisdiction with data transfer restrictions, please note:

Your data may be transferred to and processed in the United States or other jurisdictions where we or our processors operate. Where required, we implement appropriate safeguards such as Standard Contractual Clauses (SCCs) to ensure adequate protection of your data.

7. Data Retention

We retain off-chain data only as long as needed for the purpose for which it was collected.

• Snapshot data is retained for no more than 60 days after a mint phase concludes.

• Analytics and logs are periodically anonymized or purged.

You may request deletion of any off-chain data by contacting privacy@dothype.io. We cannot delete data that is stored immutably on a public blockchain.

8. Your Rights

Under GDPR (EU/UK Residents):

You may request:

• Access to off-chain data we hold about your wallet

• Rectification or deletion of off-chain data

• Restriction of processing

• Data portability (where applicable)

Under CCPA/CPRA (California Residents):

You have the right to:

• Know what personal information we have collected

• Request deletion of your data

• Opt-out of data sharing (note: we do not share or sell user data)

To exercise any of these rights, contact privacy@dothype.io with the subject line “Privacy Request – [Your Wallet Address]”.

9. Cookies and Analytics

Our website may use:

• Essential cookies for load balancing and wallet verification

• Anonymized usage analytics via privacy-respecting tools like Plausible

We do not use tracking pixels, fingerprinting tools, or behavioral ads.

10. Web3 User Considerations

dotHYPE aligns with self-sovereign identity (SSI) principles by enabling users to participate without disclosing off-chain identities. As the Web3 privacy ecosystem matures, we may explore integrations with zero-knowledge credential frameworks that enhance selective disclosure and data minimization.

While we encourage wallet hygiene, you should be aware that:

• Wallet addresses are pseudonymous but traceable

• Name registrations and smart contract interactions are public

• Use of ENS-compatible resolvers may expose text records or avatars you configure

We recommend avoiding storing personal identifiers in on-chain metadata. Should users choose to add personal data via ENS-compatible records or resolver metadata, they do so voluntarily and at their own risk. We cannot control or remove such data once written to the blockchain.

11. Updates to This Policy

We may update this Privacy Policy as laws evolve or our Service changes. Each revision will include a new version number and updated "Last Updated" date. If updates are material, we will:

• Update the “Last Updated” date

• Notify users via the website or other appropriate channels

12. Contact Us

For privacy-related concerns or to exercise your data rights, contact our Data Protection Officer (DPO) or authorized privacy representative at: team@dothype.io

You may also reach us at:

dotHYPE LLC 8 The Green Suite B Dover, DE, US 19901