Trust model

Soran reads namespace ownership, name lifecycle and payment instructions from contracts on Stellar. Universal Lookup brings those reads together for your app. You rely on the deployed code, its governance rules and the RPC that returns its results.

​

Contract authority

Registry records namespace ownership and routing. The current allocation rules prevent Allocator from overwriting an owned namespace. Registry itself supports governance-authorized code upgrades: those rules are properties of the deployed implementation, not an immutable promise about future code. Namespace owners control issuance, supported-network policy, subname policy and owner-authorized Registrar and Resolver upgrades. An upgrade requires approval for the exact implementation and contract role. Holders control their records and permitted transfers. A subname is controlled by its parent holder; its recipient gains no editing rights. The governed testnet does not allow new permanent code locks. A name having no expiry does not remove reclaim or upgrade powers. Ownership guarantees separates these properties and explains historical locked deployments. Universal Lookup is governed separately. Its code can change immediately after governance approves an exact code hash, while its address remains the same. See governance and upgrades.

​

What reads verify

Universal Lookup follows current Registry routing and checks the supported contracts, name activity, ownership generation and complete payment instruction. Subnames also depend on their parent generation and namespace policy. Additional network addresses require an explicit network choice and an enabled namespace policy. If a configured instruction is missing or invalid, the read fails. Metadata methods let you inspect ownership even when payment resolution fails. Reverse and Primary answers must match current forward resolution. G/C elections identify an account without distinguishing customer memos. Each complete M address has its own election, with no fallback to its base G account or another routing ID. These elections establish a selected display name, not a person’s identity. An empty identity result means no verified election was returned. The underlying G/C contracts can return None when an internal proof fails, so emptiness alone does not explain why a name was unavailable. Handle reported read errors separately. The SDK checks Lookup’s Registry address and interface version. These checks establish compatibility; they do not verify every behavior of upgraded or custom code. Configure the intended network and RPC. Separate SDK calls can observe different ledgers, while reads within one contract invocation share a simulation snapshot.

​

Hosted discovery and history

The indexer finds names and archives events. The SDK checks current holdings candidates on chain, but discovery can still miss names. Follow pagination and inspect coverage and freshness when using listings or history. Directory listings, history and profile text provide context. User-authored profile claims are not verified just because they are stored on chain. Escape displayed text, validate links and treat profile content as data.

​

Hosted services and custody

The console, HTTP API, webhooks and optional managed services help operate the contracts. Self-custody writes are signed by your wallet. A platform-operated namespace instead uses the deployment’s operating signer; do not confuse console access with on-chain authority. Billing and the marketplace apply when enabled on a deployment. Hosted subscriptions do not create a yearly ownership levy in the naming contracts. Marketplace payment escrow is operator-custodied and separate from the Allocator’s on-chain namespace-claim escrow. You can use another RPC to call the contracts without the hosted app. Reads still require a working RPC, supported code and accessible storage. Archived records may need restoration before they can resolve.