# Domain examples

Use these examples as starting points for domain design. For the underlying model, see [Domains](/products/custody/governance/domains). For launch planning, see [Design your domains](/products/custody/governance/genesis/design-your-domains).

## Example catalog

| Example | Goal | Domain model | Policy implication |
|  --- | --- | --- | --- |
| Client tenancy | Separate client assets and operations. | Root domain with one child domain per client. | Client policies apply in each client domain; parent oversight can apply from root or an operations parent. |
| Regional governance | Separate legal entities or jurisdictions. | Root domain with regional child domains. | Regional policies can reflect local approval and compliance requirements. |
| Treasury isolation | Separate treasury desks or asset operations. | Root domain with treasury subdomains by desk, asset class, or operating team. | Transfer and approval policies can differ by domain. |
| Compliance oversight | Add a compliance layer above operating domains. | Compliance domain above child operating domains. | Compliance policies can apply to descendant domains. |
| Domain injection | Insert a parent after launch. | New parent domain is created with existing children. | Future intents in child domains can inherit new parent policies. |


## Client tenancy

Use client tenancy when client data, accounts, users, and operational approval workflows must be isolated.


```mermaid
flowchart TB
    Root["Root"]
    Clients["Client operations"]
    A["Client A"]
    B["Client B"]
    C["Client C"]

    Root --> Clients
    Clients --> A
    Clients --> B
    Clients --> C
```

Design notes:

- Use clear domain aliases that match operational support and reporting needs.
- Keep client users and client-specific policies in the client domain.
- Put shared controls in the parent only when parent oversight is intended.
- Use `CoerceDescendants` only for controls that clients cannot override.


## Regional governance

Use regional domains when jurisdiction, legal entity, operating hours, or compliance ownership differs by region.


```mermaid
flowchart TB
    Root["Root"]
    APAC["APAC"]
    EMEA["EMEA"]
    Americas["Americas"]
    Root --> APAC
    Root --> EMEA
    Root --> Americas
```

Design notes:

- Put region-specific approver roles in the regional domain.
- Use policy conditions for regional thresholds or operating windows.
- Keep global emergency controls in a parent domain.


## Treasury isolation

Use treasury isolation when operating teams, assets, desks, or risk limits differ.


```mermaid
flowchart TB
    Root["Root"]
    Treasury["Treasury"]
    BTC["BTC operations"]
    ETH["ETH operations"]
    Stablecoin["Stablecoin operations"]

    Root --> Treasury
    Treasury --> BTC
    Treasury --> ETH
    Treasury --> Stablecoin
```

Design notes:

- Keep transfer policies close to the domain where transfers are created.
- Use parent policies for shared high-risk controls.
- Keep read access broad enough for compliance and treasury oversight.


## Compliance oversight

Use a compliance domain when screening, quarantine, release, or exception review should sit above operational domains.


```mermaid
flowchart TB
    Root["Root"]
    Compliance["Compliance"]
    Trading["Trading"]
    Treasury["Treasury"]

    Root --> Compliance
    Compliance --> Trading
    Compliance --> Treasury
```

Design notes:

- Give compliance roles access to transactions, requests, events, and accounts needed for review.
- Define quarantine release policies in the compliance layer.
- Use `ConsiderDescendants` when compliance policies should combine with child-domain policies.
- Use `CoerceDescendants` only where child policies must not weaken compliance control.


For the post-genesis procedure, see [Inject a domain](/products/custody/governance/domains/inject-a-domain).