mail.alice.yourbrand. Availability depends on the namespace: shared contract support and published SDKs do not automatically upgrade an existing namespace or enable its policies.
For a working integration, start with the quickstart or try the live examples.
Network, versions and fees
The namespace application fee goes into Allocator escrow. Award pays the configured recipient; rejection or stuck cancellation refunds 100%; withdrawal or expiry refunds 80%. See namespace claim outcomes.
A username fee goes directly to the owner’s configured treasury when the claim succeeds. There is no username approval escrow or mandatory annual Soran ownership fee. Transaction and storage costs are separate. Read the namespace’s current quote before showing a price; see automatic claiming.
Display-name transaction costs
Setting or clearing a display name in Lookup or Primary no longer renews the shared Wasm code. These writes still pay Stellar transaction costs and any required record or instance storage rent. Explicit maintenance renews the shared code in bounded increments, paid by whoever submits that maintenance transaction. This update does not add automatic fee sponsorship. Reading a name through RPC simulation does not submit a transaction or charge an on-chain fee. A lookup invoked inside a submitted transaction contributes to that transaction’s resource costs. Always simulate writes for a current fee estimate. The Lookup upgrade and Primary upgrade are confirmed. That release preserved existing records and contract methods. See storage lifetime.Namespace-funded sponsorship
The Funding contract and hosted sponsorship API are live on testnet. Sponsorship is optional: the namespace owner must fund and enable a position, and the claiming app must use the sponsorship flow. Existing self-pay flows keep their current fee payer. A namespace owner can sponsor successful username claims, reverse elections and primary-name elections. The relayer pays Stellar’s network fee; the Funding contract settles the agreed charge from the owner’s position only when the action succeeds. A separate username price remains payable by the claimant. Sponsorship does not include account creation or automatic contract maintenance. Pricing uses a fixed quote based on live Stellar fee estimates. The agreed amount is charged only when the action succeeds, and Soran retains any savings against the actual network fee. There is no separate refund transaction or later debit. The agreed quote must fit the owner’s configured spending limits. The Funding deployment is confirmed. Existing naming contract addresses are unchanged.SDK versions
The core SDKs below were published and verified on 1 October 2026. They require Node.js 22.12 or newer and Stellar SDK 17. Lookup reads names; Holder manages names and subnames; Owner configures namespaces.
Published MCP 0.10.0 uses the core SDK versions above and also requires Node.js 22.12 or newer. Its resolution, metadata, identity and history tools accept one child level such as
mail.alice.yourbrand. Local profile and payment tools also support children, with authorization from the parent holder. Use the SDKs for child creation, removal, subname-policy changes and additional-network address operations; MCP does not expose dedicated tools for these actions. See child-name support.
The local MCP package includes namespace activation, Resolver setup and submission recovery. See agent access and Resolver setup.
Subnames and network addresses
The 1 October Lookup upgrade and Primary upgrade installed shared subname support. Lookup also supports explicit network-address reads. Their existing addresses are unchanged. Registry governance selected compatible Registrar and Resolver templates for new namespace deployments. Existing namespace contracts and policies were not changed by this rollout. The console and HTTP API include the corresponding interfaces, and the published core SDKs expose the read and write methods. For an existing namespace, its owner must install the compatible contracts and choose the policy. Additional networks start disabled. Subnames start with creation disabled; enabling creation is separate from installing the code. A subname remains controlled by its parent holder and is not independently transferable. Additional network IDs describe destination mainnets, even while Soran runs on Stellar testnet. Publishing an address does not send funds or bridge assets. Stellar retains its complete address-and-memo flow.Shared testnet contract addresses
Universal Lookup is the shared read entry point for every namespace. An integration does not need to maintain a list of namespace Resolvers.Universal Lookup
Registry — namespace ownership and routing
Registry — namespace ownership and routing
Primary — G/C display-name elections
Primary — G/C display-name elections
Allocator — namespace applications and fee escrow
Allocator — namespace applications and fee escrow
Funding — optional namespace sponsorship
Funding — optional namespace sponsorship
SORAN prefix alone does not authenticate a contract.
Nova namespace contracts
Nova is a working example namespace used by the claim app. These two contracts serve only.nova. For another namespace, discover its current pair through Lookup.
Nova Registrar — name issuance and claim rules
Nova Registrar — name issuance and claim rules
Nova Resolver — payment destinations and profile records
Nova Resolver — payment destinations and profile records
Orange namespace contracts
The claim app also offers.orange in the namespace selector. It is owned by a separate wallet and has its own Registrar, Resolver and username availability. Its namespace claim passed the original 24-hour window.
Orange Registrar — name issuance and claim rules
Orange Registrar — name issuance and claim rules
Orange Resolver — payment destinations and profile records
Orange Resolver — payment destinations and profile records
nikcle.orange, robert.orange, mux.orange and cyclops.orange in the live examples.
Contract interface versions
Registrar and Resolver versions are namespace-specific. New approved templates support subnames; the Resolver template also supports network-address records. Read each namespace’s capabilities before offering these features.
Lookup’s muxed identity extension is active at the same contract address. See the full-M methods and storage schema.
Name status and history reads
The 9 September Lookup upgrade keeps the same contract address, storage and existing methods.name_status distinguishes missing namespaces, missing Registrars, unregistered names, active names and expired records in one observation. Existing payment error codes remain compatible.
The 10 September batch optimization keeps all contract addresses unchanged. reverse_names accepts up to 32 G/C/full-M identities in one namespace; primary_names accepts up to 16 across namespaces. Current native contracts combine related reads and share namespace verification work while still checking each live forward destination. Lookup 0.11.0 history helpers split calls when a host budget limit requires it and preserve each row’s ledger/time. See contract methods, SDK examples and exact JavaScript/XDR shapes.
The current SDK release preserves these history methods and complete Stellar payment reads.
Allocator upgrade
The Allocator records case-specific rulings and explanations on chain. Code-upgrade execution and cancellation bind the exact reviewed code hash. Reopening cancellation and execution now bind the exact proposal identity, so a replacement proposal needs a new review. The 8 September upgrade keeps the same contract address and storage schema4.
Those upgrades added case-specific rulings, removed the mandatory wait for new governance-approved code proposals and fixed XLM settlement to G accounts that do not yet exist. A payout can create the account when it meets the required reserve; if the transfer fails, the recipient receives a recoverable credit. The upgrades are recorded separately in the deployment manifest.
The 10 September governed migration also upgraded Allocator code in place and retained its escrow. Namespace claim and objection windows, the 5,000 XLM fee and refund entitlements remain unchanged. See governance and upgrades.
1 October storage maintenance renewed Allocator code storage without changing its executable code. The HTTP API includes this maintenance update; contract addresses, application fees and claim windows stayed unchanged.
Hosted services
The console and HTTP API include the 1 October subname and network-address interfaces. Hosted MCP runs 0.10.0, verified independently of npm publication on 1 October 2026, and exposes the read tools for child names. Signing tools are local-only. Package releases and hosted-service updates have separate verification records in the manifest. Billing and marketplace features are available only when enabled on a deployment. Check service status when integrating.
Namespace activation, current ownership checks and submission recovery remain available. Always use the selected namespace’s live policy and contract capabilities.
Governed testnet deployment
The 10 September migration preserved the Universal Lookup and Allocator addresses. Registry, Primary and Nova’s Registrar and Resolver use the successor addresses above. Later upgrades retain these addresses. Use the current core SDK versions with this deployment; MCP manages its own dependency versions. The active naming contracts support authorized upgrades at the same address. Namespace Registrar and Resolver upgrades require the current namespace owner and protocol approval for the exact contract role and code hash. The governed testnet does not permit irreversible code locks. Name expiry and owner reclaim policy remain separate settings. See governance. The migration retains existing names, payment destinations, exact memo values and full muxed routing IDs. Display-name lookups verify the complete destination; an M destination is not a base-G election. Pending namespace applications retain their original claim windows, escrow and refund entitlements. Keep original saved claims and transaction hashes. Owner and Holder can verify historical receipts throughrecoverHistoricalClaim(originalIntent, { lookupId }) once canonical Lookup confirms the sealed successor. A missing or unavailable receipt does not authorize an automatic retry. Source receipts remain at their original Registrar.
New clients also enforce a shared network-fee ceiling for writes and storage restoration; see client configuration.
Historical records
Older deployments have separate state. Soran does not provide a supported legacy app or API route. For historical inspection, use the snapshots below and the legacy storage reference:- 9 September deployment, before the governed migration
- 5 September native-muxed deployment
- 5 September namespace-bound deployment
- Earlier unscoped deployment