Skip to main content
The console at soran.domains is where you run a namespace: issue names, manage your team, configure webhooks, and (when a deployment enables them) handle billing and the marketplace. Identity on Soran is a Stellar keypair, so there is nothing to register — you sign in with the wallet you already own.

Wallet sign-in

Sign-in is a SEP-10-style challenge:
1

Request a challenge

The console asks the server for a challenge transaction scoped to your address. Its source account is your address and it is built at sequence number 1 — a sequence no funded account can ever be at — with a five-minute time bound, so it can never execute on chain. It carries a single manageData entry with a one-time nonce.
2

Sign it in your wallet

Your wallet (Freighter, xBull, or any wallet that signs Stellar transactions) signs the challenge. Because it’s a transaction, not a raw message, this works across wallets uniformly. Nothing is submitted anywhere.
3

Verify

The server checks the signature against your address and the challenge is consumed — each one is strictly single-use and expires after five minutes. A valid signature proves you control the key. That’s the whole login.
There is no email path and no password path, by design. Signing out deletes the session server-side, so the token is dead immediately.
Any wallet can sign in — including one that owns nothing yet. An empty wallet lands on onboarding (claim or register a namespace) instead of being locked out.

Authentication vs. authorization

Signing the challenge proves you control the address — that’s authentication. Authorization is separate and per-namespace: at login, the server resolves which namespaces your wallet owns on chain or operates by invitation, and your session carries that list. If your wallet holds several namespaces, the console shows a namespace switcher (in the header chip and the sidebar). Switching re-scopes the session; the server re-validates your role for the target namespace on every switch.

Roles

Each namespace has a team of operators, identified by wallet address. Three roles: Adding a teammate takes their wallet address, a display name, and a role — their wallet address is the invitation. They sign in at the same console with their own wallet; removing the row revokes access. Two boundaries the roles never cross:
  • Roles govern the console; the chain governs ownership. The on-chain owner’s row cannot be removed from the team — chain ownership is access, and it only moves via an on-chain namespace transfer.
  • On a self-custody namespace, console access is not signing authority. Admins and issuers can drive every flow, but on-chain writes still require the owner wallet’s signature.

Self-custody vs. platform-operated

A namespace runs in one of two custody modes, and the console adapts to whichever applies:
  • Self-custody — your wallet is the on-chain owner and the operating key. The console prepares transactions (issue, reclaim, transfer, records, resolver deploys) and hands them to your wallet to sign; the server never holds a key that can touch your namespace. Chain fees are paid by your wallet.
  • Platform-operated — the deployment’s operating key owns and signs for the namespace, and the console executes actions directly. Chain fees are paid by the operating key.
Self-custody is the sovereign path: it works against the public contracts with nothing but your wallet, and it is never gated by billing on any deployment. See the sovereignty principle.

Where things live