Use these examples as starting points for domain design. For the underlying model, see Domains. For launch planning, see Design your domains.
| 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. |
Use client tenancy when client data, accounts, users, and operational approval workflows must be isolated.
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
CoerceDescendantsonly for controls that clients cannot override.
Use regional domains when jurisdiction, legal entity, operating hours, or compliance ownership differs by region.
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.
Use treasury isolation when operating teams, assets, desks, or risk limits differ.
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.
Use a compliance domain when screening, quarantine, release, or exception review should sit above operational domains.
Design notes:
- Give compliance roles access to transactions, requests, events, and accounts needed for review.
- Define quarantine release policies in the compliance layer.
- Use
ConsiderDescendantswhen compliance policies should combine with child-domain policies. - Use
CoerceDescendantsonly where child policies must not weaken compliance control.
For the post-genesis procedure, see Inject a domain.