# How It all Works

### 🔧 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

| **Contract**   | **Role**           | **What it Controls**                                                             |
| -------------- | ------------------ | -------------------------------------------------------------------------------- |
| **Registry**   | NFT ownership      | Tracks who owns each name, when it expires, and when it can be renewed           |
| **Controller** | Minting logic      | Sets pricing, duration, access, and routes requests to the registry              |
| **Resolver**   | Name functionality | Allows your name to resolve to addresses, text records, content hashes, and more |

### 🔄 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**.

&#x20;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:

* [Registry Contract](/architecture/how-it-all-works/dothype-smart-contracts/registry-contract.md) → Tracks ownership and expirations
* [Controller Contract ](/architecture/how-it-all-works/dothype-smart-contracts/controller-contract.md)→ Handles minting access and pricing
* [Resolver Contract](/architecture/how-it-all-works/dothype-smart-contracts/resolver-contract.md) → Makes your name usable across Web3


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dothype.io/architecture/how-it-all-works.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
