Just like the internet needed DNS, Starknet needs a name service that makes it easy to use human readable (and memorizable!) addresses and makes it easy to update the underlying resource that those resources refer to, without requiring any action by the end user.

👀 TL;DR

Starknet name service lets anyone register human readable domains that point to a contract of their choosing. Domains can be registered for 1 to 10 years for an annual fee that is larger for shorter domain names, in order to avoid domain squatting. For a given domain, owners can add arbitrary subdomains.

Try it out! You can reserve a name, and update your registration using this frontend (on Goerli testnet).

Check out the code here, and links to Voyager for the registry here and a first resolver here.

Thoughts or questions? Feedback welcome! Send to @jonas_nelle on Twitter or @JonasNelle on Telegram

🤔 Approach

Build on Top of Ethereum

Just like Starknet is built on top of Ethereum and inherits its security from that, we want to build with the rest of the Ethereum ecosystem in mind. ENS has done a fantastic job being mindful about naming and wielding their power to make the ecosystem better, and we want to follow in their footsteps.

What does this mean practically? First, following ENS’s responsible lead, we will only create a .stark TLD to avoid name clutter. Second, we will make it easy for owners of existing .eth names to reserve the corresponding .stark names during the registration period (see below). Finally, we will work with ENS to add Starknet addresses to ENS and create a bridge so that we can resolve .eth names to Starknet addresses in the future.

Technical Implementation

Similar to ENS, we will create a separate Registry and Resolver. The registry is a single smart contract (thus centralized, though permissionless and on-chain) that stores the record of who owns which name, and the resolver associated with that name.

The resolver is a smart contract, determined by the name owner. Anybody can create a resolver, as long as that resolver conforms to a certain specification. The resolver’s job is to store and make available data the name’s owner wants to associate with their name. In V1.0 this will include the mapping between the (sub-)names and Starknet addresses.

See GitHub here.

Start Lightweight, Build Extensible

We will start just with the simple use case of resolving names (and subnames) to Starknet addresses. Because we separate the concerns of the registry and resolver we will be able to easily add functionality in the future, in a way that is backward compatible and preserves the security of names registered. Future versions will include resolvers for a name’s email address(es), Twitter handle(s), Discord username(s) and much more.

🚀 Roadmap

Rollout Process

  1. Test & feedback phase (2-4 weeks): Get feedback from the community about key features, iterate and repeat. Make the code robust to edge cases.
    1. Reverse lookup (address → names mapping)
    2. Commit and reveal scheme to future-proof (avoid front-running)
    3. Payment (see open questions)
  2. Launch on mainnet & reservation process (1-2 weeks): Make sure owners of names in other systems can reserve the equivalent names on SNS.
    1. Enable owners of .eth names to have priority registering the corresponding .stark names
    2. Enable entities with copyrighted names to have priority registering the corresponding .stark names