RNS: naming as a safety property on a chain that carries equities

Status

Deployed, unaudited

Licence

MIT

Token

None

Contracts

Nine, live

Introduction

Two distinct problems exist on Robinhood Chain, and the existing literature addresses only one of them.

The first is familiar. A forty character hexadecimal address cannot be read, checked or remembered by a person, so people copy and paste, and pasting is the step at which funds are lost. Naming systems resolve this by mapping a human readable label to an address through a registry any party may read. RNS resolves it the same way, for the same reasons, using substantially the interfaces of ENS^[1].

The second problem is particular to this network and is, we argue, the more serious of the two. Robinhood Chain exists to carry tokenized equities. Every application built upon it therefore requires a mapping from a ticker symbol to the contract address of the corresponding token. Absent a shared registry, each application maintains that mapping privately, pasted into a configuration file. Four applications produce four copies. Copies drift. A single incorrect character in one configuration routes a purchase to a contract nobody controls, and the purchaser has no signal distinguishing the incorrect address from the correct one, both being opaque hexadecimal.

This is not an ergonomics problem admitting a usability fix. It is a correctness problem with funds attached, and a naming layer is the natural site of its resolution.

Architecture

The architecture follows ENS deliberately. Its layering was refined across several years of adversarial pressure, and reproducing it is both cheaper and safer than designing anew. Four components carry the system.

The registry is the root of trust and the smallest contract in the system: a single mapping from namehash to owner, resolver and time to live. It stores no records itself, answering only two questions, namely who owns a node and which contract speaks for it.

The registrar owns the hood node and mints each name as an ERC-721 token^[4], rendering names tradable on any existing marketplace without a bespoke one. Two behaviours matter disproportionately. First, ownerOf reverts once a name has expired, so an expired name never appears owned to a wallet or marketplace. Second, a secondary transfer clears the resolver, so a name purchased on a marketplace cannot arrive still resolving to the seller’s address. The latter is, to our knowledge, the most common mechanism by which users of naming systems lose funds.

The controller is the only contract a buyer interacts with. It carries pricing, referral payment and the commit and reveal flow, and is replaceable: the registrar may revoke it without migrating a single registered name.

The resolvers hold what a name carries: addresses per coin type per ENSIP-11^[2], free form text records, a content hash, and two records particular to this chain, rns.book and rns.ticker.

We omit NameWrapper deliberately. It concentrates ENS’s complexity and much of its bug surface, and its principal feature, permission fuses upon subnames, is not required at launch. Wrapping remains additive should it prove necessary.

Acquisition

Registering a name requires two transactions. The first publishes a hash committing to the label, the owner, the duration, a secret held only in the buyer’s browser, the resolver, the initial records, and whether to set a reverse record. The second reveals the preimage and claims the name.

The interval between them is bounded below at sixty seconds and above at twenty four hours. A single sequencer rollup^[6] presents a less exposed mempool than a public one, but the sequencer is itself a privileged party observing a transaction prior to ordering. The two phase flow removes the possibility of reading a label out of a pending transaction and claiming it first, irrespective of who is reading.

The second transaction performs the entire setup: it mints the token, writes the resolver records, sets the reverse record so wallets display the name immediately, pays any referrer, and refunds overpayment. A name is fully usable when that transaction confirms.

Pricing, expiry and release

Names are denominated in USD by label length and settled in the native asset. One and two character labels are withheld at launch and will be auctioned, so that a market rather than an automated claimant at genesis establishes the floor.

Renewal is permissionless and identically priced. Any party may extend any name. Extending a name cannot harm its owner, so there exists no incentive to gate it, and dependent integrations may keep the names they rely upon alive.

An expired name ceases to resolve immediately, then remains unregisterable for a ninety day grace period during which only its prior owner may renew. Resolution halts at the moment of expiry rather than at the close of grace, so that no party continues sending funds to a name its former owner no longer controls. Thereafter the name enters a twenty one day window carrying a premium beginning at $100,000,000 and decaying to exactly zero. The premium is not a revenue mechanism; its function is to convert the release of a desirable name from a gas price contest into a descending price auction.

The ticker namespace

This is the component without analogue in existing naming systems, and the reason the system is worth deploying upon this network in particular.

At deployment the registry reserved thirty eight listed equity symbols. These labels cannot be registered by any party, ourselves included. A reserved name resolves to the canonical tokenized contract for that equity, and its rns.ticker record carries the symbol together with the issuer’s attestation.

Consuming applications replace a pasted address with a single resolver lookup. Issuers may rotate a contract without every downstream application shipping a release. Most importantly, the failure mode described in section 1 becomes unreachable by accident.

Determining which party may claim a symbol is a governance question rather than a contract one. As that process is not yet specified, the registry presently holds every symbol and releases none. Withholding all of them is strictly safer than assigning one incorrectly whilst the rules remain undecided.

Unresolved assumptions

Homograph resistance

Registration is keyed by labelhash, so the contract cannot observe the string. Normalisation^[3] is therefore a client side convention rather than a chain enforced rule. This is inherited from ENS and constitutes its principal known weakness. Our mitigation is a checker contract and an explicit interface warning upon any label outside plain lowercase ASCII. This is mitigation, not resolution, and the interface states as much rather than implying safety by construction.

Price origination

No Chainlink or Pyth deployment exists upon this network, and no wrapped ether pool carries depth sufficient for a manipulation resistant time weighted average. We therefore operate a push feed at 0x86B5e890…: a keeper posts the median of three public spot markets, the contract rejects any single update moving the price by more than ten percent, and consumers verify the timestamp. A keeper failure renders the feed stale rather than incorrect, whereupon pricing falls back to a timelocked manual rate. We regard this as the honest middle option and note it is a weaker guarantee than an on chain oracle.

Root custody

The registry root, the registrar and the oracle are presently controlled by a single key. The intended path is a multisig, thereafter a timelock, thereafter locking the hood node. Each step is a public transaction. Until those transactions exist, decentralisation is a stated intention rather than an established property.

Economics

Registration and renewal proceeds accrue to a treasury. A referrer address supplied to register receives 5% of the price within the same transaction, being the mechanism by which wallets and applications are compensated for integrating. There is no token and none is planned; a registry does not require one, and stating this plainly is more credible than issuing one for which no use exists.

Implementation

Nine contracts in Solidity 0.8.26, built and tested with Foundry, deployed to Robinhood Chain at network 4663. The suite comprises twenty nine tests weighted towards adversarial paths rather than the happy path: reveal timing at both bounds, commitment replay, expiry and grace boundaries at one second resolution, premium monotonicity across the decay window, resolver clearing upon secondary transfer, record injection against a third party node, refund exactness under fuzzing, reentrancy through the refund call, and reverse record spoofing. Every address is enumerated at rns.hood/contracts.