The internet’s naming system remains under the centralized control of the Internet Corporation for Assigned Names and Numbers (ICANN), requiring million‑dollar fees and bureaucratic approval processes for new top‑level domains. While other blockchain naming systems have attempted to solve this through pure decentralization, they have failed to produce notable products or use cases after years of operation, trapped by ideological purity that refuses any coordination even when necessary for basic ecosystem development.
Dap represents a pragmatic alternative: decentralized enough to ensure censorship resistance and permissionless innovation, yet coordinated enough to ship products and serve users. We explicitly reject the purity spirals that have paralyzed other projects, choosing instead to measure success by applications built, users served, and utility created.
This paper introduces Dap’s technical architecture, economic model, and our philosophy of pragmatic decentralization that prioritizes shipping over philosophizing. Perfect decentralization without adoption is worthless. Dap chooses adoption.
Since 1998, ICANN has maintained monopolistic control over the internet’s root naming system. Creating a new top‑level domain (TLD) requires:
This system has resulted in ~1,500 TLDs existing after decades of internet growth, with control concentrated among a handful of large registry operators. Innovation is stifled, prices remain high, and entire communities and businesses are excluded from owning their namespace.
Previous blockchain naming systems launched with the promise of decentralizing domain names. The technology works; the blockchains run, names can be registered, DNS records can be set. Yet after years:
Why? The answer isn’t technical; it’s cultural.
These communities inherited Bitcoin maximalism’s toxic trait: an absolute refusal to coordinate or centralize anything, even temporarily, even when necessary for basic ecosystem development. This manifested as:
The Purity Trap: Any suggestion of coordination, funding, or leadership was attacked as “centralization” and rejected, regardless of practical benefits.
Technical Superiority Complex: Communities became satisfied with having built “the best decentralized naming system” technically, while ignoring that nobody uses it.
Governance Paralysis: Decision‑making processes optimized for “decentralization theater” over progress. Months spent debating, zero time shipping.
User Hostility: Expecting end users to understand blockchain mechanics, run full nodes, and compile software from source. Then wondering why adoption never came.
The Field of Dreams Fallacy: “Build the infrastructure and they will come.” No marketing. No business development. No user onboarding. No ecosystem cultivation.
Dap explicitly rejects this failed approach. We prioritize pragmatism, product development, and user adoption over ideological purity.
Products Over Protocol: We judge ourselves by applications built and users served, not by technical papers published or governance proposals debated.
Pragmatic Decentralization: We use centralization as a tool when it accelerates development, with clear sunset provisions to prevent permanent capture.
User‑First Design: If your grandmother can’t use it, we haven’t built it right. Complexity belongs in the backend, not the user interface.
Aggressive Business Development: We don’t wait for organic adoption. We actively pursue partnerships, integrations, and users.
Rapid Iteration: We ship weekly, not yearly. Better to launch and fix than to debate and delay.
The domain industry generates over $10 billion annually, with:
Yet innovation has stagnated:
Dap targets three distinct markets:
TLD Ownership: Instead of paying ICANN $185,000+ and waiting years, own a TLD on Dap immediately through transparent auctions.
Brand Protection: Companies can own their .brand TLD forever, controlling their entire namespace without annual ICANN fees.
Developer Innovation: Build applications impossible under ICANN’s restrictions—token‑gated domains, NFT integration, automated markets.
Unlike projects that wait for users to discover them, Dap actively creates adoption:
Phase 1: Resolution & Builders (Months 0‑6)
Phase 2: Browser & Businesses (Months 6‑12)
Phase 3: Mass Adoption (Months 12+)
Pragmatic Governance: For the first two years, a small team makes decisions quickly. No months‑long governance debates about minor technical details. No committee paralysis. Decisions in days, not months.
We choose building over debating, shipping over philosophizing, and users over ideology.
Dap builds on proven foundations while fixing the limitations of previous systems. We use a UTXO‑based blockchain with enhanced covenants designed for domain name operations.
Core Design Principles:
Key Improvements:
We resist the temptation to over‑engineer. Every technical decision is evaluated against realistic use cases, not theoretical possibilities.
Dap implements a revolutionary consensus mechanism combining three proven technologies:
Verifiable Delay Functions (VDF): Replace pure computational work with time‑based proofs, reducing energy consumption by 95% while maintaining security. Miners prove elapsed time, not wasted computation.
Verifiable Random Functions (VRF): Provide provably fair randomness for block producer selection and auction resolution. No more mining pool centralization or auction manipulation.
Blake3 Proof‑of‑Work: The fastest cryptographic hash function available, providing ASIC resistance and efficient verification.
This “Trinity” design delivers:
But we emphasize: Technical superiority means nothing without adoption. We judge our consensus by whether it enables products, not whether it wins academic awards.
A naming system nobody can resolve is a naming system nobody uses. Resolution isn’t a feature—it’s the entire product. Without it, we’re selling vanity database entries.
Day One Requirements (Ship with mainnet or don’t launch):
dns.dap.shYear One Goals:
Technical Specifications:
Advanced Features:
Measurable Success:
Users shouldn’t need to understand blockchain to use blockchain domains. They type a URL, it resolves. Everything else is implementation detail.
Where other projects relied on spontaneous emergence, Dap actively cultivates its ecosystem:
Centralized Kickstart: The Dap Foundation initially coordinates development, funds builders, and drives adoption. This is temporary centralization for permanent decentralization. We’ll sunset the foundation’s special powers after achieving product‑market fit.
Developer Grants: $10 million allocated for builders who ship products. Not researchers who write papers, not theorists who debate governance—builders who ship code users can use.
Marketing Budget: Yes, we market. We advertise. We sponsor conferences. We create content. We do business development. Because products without users are expensive hobbies.
Business Development: We actively pursue partnerships with registries, browsers, and applications. We don’t wait for organic adoption—we create it.
Our success metrics are products and users, not protocol features:
Testnet Goals:
Product Showcases:
User Focus:
Every protocol decision is downstream from “What helps users?”
We explicitly favor builders over speculators:
Testnet Rewards: Developers who build during testnet receive GRP token grants at mainnet launch. The more you build, the more you earn.
Mainnet Allocation: 10% of token supply reserved for proven builders, distributed based on ecosystem contribution, not token holdings.
Revenue Sharing: TLD auction revenues partially distributed to application developers driving adoption. Build the ecosystem, share the rewards.
Anti‑Speculation Measures:
We want builders, not holders. Users, not speculators. Products, not promises.
Dap’s auction system prioritizes utilization:
Vickrey Auction Format: Blind second‑price auctions ensure fair price discovery. Bidders submit sealed bids; the winner pays the second‑highest bid amount. This mechanism encourages honest bidding; your dominant strategy is to bid your true valuation, while preventing bid sniping and last‑minute manipulation.
Progressive Minimums:
Build Requirements: TLD winners must:
Builder Advantages:
TLD owners have complete control over their namespace:
Business Models:
Technical Freedom:
The Crucial Insight: “Own the whole .com, not just a domain.” Instead of registering mycompany.com, own .mycompany and control unlimited domains beneath it.
TLD squatting is prevented through economic incentives:
Usage Requirements:
Renewal Scaling:
Bulk Penalties:
Standard TLDs require SLD registrations to prevent squatting, but this conflicts with a legitimate use case: personal namespaces. Someone wanting `.lanhikari` for their own identity shouldn’t need (nor want) to sell domains to strangers.
Personal TLDs solve this through economic design rather than honor systems.
Registration Choice
At TLD claim, the wallet selects one of two classes:
| Class | Renewal Fee | SLD Requirement | Transfer Rules |
|----------|--------------|---------------------------|---------------------|
| Standard | Base rate | 100+ Year 1, 1000+ Year 2 | Freely transferable |
| Personal | 3× base rate | None | Graduated unlock |
The choice is recorded on‑chain at registration. The 3× fee multiplier makes portfolio‑building uneconomical while remaining affordable for genuine personal use.
Graduated Transfer Unlock
Personal TLDs have transfer restrictions that decay over time:
| Ownership Duration | Transfer Allowed? | Burn Penalty |
|--------------------|-------------------|--------------------------|
| Year 0–1 | No | Blocked |
| Year 1–2 | Yes | 75% of sale price burned |
| Year 2–3 | Yes | 50% of sale price burned |
| Year 3+ | Yes | None |
Deflationary burns: All penalty burns permanently remove GRP from circulation. No treasury allocation—pure deflation. This ensures no constituency benefits from rule‑breaking, making the penalty a pure disincentive.
By year 3, the owner has paid enough premium renewals (3× annually) that speculation math doesn’t work regardless of transfer freedom.
Personal → Standard Conversion
Circumstances change. A personal TLD can convert to standard class at any time, with the following conditions:
This prevents gaming where someone parks as personal then flips to standard right before a sale. The reverse conversion (standard → personal) is not permitted.
On-Chain Data
TLD {
class: "personal" | "standard";
last_renewed: timestamp;
name: string;
personal_since: timestamp | null;
registered_at: timestamp;
}
The personal_since field tracks when the TLD entered personal class, enabling accurate graduated unlock calculations regardless of original registration date.
Design Rationale
This approach succeeds where cap‑based exemptions (e.g., "4‑10 personal TLDs per wallet") would fail:
For the first two years, the Dap Foundation makes decisions quickly:
This is explicitly temporary. We need to achieve product‑market fit before decentralizing governance. Other projects proved that premature decentralization equals permanent paralysis.
After two years, we transition to community governance with pragmatic constraints:
Bounded Decisions: Governance for major changes (protocol upgrades, economic parameters). Daily operations remain centralized for efficiency.
Time Limits: All proposals have 30‑day maximum discussion periods. Decisions happen, even if imperfect.
Implementation Focus: Proposals must include implementation plans, not merely ideas. “Who will build this?” comes before “Should we build this?”
Default to Action: Without clear consensus against, we proceed. Inaction is not an option.
All special powers expire automatically:
| Component | Initial Control | Transition | Final State |
|---------------------|-----------------|-----------------|--------------------------------|
| Development Fund | Foundation | -20% yearly | Community DAO by Year 5 |
| Technical Decisions | Core Team | Gradual opening | Full community by Year 3 |
| Marketing | Dedicated Team | Ongoing | Professional team (DAO funded) |
| Partnerships | Business Dev | Ongoing | Professional team (DAO funded) |
Total Supply: 420,000,000 GRP
Distribution:
Why 70% to Miners: Unlike other projects that waste tokens on unclaimed airdrops or insider allocations, Dap puts the overwhelming majority in the hands of those securing the network. Miners are the backbone of Dap.
All TLD auction proceeds and penalty burns are permanently removed from circulation:
Burn Sources:
Burn Projections:
Economic Security: As supply decreases through burning while demand increases through adoption, GRP becomes increasingly valuable, ensuring long‑term mining incentives even as block rewards decrease.
Why True Burns: Penalty burns go to a provably unspendable address rather than a treasury. This eliminates perverse incentives—no constituency profits from rule‑breaking. "Break the rules, value disappears" is simpler to explain and harder to politicize than redistribution schemes.
Unlike other projects with complex token swaps or conversion mechanisms:
ICANN has operated without meaningful competition for decades. No pressure to innovate. No incentive to lower prices. No reason to improve. Dap changes that.
We are not an extension of the existing internet. We are an alternative.
No Reserved Namespaces: Every TLD is available at genesis. .com, .google, .amazon—all of it. If Verisign wants .com on Dap, they can bid in the auction like everyone else. We don’t reserve their seat at our table.
No Special Treatment: Legacy operators have no automatic claims, no DNSSEC proof shortcuts, no priority access. Dap is a level playing field. Your ICANN credentials mean nothing here—only your willingness to build and your GRP to bid.
No Apologies: We’re not “complementing” ICANN or “coexisting peacefully.” We’re demonstrating what a root namespace looks like when it’s run for users instead of bureaucrats. If that’s threatening, good. Competition should be.
Bitcoin didn’t ask permission from central banks. It didn’t say “we’ll avoid fiat currency denominations to prevent confusion.” It built an alternative monetary system and let people choose.
Dap follows the same logic. We’re not asking ICANN’s permission. We’re not worried about “name conflicts” with their system. We’re building something better and letting the market decide.
Your resolver, your namespace, your choice.
The only question that matters: can users reach Dap domains?
If yes, we win. ICANN becomes one option among many—the legacy option, the expensive option, the slow option.
If no, we’re irrelevant. The best protocol in the world means nothing if nobody can use it.
This is why resolution ships Day One. Not Year 3. Not “eventually.” Day One.
Resolution Strategy:
| Approach | Timeline | Reach |
|----------------------------------------------|------------------|---------------------------------|
| Browser extensions (Chrome, Firefox, Safari) | Launch | Early adopters, developers |
| Public DoH/DoT resolver (`dns.dap.sh`) | Launch | Anyone who changes DNS settings |
| Mobile configuration profiles | Launch | iOS/Android users |
| Aries browser (Chromium) | Year 1 | Full native experience |
| Aries browser (WebKit, Servo) | Year 1-2 | Engine diversity |
| ISP partnerships | Year 1-2 | Mainstream users |
| Native browser integration | Ongoing | Mass adoption (the real goal) |
Someone owns .google on Dap. Google Inc. is unhappy. What happens?
Nothing special. Google can:
1. Bid on.google in Dap’s auction (they probably should)
2. Ignore Dap entirely (their choice)
3. Sue someone (good luck—we’re decentralized)
What Google cannot do: demand we reserve their name, expect special treatment, or dictate our namespace policy.
The Dap owner of .google has exactly the same rights as every other TLD owner. They must meet usage requirements or face reclaim. If they squat, they pay escalating fees. If they build, they thrive.
Trademarks are an ICANN concern. In Dap’s namespace, you own what you win. Build something or lose it.
What We Track:
What We Don’t Track:
Build. Ship. Iterate. Everything else is noise.
Unlike other projects’ headless approach, Dap has clear leadership:
Technical Direction: Core team makes architectural decisions quickly and decisively. No endless bike-shedding over minor details.
Ecosystem Coordination: Dedicated team manages developer relations, partnerships, and user growth. Not left to “emerge organically.”
Resource Allocation: Foundation distributes grants based on results, not politics. Ship code, get funded.
Accountability: Leaders have genuine names, genuine reputations, and genuine skin in the game. No hiding behind anonymous accounts.
For Miners: 70% of supply ensures profitable mining even at low token prices. No dependency on unsustainable subsidies.
For Developers: Direct grants, revenue sharing, and clear monetization paths. Build on Dap, make money.
For Users: Utility from the start. Use domains for websites, email, identity. Not only speculation.
For TLD Owners: Run a genuine business selling domains. Not merely holding and hoping.
Year 0 (Testnet): Build, test, iterate. Browser extensions and resolver ready. Launch when ready, not when scheduled.
Year 1: Browser extensions live, Aries browser shipped, 10+ production applications, 100+ active developers, 10K+ daily users.
Year 2: Native browser integration negotiations, enterprise adoption, 100K+ daily users.
Year 3: Mainstream awareness, 1M+ daily users, profitable ecosystem.
Year 5: Serving 1B+ DNS queries daily. Undeniable product‑market fit.
Dap represents a fundamental shift in how blockchain projects approach development and adoption. We reject the failed maximalist approach that prioritizes ideological purity over user value. We embrace pragmatic trade‑offs that enable us to ship products and serve users.
The domain name system is too important to leave in the hands of:
Dap will succeed because we:
The internet deserves a naming system that is both decentralized AND useful. Previous projects proved you can build one or the other. Dap will prove you can build both.
ICANN has had no competition for three decades. That ends now.
Join us in building the future of internet naming. Not through endless debates and governance theater, but through shipping code and serving users.
Dap: The competition ICANN never had.
Blockchain Parameters:
Covenant Types:
DNS Integration:
What Centralization We Accept:
| Component | Centralization | Duration | Justification |
|---------------------|-----------------------|----------|---------------------|
| Development Fund | Foundation controlled | 5 years | Bootstrap ecosystem |
| Technical Decisions | Core team | 2 years | Ship quickly |
| Marketing | Dedicated team | Ongoing | Drive adoption |
| Partnerships | Business development | Ongoing | Enterprise adoption |
| Documentation | Technical writers | Ongoing | Developer success |
Sunset Provisions:
Year 1: “Startup Raises $5M Using .startup TLD”
.startup domain for all propertiesYear 2: “Fortune 500 Migrates to .brand TLD”
Year 3: “Developer Earns $1M from Domain App”
Year 5: “Dap Serves 1 Billion DNS Queries Daily”
Governance Paralysis: Other projects spent months debating minor parameter changes while shipping nothing. We decide in days and iterate.
Purity Spirals: Other communities attacked any pragmatism as betrayal. We celebrate what works.
Technical Superiority Without Usage: Others built “the best” system nobody uses. We build good‑enough systems millions use.
Community Gatekeeping: Toxic maximalism drove away builders. We welcome anyone who ships.
Speculation Over Utility: Others optimized for token price over product development. We optimize for usage metrics.
Documentation Negligence: Others never properly documented APIs or tools. We maintain comprehensive, updated documentation.
User Hostility: Others expected users to understand blockchain complexity. We hide complexity behind simple, intuitive interfaces.
ICANN Deference: Others reserved ICANN namespaces out of misplaced respect. We compete on merit.
Join us: https://dap.sh
Version 7 - Draft
Last Updated: 2025.12.24