Pharos ecosystem primitive

Human‑readable names for Pharos.

EasyCryptoName brings the .pha naming layer to Pharos: domains that resolve to wallets, smart contracts, and on-chain profiles, with a security-first core and an adoption plan built for mainnet launch.

Read the whitepaper View roadmap
alice.pha 0x7b…4C2a

Designed for wallets & dApps: predictable resolution rules, reverse lookup, and an audit-ready registry + resolver.

At a glance

A naming layer is only useful if it is native, secure, and shipped with integrations. These are the concrete targets.

Native TLD

.pha

Pharos-first identity, designed for ecosystem adoption.

Performance Fit

30,000 TPS

Built for Pharos UX: fast finality and high throughput.

Wallet-Grade Resolution

Forward + reverse

Send to a name, display names across the UI, and reliably resolve back to addresses.

RealFi-Ready Identity

Metadata schema

A path to structured, verifiable records that can power compliant, institution-friendly flows.

What EasyCryptoName ships for Pharos

A lean on-chain core, plus the integration layer that makes names usable everywhere from day one.

Registry + ownership rules

A canonical registry with explicit interfaces and conservative upgrade boundaries — so apps can depend on it.

  • Commit‑reveal to reduce front‑running
  • Renewals + grace periods
  • Indexer-friendly events

Resolver records wallets need

Predictable resolution for addresses, profiles, and content pointers — with documented edge cases.

  • Address, text, and content records
  • Reverse resolution
  • Safe record permissions

Adoption package

Names are only useful when apps and wallets support them. We ship guides, reference code, and SDKs so integration is easy.

  • Open-source SDK (JS/TS first)
  • Wallet integrations (OKX priority)
  • Spec-driven docs + checklists

Why this matters for Pharos

Naming is UX infrastructure. It reduces errors, improves onboarding, and creates a shared identity layer for the ecosystem.

Safer transfers

Users send to a name, not a 42‑character address. Fewer mistakes, higher trust.

Faster onboarding

One identity that works everywhere on Pharos — wallets, explorers, and dApps.

Composable profiles

Records for metadata and content pointers, portable across apps by design.

Production-ready from day one

Clear specs, predictable behavior, indexing events, and an integration kit so wallets and dApps can rely on it.

See roadmap →

Roadmap (mainnet-ready delivery)

Clear scope, measurable outputs, and security gates. Each phase ends with testable artifacts and integration references.

  1. M1 — Core protocol

    Minimal, secure, Pharos-native core

    • Registry + controller contracts, documented interfaces
    • Resolver: address + text records, predictable behavior
    • Threat model + reproducible tests

  2. M2 — UX & integrations

    Make names work in wallets & dApps

    • Reverse resolution + reference implementation
    • Explorer/indexer event mapping guidelines
    • dApp integration examples + docs

  3. M3 — Hardening & adoption

    Audit-ready release + launch checklist

    • Audit-ready release candidate with changelog
    • Public docs: resolver spec + integration checklist
    • Launch plan: monitoring + incident response notes

Whitepaper

A concise, readable technical overview. Request a formatted PDF via email if needed.

Abstract

Pharos Domain Service is a production-grade, Pharos-native on-chain naming system that maps .pha domains to on-chain records (addresses, content pointers, profiles, and future RWA-ready metadata). The goal is to standardize resolution across Pharos while keeping the core minimal, secure, and simple to integrate.

Download PDF

Key sections

Protocol overview

Registry, controller, resolver, reverse records, and event/indexing strategy.

Security model

Threat model, invariants, commit‑reveal registration, and audit readiness.

Adoption plan

Wallet + dApp integrations, SDKs, and checklists that make names work across the ecosystem.

FAQ

Is this “just ENS on another chain”?

We borrow proven patterns, but the focus is Pharos adoption: predictable resolver behavior for wallets and dApps, integration docs, and milestone deliverables you can verify.

How do you prevent front-running when registering names?

We use a two-step “commit then reveal” flow. In plain terms: you first lock an intent to register, then finalize it later, which prevents others from copying your registration in the same block.

Why does Pharos need a native name service?

Because names are UX infrastructure. A Pharos-native system standardizes how apps display identities and resolve payments, reduces errors, and enables a shared profile layer across wallets, explorers, and dApps.

How is this different from earlier testnet name prototypes?

The goal is a mainnet-ready registry for .pha: formal interfaces, security gates, indexing events, and an integration package (SDK + wallet/dApp references) so names are usable, not just minted.

Talk to the team

We can share a longer spec, integration notes, and a live walkthrough of the protocol and resolver behavior.

[email protected] [email protected]

Prefer a quick intro call? Email us with your timezone and we’ll propose times within 24 hours.