Skip to main content
Nobody hands out namespaces in private. Every claim runs through the same public process, on chain: announce → objection window → execute. Once a namespace is awarded it is immutable and permanently the claimant’s — the allocation authority has no power over it from that moment on. Disputes are settled before allocation, never after. You can watch every pending claim, with its evidence, on the public allocation queue — no account needed.

​
The window, step by step

1

Announce

You post the claim publicly on chain: the label, your claimant address, and your evidence basis. Signing is a normal wallet transaction — through the hosted console’s wizard, or self-custodied (the API can prepare an unsigned announce transaction for your own key).
2

The objection window

A fixed window opens — the contract enforces a minimum of one day, and each deployment sets its own length: one day on testnet, five days on mainnet. The allocation queue shows the live countdown on any claim. During it, anyone may object by posting a bond and a competing basis. An objection freezes the clock until it’s ruled on. You can start integrating while the window runs; you just can’t execute yet.
3

Execute

Once the window elapses unopposed, execute is permissionless — anyone can trigger it (the hosted deployment does it for you). The claim calls the immutable Registry’s allocate, the namespace node is written to your address, and the allocator’s power over it ends permanently.

​
Objections and adjudication

Objections are bonded so they cost something, and adjudicated so they resolve:
  • Anyone except the claimant or the adjudicator may object during the window, with a bond and a stated basis.
  • Upheld objection: the claim is rejected and the objector’s bond is refunded. The rejected claimant is barred from re-announcing that label; after a 30-day cooldown, other claimants may — a rejection never locks a label away forever.
  • Dismissed objection: the bond is burned (never paid to anyone — no address can profit from dismissals) and the claim’s window resumes.
  • Adjudication has a deadline. If no ruling lands within 30 days, a permissionless timeout resumes the claim, settled as a dismissal. Adjudicator inaction cannot freeze a label indefinitely.
  • Objection cycles are capped per label, so a claim can’t be frozen by an endless dismiss-and-re-object loop.
Claims also lapse: an announced claim that is never executed eventually expires and anyone may clear it, so labels can’t be parked for free.

​
What evidence helps

Attach at least one basis when you announce; stronger evidence wins if anyone objects. The console’s wizard collects: A trademark or a verifiable TXT record on yourbrand.com makes an objection against yourbrand an uphill argument. Evidence goes on chain with the claim, in public, where objectors and the adjudicator can weigh it.

​
Reserved labels

Some labels follow a different path. At Registry deployment, a set of reserved labels — launch partners, known brands — was committed into an immutable merkle root. Reservation is not ownership: it constrains how the label can be placed, for everyone, including the platform. Reserved labels come in two kinds:
  • Bound — reserved for a specific address, which can claim directly with a merkle proof, bypassing the claim process entirely. While a bound reservation is active, the label can’t be announced through the open window at all — only its reserved address can claim it. The strongest guarantee a launch partner can hold.
  • Unbound — goes through the same public announce → objection → execute window as any other claim; the only difference is that the allocation must carry the label’s membership proof instead of a not-reserved proof. Governance rules only if someone objects, exactly as for unreserved labels — and the evidence table above is exactly what an objection would weigh.
A bound reservation may carry a fallback deadline: if the reserved party has not claimed by then, the direct-claim path closes and the label reverts to the public claim window, open to anyone. Reservations without a fallback deadline never lapse. Launch partners should confirm which kind their leaf is — and claim before any fallback date.
A quick first check: await soran.isAvailable("yourbrand") tells you whether the namespace is unowned on chain. Reserved-but-unclaimed labels also read as available, and the check is blind to rival claims mid-window — the console additionally checks the reserved list and whether a rival claim is already in its window.

​
After the award

The namespace node in the Registry now lists your address as owner. From here you deploy your Registrar (policy, issuance), point your resolver, and start issuing names — with the option to later close the one-way permanence door. Nothing about the award can be revisited: not by an objector, not by governance, not by Soran.