> For the complete documentation index, see [llms.txt](https://docs.dothype.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dothype.io/architecture/how-it-all-works.md).

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

 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