How a claim is made

A single Gold server record holds the canonical entry for every domain.name. IANA names always take precedence at the resolver.

High-level flow

1. ISP proves IP-block control
   → reverse DNS (ARPA) TXT record + hairpin verification
   → Gold server mints scarce claim tokens to the ISP

2. Human associates with one ISP
   → humanity verification (Worldcoin-style or approved oAuth)
   → receives / wraps token for the request

3. ISP submits uCRS on behalf of the human
   → public justification (GitHub PR, profile, post, etc.)
   → stake committed

4. Gold server (or agent) evaluates
   → free vs paid/premium decision based on evidence
   → records single canonical claim if accepted

5. Renewal
   → term lengthens with demonstrated legitimacy
   → justification must remain valid
   → blocked if competing claim or open dispute exists

uCRS (UCAN Claim-Request-Staking)

The uCRS is the on-chain or control-plane transaction that requests a name, commits stake, and points to the public justification. Tokens committed in a failed contest are lost; successful ones remain staked behind the final Gold claim.

When a name is already claimed, a challenger can file a uCRS immediately. This registers a case and notifies the current holder that their next renewal will be contested unless the situation changes. The holder sees the challenger’s justification and humanity indicator and must decide whether to strengthen their own material or risk their stake.

Smart-contract concepts

Token minting, wrapping, expiration, uCRS commitment, stake return or loss, and dispute escalation are intended to be expressed as smart contracts (chain-agnostic where practical). Exact semantics are open for contribution.

See also the escalation levels and the draft specification in the protocol repository.