What is PNS?
PNS — the Polkadot Naming Service — is a decentralized identity system built natively on Polkadot. It lets you register a human-readable name and attach it permanently to your on-chain address. Instead of sharing a long cryptographic address with someone, you share your name. Anyone can look it up and resolve it back to your address instantly.
Every record returned by a PNS lookup includes the block hash of the transaction that created it, meaning anyone can independently verify that the record is real and was actually recorded on the blockchain. No trust required — the chain proves it.
-–
## Registering Your Name
When you register a name, that name belongs to your address. Simple rules:
- One name per address. Your address can only hold one name — ever. You cannot register multiple names on the same address.
- One address per name. A name resolves to exactly one address. No ambiguity, no shared ownership at the name level.
- Your name is yours for as long as you keep it renewed. If your registration lapses, your name and everything under it becomes inactive.
- Names are case-insensitive, and can contain numbers. Special characters and symbols are not allowed.
-–
## Subdomains
If you own a name — say `frank.d0t` — you become the sole authority for everything under it. You can offer subdomains of your name to other addresses.
The rules:
One name per address, no exceptions. Your address can only ever hold one name. It does not matter whether that name is a root name or a subdomain under someone else’s name — you get one. If your address is frank.d0t it cannot also be bob.d0t. If your address is frank.d0t it cannot also be sally.bob.d0t. If your address is sally.frank.d0t it cannot also be alice.bob.d0t. One address, one identity, full stop.
You can have a maximum of 10 subdomains under your name at any time across all states — offered, active, or rejected combined.
As the parent name owner, you are the only one who can create subdomain offers under your name.
How offering works:
- You create an offer for a subdomain and specify exactly which address it is intended for
- That address now has a subdomain entry in the table with status “offered”.
- Only that specific address can accept or reject the offer — nobody else
- If they accept, the subdomain becomes active on their address
- If they reject, the record remains and counts against your 10 slot limit until the parent revokes it delete it. This is to limit spam.
Why does a rejection stay on your record?
This is intentional. If you are spamming people with unwanted subdomain offers and they keep rejecting them, those rejections consume your available slots. You have to manually clean up each rejected offer, which costs you a transaction fee each time. Bad behavior is economically expensive.
Receiving an offer costs the recipient a small transaction fee to reject it. If you would rather not pay that, you can simply ignore it. An offer that is never accepted does nothing — it sits in offered state indefinitely and has no effect on your identity. It cannot become active unless you explicitly accept it, and acceptance requires that your address does not already have a name assigned to it. You can receive offers whether or not you already have a name, but you cannot accept one if you do.
What the parent name owner can do:
- Offer a subdomain to any address
- Revoke a subdomain at any time regardless of its state, which frees that slot
- A revoke costs a transaction fee
What the subdomain holder can do:
- Accept an offer
- Reject an offer
- Release an active subdomain they no longer want, which frees that slot for the parent
What happens if the parent name expires?
If the parent name owner fails to renew their registration, every subdomain under it becomes inactive automatically. Sally does not need to maintain her own registration — but she is entirely dependent on Frank keeping his. If Frank lets his name lapse, `sally.frank.d0t` stops resolving until Frank renews. If Frank never renews, Sally loses her subdomain permanently.
If frank.dot fails to renew and the registration is expired, anyone can purchase frank.dot. the purchase automatically deletes any preexisting records, including subdomains.
-–
## Public Keys
Every PNS record supports up to 3 public key slots, numbered 1, 2, and 3. These slots are purpose-agnostic — PNS does not dictate what you put in them or what they are used for. That is entirely up to you and the applications you use.
Key slots support large post-quantum hybrid cipher keys, so whatever cryptographic standard your application requires, the slots can accommodate it.
What this means in practice:
If you own a root name with 10 active subdomains, your namespace contains up to 33 public keys — 3 per address across 11 addresses. Applications that need to look up your keys know exactly where to find them. They query your PNS record, iterate through the populated slots, and use whichever key matches what they need. Empty slots are skipped cleanly.
If you need more than 33 keys in a namespace, register a new root name on a new address and build from there.
Fees
The transaction fee to the network is always paid to change the state. In addition, the following fee table applies:
Character length | Registration Fee
-1……….. 1000 DOT
-2……….. 100 DOT
-3……….. 45 DOT
-4………. 25 DOT
-5……….. 10 DOT
-6+……. 0.5 DOT
Since shorter names are in short supply, the cost to purchase and maintain them is higher.
ALL REGISTRATION FEES ARE BURNED
Record Types
PNS supports the full set of standard DNS record types including A records, CNAME records, TXT records, MX records, and all other commonly used record types. These work as you would expect them to in any standard DNS implementation.
In addition to the standard record types, PNS defines the following custom attributes specific to the Polkadot network. These fields are designed to support on-chain identity, cryptographic key publication, and ecosystem-specific associations that have no equivalent in traditional DNS.
SS58
Your native Polkadot address in SS58 format. This is the primary resolution target — what most lookups are looking for when they query your name.
RPC
An optional node endpoint address. If your address is associated with a specific node that should be contacted directly, you can publish that endpoint here so applications know where to point their RPC calls.
Validator
An optional slot for publishing your validator identity. If your address is operating as a validator on the network, this field associates that role with your named identity.
Para
An optional slot for associating a parachain with your identity. If your address is connected to a parachain, you can publish that reference here.
Proxy
An optional slot for publishing an associated proxy address. Useful for identity recovery and delegated signing scenarios.
Public Keys (1, 2, 3)
Three numbered, purpose-agnostic public key slots supporting large post-quantum hybrid cipher keys. What you put in them and how applications use them is entirely up to you and the developers building on top of PNS.
Avatar
An optional slot for associating a visual icon or image identifier with your identity. Applications that display named identities can use this to render a profile image alongside your name.
Contract
An optional slot for associating a smart contract address with your identity. If your address has a deployed contract that is relevant to your identity, you can publish that reference here.
Origin
The block hash of the transaction that created or last updated this record. This field is system-generated and cannot be manually set. It is returned with every PNS lookup and allows anyone to independently verify that the record is genuine and was actually recorded on the blockchain by cross-referencing the hash against chain state.
-–
## Summary of Limits
- 1 name per address
- 1 address per name
- 10 subdomain slots per root name, total across all states
- 3 public key slots per address
- Maximum 33 public keys per root namespace