v1 state

pendingAction

pendingActions

// id -> \*pendingAction

maxPendingActions

actionWindow

maxActionIDLen

minActionWindow

maxActionWindowS

getAction

assertActionID

ProposeAction

ProposeAction starts the clock on one admin action. Proposing an id already pending restarts its clock: the latest proposal is the one that must survive its window.

CancelAction

CancelAction withdraws one pending action. Admin or recovery: the admin changing its mind, or recovery vetoing a key it no longer trusts.

CancelAllActions

CancelAllActions withdraws every pending action at once — the incident call, when nobody wants to read a list before acting. From recovery it is a veto: the admin proposes no action for one timelock.

ConsumeAction

ConsumeAction spends a matured action. Trusted logic only, so it is also gated by the pause: a paused registry executes nothing, timelocked or not. It refuses an action proposed by anybody but the CURRENT admin. Rotation already drops them all; this is the second lock on the same door, because a matured proposal is a loaded instruction and the vault should not rely on one rule to unload it.

ActionReady

ActionReady reports whether an action could be consumed right now.

GetAction

GetAction reports a pending action: when it matures, when it expires, and who proposed it. All zero when nothing by that id is pending.

ListActions

ListActions pages through pending action ids, ONE PER LINE: an id may contain commas (a price rule does), never a newline.

GetActionWindow

SetActionWindow

SetActionWindow sets how long a matured action stays executable, between an hour and ninety days.

pruneExpiredActions

pruneExpiredActions frees the slots of actions nobody can execute any more. Bounded by maxPendingActions.

dropAllActions

isFresh

isFresh reports whether a name's profile data belongs to the token's CURRENT ownership epoch. See Name.epoch and freshen.

freshAt

freshAt is isFresh with the ledger's answer passed in. See freshenTo.

ownsNow

ownsNow reports whether \`addr\` holds the token right now, per the ledger.

isValidNow

isValidNow / isReclaimable are pure integer math over \`termLength\` and \`gracePeriod\`, both of which are settable — so the lifecycle rules themselves can be retuned after deployment. All times are unix seconds.

isReclaimable

isReclaimable compares the elapsed time with the grace period instead of adding the grace period to the expiry. The sum wrapped: an expiry of math.MaxInt64 — the natural "never expires" value — read as valid AND reclaimable at once, and a stranger could take the name (audit L-2). A name that has not expired is never reclaimable, whatever grace says.

streakOf

streakOf derives how many whole terms a holder has actually lived through, replacing the counter that used to be stored on the record. The stored version counted RENEWAL CALLS, so it measured transactions rather than time: prepaying five years bumped it five times on a name registered that morning, and an earlier version could be run up arbitrarily by calling renew in a loop within one block. Deriving it from the registration date makes it unbuyable by construction — the only way to increase it is for time to pass — and it resets on its own when a lapsed name is reclaimed, because a reclaim writes a fresh record with a new \`registered\`. termLength is settable and could legitimately be zero, which would otherwise divide by zero in a realm that cannot be redeployed.

assertIsTrustedLogic

assertIsTrustedLogic is the gate on every mutation function below. cur.Previous().Address() resolves to the CALLING realm's own address when invoked via cross(cur) from another realm — same idiom already used for assertIsAdmin, just checking a different address. A stray call from anywhere else (a different realm, a direct user tx trying to call these directly) is rejected.

nameTreeKey

nameTokenID

domainRange

domainRange returns the \[start, end) key bounds covering exactly the names stored under \`domain\`. '+' (0x2B) is the next byte after '\*' (0x2A), so \`domain+"+"\` sorts immediately past every \`domain+"\*"+...\` key while still sorting before any longer domain (e.g. "meme+" falls between "meme\*zzz" and "memes\*a").

accountKey

accountKey is the per-address store's key: the address, a colon, the field. A bech32 address never contains ":" and a field may not (see assertAccountKey), so the split is unambiguous, and every field of one address sorts into one span.

accountRange

accountRange bounds exactly one address's fields. ';' (0x3B) is the byte after ':' (0x3A), the same trick domainRange plays with '\*' and '+'.

splitTokenID

splitTokenID splits a \`label\*domain\` TOKEN ID. Do not use it on a storage key — see the ordering note above.

mustGetDomain

getDomain

mustGetName

getName

clearPrimaryIfPointingAt

clearPrimaryIfPointingAt drops \`owner\`'s reverse-resolution pointer when (and only when) it still points at \`tid\`. Called on every ownership change — transfer and reclaim. Without this, \`primary\` was a write-only tree: it had a Set path and no Remove path anywhere in the realm, so selling or losing a name left the previous holder permanently reverse-resolving to a name somebody else now owns. Reverse resolution asserting ownership that is no longer true is the one thing a name service must never do.

emitBy

i64

boolStr

emitConfig

emitConfig is the one event for every typed vault setting.

maxPage

pageKeys

pageKeys walks a key span and returns up to \`limit\` keys after the \`after\` cursor, plus the cursor to pass next (empty when exhausted).

ExportDomains

ExportDomains pages through every domain label.

ExportNames

ExportNames pages through every name in the registry, as raw storage keys (\`domain\*label\`). Pass an empty domainLabel to walk the whole tree, or a domain to walk just that domain's span.

ExportPrimary

ExportPrimary pages through the reverse-resolution table as owner addresses; pair with GetPrimary to read each value.

ExportGlobalKeys

ExportGlobalKeys lists the package-level extension slot's keys; pair with GetGlobal for values.

ExportAccounts

ExportAccounts pages through the per-address store as raw keys \`\<address>:\<field>\`; pair with GetAccount for each value. Field names are comma-free by construction (see assertAccountKey).

AccountCount

AccountCount is how many per-address fields exist, so a snapshot of the store can be checked for completeness. A separate read rather than a fifth value from Sizes, whose shape the snapshot tools already parse.

ExportDomainExtraKeys

ExportDomainExtraKeys / ExportNameExtraKeys list a record's extension keys so a snapshot can capture data this realm has no schema for. Keys are comma-free by construction (see assertExtraKey), so a CSV listing is unambiguous.

ExportNameExtraKeys

A previous holder's keys are not exported. A snapshot that captured them would carry the seller's payment addresses into a restore as the buyer's.

Sizes

Sizes let an operator verify a snapshot is complete rather than trusting that pagination terminated correctly.

genesisDomainTerms

Genesis domains get a long runway. They are project-owned and all created in the same block, so a single term would have every one of them lapse on the same day a year later — and a lapsed domain refuses every registration under it. Renewing them is still the admin's job; this just stops the first renewal being a cliff.

refusedInGenesis

refusedInGenesis names what may never be baked into a registry's birth. Anything whose VALUE is an address: a key that holds power — the free-tier granter was the one that shipped by accident — is set deliberately, after deploy, on the chain it belongs to, never inherited from whatever chain a snapshot was taken on. And the lab nomination, which belongs to a sandbox generation and would otherwise let a hand-edited data file ship a lab on a real domain. No regexp: one compiled pattern costs more storage than this whole file.

looksLikeAddress

genesisCfg

genesisDomain

applyGenesis

genesisConfig

genesisGlobals

genesisDomains

pendingOp

Governance and emergency response for a realm that can never be redeployed. Everything here is callable ONLY by a direct wallet transaction — never through a logic realm — so a compromised or buggy logic realm can never touch it. Three powers, deliberately not held by the same key: admin — day-to-day authority: grants/revokes logic realms, tunes config. The warm key. recovery — cannot operate the registry at all. Can only rotate admin, cancel a pending change, revoke a logic realm, and pause. MUST be a multisig in production; see the trust note below for why that is not optional. guardian — can ONLY pause. Nothing else. Safe to keep hot (a monitoring bot), because its compromise costs an outage, never the registry. GRANTING POWER IS SLOW, REVOKING IT IS INSTANT. Handing authority to a new admin or a new logic realm goes through a timelock, and so — since actions.gno — does every admin action in the logic realm that destroys or moves names or money (deletion, lifecycle and treasury changes, unfreezing, reassigning, pricing rules, large price moves). Revocation, cancellation and pause are immediate; undoing a pause takes recovery or the timelock. An attacker holding one key cannot act instantly: they must announce and wait, and every step emits an event. EACH ROLE CAN ROTATE THE OTHER, AND THE ADMIN CANNOT VETO ITS OWN REPLACEMENT. A rotation recovery proposes — of the admin, or of itself — can be cancelled or displaced only by recovery. An admin-initiated rotation of recovery is the admin's to withdraw and, since the re-audit of 2026-10-16, recovery's to veto too: recovery is the root (see the trust note below), and a veto it could not send in its incident sitting reverted the whole sitting, eviction included. A LOST recovery cancels nothing, so the admin can still replace it. Proposals live in PER-KIND slots so an admin rotation and a recovery rotation can never contend for the same slot — an earlier single-slot design let one in-flight proposal freeze the entire governance surface, which meant the honest key could not even propose a response. THE TRUST ASYMMETRY, chosen rather than papered over. Both roles rotate the other on the same timelock, and it used to be that whichever proposed FIRST matured first and won — so a thief holding the admin key, acting before anybody noticed, could take recovery too. Since the re-audit of 2026-10-16 (M-1) RECOVERY WINS: once recovery's eviction is pending, nothing the admin proposed executes before it, a rotation of recovery the admin queued earlier included, and the eviction drops all of it. Every asymmetry hands the mirror-image power to whoever steals the favoured role, and this one is deliberate, the same as the ledger's (nsnft governance.gno): a stolen RECOVERY key now beats an honest admin, which is why recovery must be the cold multisig and the admin the key that is used. The mitigation is therefore operational as well as contractual: - recovery MUST be a multisig, so no single stolen key can use it; - timelockDelay must be long enough that you will actually notice an event within it; - watch for GovernanceProposed and ActionProposed and treat one you did not initiate as an active incident. THE INCIDENT RUNBOOK, in this order (MAINNET.md §1b has it in full). First RevokeTrustedLogic on every entry of ListTrustedLogic(): guardian, admin or recovery may, it is instant, and re-granting needs the timelock, so no stolen key can switch the logic back on. Then Pause, and Disarm (incident.gno). Then, from recovery: the counter-rotation FIRST and alone — proposing it drops everything the admin had pending — then VoidGrantsSince and SetQuarantine (incident.gno), and CancelAllActions / CancelPending on anything left, which cannot revert; execute the eviction at maturity, before anything else. Pause does NOT stop ExecutePending — it stops registry mutations, which limits damage but does not stop a rotation. Do not rely on it for that. RECOVERY'S EVICTION LANDS FIRST, by rule (re-audit 2026-10-16, M-1). An eviction used to drop the admin's plans only when it executed, and anyone chose the order matured proposals ran in: the thief could re-propose a cancelled grant the block after recovery's sitting, or execute recovery's own move to a new cold key first, which dropped recovery's eviction. Now: recovery proposing the eviction DROPS everything the admin had pending — grants, delay, unpause, a rotation of recovery, every timelocked action — so nothing of the admin's is held to spring back if the eviction is cancelled; while it is pending (EvictionPending) the admin proposes nothing, nothing it proposed may execute, and logic can spend none of its actions; a veto holds: what recovery cancels of the admin's, the admin may not propose again for one timelock (any action, after an action veto), so the sitting cannot be re-proposed around; recovery's eviction landing clears the vetoes, and nothing else does; recovery moving ITSELF keeps its eviction: the eviction is protected by the recovery role, which the new key holds, and recovery's rotation of itself is recovery's alone to cancel or displace. Only an admin-initiated replacement of recovery drops the replaced key's eviction. recovery's cancellations are idempotent: cancelling what is no longer pending does nothing, so a thief withdrawing its own proposal first cannot make recovery's batched sitting revert.

recovery

guardian

paused

timelockDelay

maxTimelockDelay

absoluteMaxTimelock

pendingOps

successor

vetoUntil

assertIsAdmin

assertIsAdminOrRecovery

assertCanPause

Pause

Pause halts every registry mutation, timelocked actions included. Reads are unaffected, so names stay resolvable while writes are frozen. It deliberately does NOT gate ExecutePending: governance must keep working during an incident — recovery's counter-rotation above all. A pause also drops a pending admin-proposed unpause, so the guardian bot can hold the registry paused against a stolen admin key simply by pausing again whenever it sees UnpauseProposed.

Unpause

Unpause restarts the registry at once, and only RECOVERY may do that. It used to be open to the admin too, which made a pause useless against the key most likely to be stolen: the admin could unpause in the same multi-message transaction as whatever it did next, so a pause stopped only writers that did not hold admin. An audit showed it. The admin can still unpause — ProposeUnpause, then the timelock — so a false alarm costs a delay rather than the cold key; recovery can cancel that proposal, and any new pause drops it. The guardian is excluded as before: a hot key that can stop the system must not also be able to restart it.

ProposeUnpause

ProposeUnpause is the admin's way back from a pause: a proposal like any grant of power, executable by anyone once it matures.

IsPaused

IsTrustedLogic

ListTrustedLogic

RevokeTrustedLogic

RevokeTrustedLogic is INSTANT and available to the guardian, because cutting off a misbehaving logic realm is the emergency action that must never wait on a timelock.

ProposeAdminTransfer

ProposeAdminTransfer starts an admin rotation. When recovery initiates it, only recovery may cancel it — the admin being replaced gets no veto over their own replacement.

ProposeRecoveryTransfer

ProposeRecoveryTransfer is the mirror image: when admin initiates it, only admin may cancel it, so a compromised recovery key cannot block its own replacement either.

ProposeTrustedLogicGrant

ProposeTimelockDelay

ProposeTimelockDelay is bounded on BOTH sides. An unbounded delay would let a single execution stamp every future proposal with an unreachable maturity, permanently disabling governance in an unredeployable realm.

SetMaxTimelockDelay

SetMaxTimelockDelay raises or lowers the ceiling on timelockDelay. Bounded by absoluteMaxTimelock, and it cannot be set below the delay currently in force.

canControl

getPendingOp

EvictionPending

EvictionPending reports a pending rotation of the admin that recovery proposed while the two roles are separate keys: recovery replacing an admin it no longer trusts. See the note above pendingOp.

adminAlone

adminAlone: the address is the admin and not also recovery — the case every eviction rule is about. While one key holds both, nothing is.

assertAdminMayPropose

assertAdminMayPropose refuses the admin while recovery is replacing it, and for one timelock after recovery vetoed a proposal of this kind.

veto

veto starts the cooldown on a kind, when recovery has just cancelled something the admin proposed.

setPending

CancelPending

CancelPending cancels the pending change of one kind. A proposal with a protectorRole can be cancelled only by that role, so a compromised key cannot veto its own replacement.

ExecutePending

ExecutePending applies a matured change. Callable by anyone on purpose: execution must not depend on a particular key still being available, since key unavailability is one of the things being recovered from. It only applies what was already proposed and survived its window.

dropPendingProtectedBy

dropPendingProtectedBy removes the pending change of \`kind\` when it is protected by \`role\` — used when that role's key has just been replaced.

adminOnlyKinds

adminOnlyKinds are the proposals only the admin can make. Every one of them dies when the admin rotates: whoever proposed it no longer holds the key that could, and an eviction that leaves the evicted key's plans running has not evicted anybody.

dropAdminProposals

GetPending

GetPendingDetail

GetPendingDetail is GetPending with the rest of the proposal: the delay a "delay" proposal would install, in seconds — which GetPending could not show, so "set the delay to zero" and "raise it" looked identical — and who proposed it.

ListPending

SetGuardian

SetGuardian takes the RECOVERY key, to seat a guardian as much as to replace one. Replacing took recovery from the start: otherwise the first move of anyone who steals the admin key is to point the guardian at themselves, disarming the emergency stop before you can use it. Seating an EMPTY seat used to be the admin's too, and that was the same hole: a stolen admin key seated its own bot, and after its eviction that bot could still pause and revoke, removable only by recovery (re-audit 2026-10-16, L-4). The deploy seats the guardian while its key still holds recovery.

ClearGuardian

ClearGuardian stands the pause capability down. "Removing a power is never the dangerous direction" was the old reasoning here, and it is wrong in one specific way: removing this power restores the state in which SetGuardian is admin-callable. SetGuardian demands the RECOVERY key whenever a guardian is already set, and says why — a stolen admin key must not be able to disarm the emergency stop. ClearGuardian then SetGuardian was a two-transaction admin-only replacement of a live guardian, which defeats exactly that rule. So standing down a LIVE guardian now takes the same key that replacing one takes. Clearing when there is no guardian stays open to either role, because then there is nothing to defeat. The practical stakes are small — assertCanPause admits admin, recovery and guardian, so an operator holding recovery keeps Pause and RevokeTrustedLogic either way. It is fixed because this realm can never be redeployed, and a documented authorization rule that a two-call sequence walks around is not something to leave in permanent code.

SetSuccessor

SetSuccessor records where this registry moved, if it ever has to be abandoned. Pair it with Pause() so the retired registry cannot drift away from the snapshot its successor was built from.

GetAdmin

GetRecovery

GetGuardian

GetSuccessor

GetTimelockDelay

GetMaxTimelockDelay

disarmKeys

disarmKeys are the globals whose presence is a power and whose absence is the safe reading (nslogic: credits.gno, freetier.gno, keeper.gno).

maxGrantVoids

// void windows kept; the oldest two merge past it

maxQuarantine

// the furthest a quarantine may reach, in seconds

grantVoids

quarantineUntil

assertIsRecovery

Disarm

Disarm deletes the claim window, the granter and the keeper at once. Admin, recovery or guardian, as a direct wallet call; it works while the registry is paused and with every logic realm revoked.

VoidGrantsSince

VoidGrantsSince voids every grant made at or after \`since\`, up to now. Recovery only. \`since\` may be 0 (everything so far) and may not be in the future. The window joins the ones already in force; past maxGrantVoids the two oldest merge, which can only void more, never less.

insertVoid

insertVoid keeps the windows sorted by start and folds overlapping ones together, so "the gap between two windows" means what it says.

GrantVoided

GrantVoided reports whether a grant made at unix second \`at\` falls inside a void recovery declared.

GrantVoids

GrantVoids lists the void windows, "from-to" comma-separated, oldest first.

SetQuarantine

SetQuarantine holds every giveaway shut until \`until\` (unix seconds), at most maxQuarantine ahead; 0 lifts it. Recovery only.

QuarantineUntil

QuarantineUntil is the unix second giveaways may run again, 0 for none.

Quarantined

Quarantined reports whether a quarantine holds right now.

isTokenValid

BalanceOf

BalanceOf counts every token an address holds — including free-tier tokens, which are held rather than absent. That is a real change from the previous generation, where a free name had no token and counted for nothing; nsvote gates on this, so free-tier holders now have a vote.

OwnerOf

GetApproved

IsApprovedFor

IsApprovedFor is the question a marketplace actually has: may this operator move this token, by either route?

IsApprovedForAll

TokenURI

TokenURI returns a pointer at whichever view realm renders the art. nsnft has its own URI base for external marketplaces; both are set to the same view realm at wiring time.

ListDomains

ListNames

ListNames and CountNames scan only the key span belonging to \`domainLabel\` (see domainRange in auth.gno), costing O(names in that domain) rather than O(every name in the registry).

CountNames

CountDomains

DomainExists

NameExists

GetDomainOwner

GetNameOwner

GetDomainInfo

GetDomainInfo / GetNameInfo return a whole record in one call, so a view realm can render a page without six round trips. Timestamps come back as unix SECONDS. They used to be time.Time, which vm/qeval rendered using gno's internal epoch, so every consumer had to know to subtract 62135596800 — our own frontend did exactly that. Returning unix seconds stops leaking that offset into every integration, and it is what the records now hold anyway. \`streak\` is computed from the registration date rather than read from a stored field. See streakOf.

GetNameInfo

GetNameInfo keeps its six-value shape so every existing reader — nslogic, nsview, nsskin, nsvote, the site, both snapshot tools — goes on parsing it unchanged. Two of the six are now answered differently: owner is read from nsnft, never stored here. The snapshot tools record whatever this returns, so they now record the real owner — the restore-hands-sold-names-back bug the first attempt had cannot happen, because there is no stale copy for them to read. paid replaces isNFT and means exactly one thing: the name is NOT held as an un-upgraded free-tier record. It is deliberately not "transferable" — a frozen paid name is locked too, and reading the lock would have made a frozen paid name look free, which is precisely the proxy bug that let free renewals renew paid names.

GetNameTTL

GetNameTTL / GetDomainTTL report how long a resolver may cache an answer about this record, in seconds, where 0 MEANS NEVER CACHE — the ENS registry's rule, deliberately, so integrators need not read anything of ours to handle it correctly. A TTL written for a previous holder is not this holder's cache policy. A stale one reads as 0 — never cache — which is the safe answer during exactly the window after a sale when a cached answer pays the seller.

GetDomainTTL

GetNameHeldSince

GetNameHeldSince is when the current holder's holding began, in unix seconds — or 0 when the ledger has moved on since this registry last saw the record (a sale it has not yet observed). It can understate a holding, never overstate one. See Name.since.

RestoredFor

IsNamePaid

IsNamePaid reports that a name is not held as an un-upgraded free-tier record. See GetNameInfo on why this is not "transferable".

IsDomainValid

IsNameValid

GetDomainExtra

GetNameExtra

GetNameExtra answers EMPTY for data written in a previous ownership epoch. This is the read half of the lazy wipe. A sale that settles on nsnft — through our marketplace or anybody else's — never calls this realm, so nothing here can clear the seller's payment addresses at the moment it happens. What this CAN do is refuse to repeat them: the instant the ledger's epoch moves, every extra on the name stops answering, for every reader, before anybody has written anything. The write half, which destroys the stale data rather than hiding it, is freshen in write.gno. Both halves are needed: hiding alone is what the first attempt shipped, and the buyer's first edit brought the seller's Bitcoin address back as the buyer's.

GetGlobal

GetAccount

GetAccount reads one field of an address's own record, or "" when it has none. See \`accounts\` in types.gno.

GetPrimary

GetPrimary is a raw pointer lookup. It reports what an address last SELECTED, not what it still owns — callers presenting this as reverse resolution must re-check ownership (see nslogic.ResolveAddress).

GetTreasury

GetTermLength

GetGracePeriod

GetMaxDeletePerCall

GetLabelPattern

GetLabelLength

GetTokenURIBase

GetExtraLimits

GetGlobalEntryLimit

GetAccountLimits

Render

The real human-facing view moved OUT of this realm into \`nsview\` (2026-08-21), after an adversarial review found three separate defects in the old Render() — unescaped profile-field injection into the markdown, an O(domains × names) home page any user could inflate into a permanent DoS, and links that 404'd — none of which could ever be fixed, because this realm is deployed once and never replaced. The lesson generalised: "it's only display code, it has no authorization surface" was the wrong test for what belongs in an immutable realm. The right test is whether a bug in it would be permanent. Display code changes far more often than storage schemas do, so it belongs in something swappable. What remains here is deliberately a fixed string: no user-authored data, no iteration over state, nothing that can be wrong later.

Domain

Timestamps are unix SECONDS, not time.Time, and that is the single biggest storage decision in this file. Measured on three throwaway realms (MAINNET.md §3d-i): two time.Time fields were 70% of a record, because each carries an unused nanosecond field and a \*Location pointer for a value that is always UTC. Switching to int64 takes a real 7,385-byte domain record to 6,246 bytes on its own, and turns every lifecycle comparison into integer arithmetic. Nothing here stores a label. The AVL key already holds it — \`label\` for a domain, \`domain\*label\` for a name — so a copy inside the record was paying storage forever to duplicate the thing used to find it.

Name

Name has NO OWNER FIELD, and that absence is the whole design. The first attempt at moving ownership into a token realm kept a copy of the owner here, and every bug it had followed from the copy: renewal checked the copy and refused the real owner after a sale, snapshots recorded the copy and would have handed sold names back to their sellers on restore. There is one owner and it lives in nsnft. Every read asks it. It also has no isNFT flag. Every name is a token; a free-tier name is a token with a hold on it (lockBitFree). Four separate places used to read "has no token" as "is free", and deleting the flag deletes that class of bug rather than fixing four instances of it.

lockBitFree

// free tier, not yet paid for: not sellable

lockBitFrozen

// frozen by an admin: not movable while disputed

domains

names

primary

globals

accounts

admin

// the vault door — see governance.gno for the full role model

trustedLogicSet

treasury

termLength

gracePeriod

labelPattern

minLabelLen

maxLabelLen

maxExtraKeyLen

maxExtraValueLen

maxExtraEntries

maxGlobalEntries

maxAccountKeyLen

maxAccountValueLen

maxAccountEntries

maxDeletePerCall

tokenURIBase

init.191

RegisterDomainRecord

ReassignDomainRecord

ReassignDomainRecord moves a domain to a new owner and leaves its configuration exactly where it was. This is the durable fix nslogic.ReassignDomain's comment was waiting for. The old path moved a domain through the name-transfer machinery, whose wipe exists to clear a SELLER'S payment addresses — and so it silently reopened closed domains, dropped their pricing to the default and released their term caps, during the key-compromise recovery it exists for. A domain's extras are its settings, not a previous holder's data, and there is no previous holder: domains never reach a third party. TTL resets, because it is the one field that is a caching promise made by whoever held the record.

RenewDomainRecord

advanceTerm

advanceTerm extends a term by exactly one term-length from its PREVIOUS due date — never from \`now\`, because the grace period must not silently extend the term somebody paid for. It no longer returns a streak. The streak used to be maintained here, with a guard against renewing repeatedly in one block to inflate it; that whole class of problem disappeared when the streak became a function of the registration date instead of a stored counter. See streakOf in auth.gno.

SetDomainFrozen

SetDomainExpiryRecord

SetDomainTTLRecord

SetDomainTTLRecord sets how long a resolver may cache answers about this domain, in seconds, where 0 means never cache. See Domain.ttl.

SetDomainExtraRecord

SetDomainExtraRecord writes one arbitrary key on a domain — pricing, or whatever a future logic realm needs. An empty value deletes the key, so storage can be reclaimed.

DeleteDomainRecord

DeleteDomainRecord destroys a domain and the names beneath it: it burns every token, drops every reverse-resolution pointer into them, removes the records, and finally removes the domain itself. WHY IT EXISTS. Retiring a domain after a brand complaint, recovering the storage deposit on a domain that never sold, and clearing out fad domains nobody renewed. A logic realm cannot provide any of this, because the vault owns the trees and exposed no delete path — the only Remove call for a domain lived inside RegisterDomainRecord as the evict-and-replace step of re-registration. IT DELIBERATELY WORKS ON A DOMAIN WITH LIVE NAMES UNDER IT. The case this exists for is a demand to remove a domain entirely, where waiting for names to lapse is not an option. Compensating the holders is handled off chain and is deliberately not a contract concern. WHERE THIS DEPARTS FROM THE SPEC, stated plainly because it is a real difference: MAINNET.md §3d asks for all of it "in one call". It is bounded instead, deleting at most maxDeletePerCall names per call and reporting whether it finished. An unbounded loop over a tree that may hold any number of names is a transaction that stops fitting in a block once a domain gets popular — which would mean the domains most likely to attract a complaint are exactly the ones that could never be deleted, in a realm that can never be fixed. The caller repeats until \`done\`; for any domain of realistic size that is one call, so the no-preconditions requirement is preserved. What is NOT preserved is atomicity: a multi-call deletion is visible half-done between calls. Freeze the domain first if that matters, so nothing new lands under it meanwhile. Not Pause(): a paused registry deletes nothing at all, since this passes the same trust gate as every write. Calling it on a domain that does not exist is a no-op reporting done, so a repeat loop terminates cleanly rather than panicking on the call that follows the last one.

RegisterNameRecord

RegisterNameRecord creates \`label\*domain\` and mints its token in nsnft. \`paid\` false registers a FREE-TIER name: the token is minted with the free hold already set, so there is never an instant in which it could be approved and sold before a lock arrived. There is no longer any such thing as a name without a token — see Name. RECLAIM burns the previous holder's token first. The owner is read from the ledger, never from the record, because the record has no owner. AN ORPHAN TOKEN IS REFUSED. A token that exists with no record behind it means a registry swap is mid-migration or something has gone wrong; either way, registering over it would mint a second claim to a name somebody already holds. RestoreNameRecord is the door for adopting one.

holdBits

setPrimaryIfNone

setPrimaryIfNone gives an address a reverse pointer when it has none — or when the one it has points at a name it no longer holds. The second half is new. A pointer used to be cleared on every transfer, because transfers went through this realm. They no longer do: a sale that settles on nsnft leaves the seller's pointer aimed at a name they sold. nslogic.ResolveAddress already refuses to answer with it, so it never misleads anybody — but left in place it also blocked the seller's NEXT registration from becoming their primary, which would have looked like a bug in registration rather than a stale pointer.

UpgradeFreeRecord

UpgradeFreeRecord lifts the free-tier hold — the paid upgrade. Preserves the dates: this is not a re-registration. \`newOwner\` exists because the common case is somebody who decided to sell and, in the same moment, wants the name in a wallet they control rather than the key they were given. That move is a burn and a mint here, because a held token cannot be transferred by design. THE PROFILE DOES NOT GO WITH IT, and it used to. The move re-stamped the old data to the new epoch and gave the recipient a reverse pointer — and \`newOwner\` can be ANY address. An audit spelled out the attack: fill a free name's profile with your own pay addresses, pay list price to upgrade it into a victim's wallet, and the victim's name now asks people to pay you, their address reverse-resolves to it, and their own later edits do not clear it because the epoch is already current. So the data is left in the previous epoch, where every read hides it and the next write destroys it, and the recipient gets no pointer they never chose. A person moving their own name to a new wallet re-enters their profile once; that is the price of the move not being usable against somebody else. Refused for a frozen name. Upgrading must never be the way a disputed name gets out of its hold.

RestoreNameRecord

RestoreNameRecord is the migration door: records move, tokens do not. A registry swapped in behind the same nsnft finds tokens that already exist. This writes the record for one and ADOPTS its token, or mints one when the ledger has none. It never moves a token: a snapshot must never take a name from its current holder. WHEN THE LEDGER DISAGREES WITH THE SNAPSHOT, IT WINS. This used to refuse, and an audit showed where refusing leads: a name sold between the snapshot and the restore panics the batch, gets dropped to finish the rest, and the window seals — leaving the buyer's token with no record behind it, unable to be renewed, resolved or registered, forever. So the record is written for whoever holds the token now, and the snapshot's profile data is NOT replayable onto it (restoredFor stays empty), because it was the seller's. Gated like every write, and nslogic only reaches it through the restore window, which is one-shot.