> ## Documentation Index
> Fetch the complete documentation index at: https://docs.soran.domains/llms.txt
> Use this file to discover all available pages before exploring further.

# Activating your namespace

> Choose reclaim, transfer and expiry rules before deploying your namespace's Registrar.

After your namespace claim is awarded, activate it by deploying its Registrar. The namespace owner's wallet authorizes this transaction. Claiming a namespace and activating it are separate steps.

You choose the Registrar's lifecycle policy at activation. You can then configure [automatic username claiming](/owner/automatic-claiming) or issue names through the [Owner SDK](/owner/issuing-from-code).

## Choose your rules

| Field               | Meaning                                                  | Accepted values                                            |
| ------------------- | -------------------------------------------------------- | ---------------------------------------------------------- |
| `reclaimable`       | Whether the namespace owner may reclaim usernames        | Boolean                                                    |
| `transferable`      | Whether holders may transfer usernames to another wallet | Boolean                                                    |
| `default_term_secs` | Default username lifetime                                | `0` for no expiry, or `86400` through `3153600000` seconds |
| `tradeable`         | Stored trading preference for custom integrations        | Boolean                                                    |
| `trade_fee_bps`     | Stored trade-fee preference; 100 basis points equals 1%  | Integer from `0` through `10000`                           |

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](/owner/automatic-claiming).

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](/concepts/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 return `namespace_required` even when your wallet owns the namespace. See [local connection](/agents/access#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:

```json theme={null}
{
  "namespace": "acme",
  "policy": {
    "default_term_secs": "0",
    "reclaimable": true,
    "trade_fee_bps": 0,
    "tradeable": false,
    "transferable": false
  },
  "maxNetworkFeeStroops": "10000000"
}
```

The fee limit in this example is a maximum network fee you authorize, not a fee quote. Review it for your transaction. To use renewable one-year usernames, set `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](/agents/access#pending-activation) for the distinct address-generation and transaction-recovery responses.

## Preset shorthands

Both shorthands remain available. These are their complete effective values:

| Preset        | Reclaimable | Transferable | Default term | Tradeable | Trade fee |
| ------------- | ----------- | ------------ | ------------ | --------- | --------- |
| `reclaimable` | `true`      | `true`       | `0`          | `false`   | `0`       |
| `permanent`   | `false`     | `true`       | `0`          | `false`   | `0`       |

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:

```http theme={null}
POST /console/session/namespace
Authorization: Bearer <session-token>
Content-Type: application/json

{"namespace":"acme"}
```

Check that the response has `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:

```http theme={null}
Authorization: Bearer <session-token>
Content-Type: application/json
X-Soran-Namespace: acme
```

Include `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.

| Response                 | Meaning and recovery                                                                                                                                     |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `400 namespace_required` | The namespace header is missing or invalid. Send `X-Soran-Namespace`; this error alone does not establish an ownership failure.                          |
| `409 namespace_changed`  | The header, session selection or body namespace disagree. Confirm the intended namespace, select it in the same session, and retry with matching values. |

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:

```rust theme={null}
Registry.deploy_registrar(
    node: BytesN<32>,
    treasury: Address,
    policy: RegistrarPolicy,
    salt: BytesN<32>,
) -> Address
```

Here `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:

```text theme={null}
SHA256(UTF8("soran:namespace-deploy:v1\0") || role || namespace_node || nonce)
```

`\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:

```json theme={null}
{
  "tool": "deploy_namespace_resolver",
  "arguments": {
    "namespace": "yourbrand",
    "maxNetworkFeeStroops": "50000000"
  }
}
```

The tool selects the namespace in its private API session, prepares through `/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:

```text theme={null}
confirm_namespace_resolver({ namespace: "yourbrand", predictedId, txHash })
```

Confirmation reads the Registry directly without signing or resubmitting. It reports `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.