> 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/registration-mechanics/merkle-based-whitelisting.md).

# Merkle-based Whitelisting

Merkle-based whitelisting is how we manage early access for select community members, partners, and contributors. This system allows addresses to claim names **without relying on centralized off-chain logic**, while still being efficient and secure.

This page covers how the allowlist system works, what’s visible to users and integrators, and how we preserve fairness while avoiding front-running.

### 🔐 Why Use Merkle Proofs

Merkle trees allow us to:

* Prove an address is eligible **without storing all addresses on-chain**
* Keep the allowlist verifiable but compact (just a root hash on-chain)
* Prevent misuse by limiting each address to a single claim (or one per configured tier)

This approach keeps the system:

* Transparent (proofs are user-verifiable)
* Efficient (low gas footprint)
* Secure (not guessable or enumerable by competitors)

### ✅ How It Works (Simplified)

1. Off-chain, we generate a Merkle tree of all eligible addresses
2. We store only the root hash on-chain
3. Each user is given a **Merkle proof**—a series of hashes proving their address is in the tree
4. During mint, the user submits their name, duration, and proof
5. The contract:
   * Verifies the proof against the root
   * Checks the user hasn’t already used their spot
   * Mints the name if all checks pass

```
function registerWithMerkleProof(
  string calldata name,
  uint256 duration,
  bytes32[] calldata proof
) external payable returns (uint256);
```

### 🛡 Anti-Exploitation Measures

To ensure fairness and prevent abuse:

* Each allowlisted address can mint **only once** during the phase
* Proofs are not reusable
* The Merkle root can only be updated by the protocol owner
* Reserved names cannot be claimed via Merkle (they must be claimed via the reservation method)

> This protects against address farming, multi-claim exploits, and ensures equality across wallets.

### ~~🧠 For Developers~~

~~To check if an address has used their spot:~~

```
function hasUsedAllowlistSpot(address user) external view returns (bool);
```

~~To reset usage for a list of addresses (e.g., in case of failed attempts):~~

```
function resetMerkleProofUsage(address[] calldata users) external onlyOwner;
```

~~To update the allowlist:~~

```
function setMerkleRoot(bytes32 _merkleRoot) external onlyOwner;
```

> ~~All allowlist generation and proof distribution is handled off-chain. You don’t need to expose full lists onchain or in your UI.~~

### ~~📣 Events Emitted~~

~~For indexers and dashboards:~~

```
event MerkleProofRegistration(string name, address indexed owner, uint256 duration);
event MerkleRootUpdated(bytes32 merkleRoot);
```

~~These events ensure transparent activity tracking while keeping individual proofs private.~~

***

### 👁️ Public Transparency, Private Integrity

dotHYPE's allowlist model balances:

* 🧩 Public verifiability (via Merkle proof structure)
* 🔐 Competitive opacity (roots only, no address indexing)
* 🎯 Usage fairness (1 claim per eligible wallet)

For broader context, return to the [Registration Mechanics → ](/architecture/how-it-all-works/registration-mechanics.md)overview.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.dothype.io/architecture/how-it-all-works/registration-mechanics/merkle-based-whitelisting.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.