Choose your rules
The trading fields do not enable an on-chain username marketplace or collect a trade fee. To charge for username registration, configure the native claim fee’s token, amount and recipient separately in claim settings.
Disabling transfers prevents holder-to-holder username transfers. It does not freeze holder-controlled payment destinations or remove the owner’s authorized reclaim powers.
There is no ordinary setter for these five lifecycle fields after activation.
configure_claims changes admission and registration-fee settings, not this construction policy. Governed testnet contracts remain upgradeable, but uploading new code does not automatically change a stored policy. See governance.
Activate through MCP
Use MCP 0.9.5 in your local client and restart the MCP process after updating its package version. This release selects the requested namespace in its private API session and sends the required namespace header. Older clients can returnnamespace_required even when your wallet owns the namespace. See local connection.
In local mode, activate_namespace accepts either a complete policy object or a preset. For example, an app can permit owner reclaim while preventing holder transfers:
default_term_secs to "31536000".
The MCP checks all five fields in the prepared Registry call and the nested Registrar constructor authorization before signing. It also verifies the namespace, network, predicted contract address and fee limit. After the API confirms submission, the MCP checks the Registrar and policy independently on chain.
activated: true with policyVerified: true means those checks passed. If submission or verification remains unresolved, use confirm_namespace_activation with the namespace, your original policy as expectedPolicy, and any returned predictedId and txHash. It checks the existing deployment without signing or submitting another transaction. Keep the original reviewed policy; do not change it to match an unexpected on-chain value. See pending activation for the distinct address-generation and transaction-recovery responses.
Preset shorthands
Both shorthands remain available. These are their complete effective values:
The historical name
permanent means non-reclaimable and no expiry here. It does not lock code. The governed testnet rejects permanent code locks. Use the full object when you want different rules.
Prepare through the API
The session wallet must own the namespace. Select it before preparing a deployment, using the bearer token returned by wallet sign-in:ok: true and namespace: "acme". Selection changes only the session’s current namespace; it does not grant ownership.
Send POST /console/registrar/deploy/prepare with the same token, the namespace and policy object shown above, and these headers:
X-Soran-Namespace on every namespace-scoped request, including deployment prepare, submit and confirm. Its value must match the selected session namespace and any namespace field in the body. A body field alone does not replace the header. Select the namespace again after renewing a session, and serialize selection with its following request when sharing a session across concurrent operations.
The API also accepts the two policy presets; omitting
policy retains the reclaimable default.
Supply exactly all five fields in an explicit object. Booleans must be JSON booleans. The term accepts a canonical decimal string or a whole JSON number within the stated bounds. Unknown fields, conflicting top-level overrides, missing policy fields and invalid values are rejected. For example, { "policy": "reclaimable", "transferable": false } is invalid: put the setting inside a full policy object.
A successful preparation returns an unsigned xdr, predictedId, deploymentSaltVersion, namespace, network and the normalized policy. The term in the returned policy is a decimal string. Compare the transaction’s arguments with your original policy before wallet approval; do not rely only on the response’s policy summary.
After signing, use POST /console/registrar/deploy/submit with signedXdr and predictedId. A pending response requires confirmation of the existing transaction, not a new deployment. POST /console/registrar/deploy/confirm checks the already deployed Registrar and records its binding. The dashboard handles these steps and displays the policy read from the contract.
Call the Registry directly
You can activate through the Registry directly with the namespace owner’s signature. This factory call requires no additional governance signature or console submission:node is the namespace namehash and salt is your 32-byte nonce. The current Registry’s deployment_salt_version() returns 1. It derives the deployment salt as:
\0 is one zero byte. The role is one byte: 1 for Registrar and 2 for Resolver. The Registry then uses the normal Soroban contract-address derivation with that salt, its own address and the network. Call predict_registrar(node, nonce) to verify the address before deployment.
The API and MCP use branded addresses matching C[A-D]SORAN[A-Z2-7]{49}. That prefix is a tooling convention; it is not a Registry requirement for a direct call.
deploy_registrar records its own on-chain attestation. Do not follow it with attest_registrar: that separate method is for post-hoc attestation of a separately deployed contract and has different provenance rules. It requires the namespace owner’s authorization, matching Registry/namespace anchors and the Registry’s pinned Registrar code. An API confirmation is not another on-chain attestation.
Finally, read Registry.registrar_of(node) and the deployed Registrar’s policy(). The Owner SDK exposes these as owner.registrarOf(namespace) and owner.policy(namespace); its returned policy uses defaultTermSecs as a bigint and tradeFeeBps as a number. These reads do not change a policy.
Universal Lookup follows the Registry’s on-chain bindings regardless of whether you submitted the factory call through the console. Native payment resolution also requires the namespace’s Resolver, an active name and configured payment records. Deploying the Registrar alone does not complete that setup. If the console has not recorded the deployment yet, use the scoped API confirmation route or confirm_namespace_activation to recover it without deploying again.
Complete Resolver setup
Registrar activation is the first step. Native username claiming and payment records also need the namespace’s Resolver. MCP 0.9.5 adds this local owner tool:/console/resolver/deploy/prepare, independently checks the predicted Resolver address and signed arguments, then submits through /console/resolver/deploy/submit. The Registry factory deploys, attests and selects the Resolver in one transaction. No separate governance attestation is needed for this factory flow.
If address generation returns queued or mining, retry the same deployment tool after retryAfterMs. No deployment transaction has been submitted yet. If submission instead returns pending: true, retain the exact predictedId and txHash and call:
resolverReady: true only after checking ownership, the selected/attested Resolver and the Registry’s native contract verification. Keep the identifiers while verification is pending. Both identifiers are optional if the original response was lost; the Registry can discover its Resolver. The supplied transaction hash is retained as a recovery reference, not independently checked as a transaction receipt by this tool.
The C?SORAN address prefix is cosmetic. An existing clean, attested native Resolver without it is valid and is accepted with alreadyConfigured: true; no replacement is prepared. A cleared or mismatched pointer stops setup and identifies the attested Resolver to review and restore using set_resolver.
After resolution is ready, configure public registration with configure_native_claims, or issue names in Manual mode. Hosted MCP remains read-only.