> ## Documentation Index
> Fetch the complete documentation index at: https://docs.soran.domains/llms.txt
> Use this file to discover all available pages before exploring further.

# Claiming a namespace

> Namespaces are awarded through a public, timelocked claim window — announce with evidence, survive the objection window, and the namespace is yours, irreversibly.

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](https://soran.domains/allocations) — no account needed.

## The window, step by step

<Steps>
  <Step title="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).
  </Step>

  <Step title="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](https://soran.domains/allocations) 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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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:

| Basis                    | What to provide                                                    |
| ------------------------ | ------------------------------------------------------------------ |
| **Registered trademark** | Filing number and jurisdiction                                     |
| **DNS control**          | A TXT record on the matching domain (the console verifies it live) |
| **Commercial first use** | Public evidence of operating under the name                        |

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.

<Note>
  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.
</Note>

## 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](/platform/issuing-names) — with the option to later close the [one-way permanence door](/concepts/ownership-guarantees#make_permanent-the-one-way-door). Nothing about the award can be revisited: not by an objector, not by governance, not by Soran.