A domain is an organizational boundary that groups accounts, users, and policies under a single governance structure.
- Domains form a hierarchy (parent → child) mirroring your business structure.
- Data is isolated. Users can only access their assigned domain and its subdomains.
- Policies can cascade down the hierarchy or be enforced at specific levels.
- Governing strategies control whether child domains can override parent policies.
Domains are your primary tool for segregating assets, users, and governance rules. Proper domain design directly impacts your ability to meet regulatory requirements (client asset segregation), enforce operational controls (regional policies), and scale your custody operations (adding new business units or clients). Misconfigured domain hierarchies can lead to unintended policy bypasses or access violations.
For architects and operators: Your domain structure is defined in the genesis block and is foundational — plan carefully before deployment. Consider how governing strategies (ConsiderDescendants vs. CoerceDescendants) will affect policy inheritance as you add subdomains.
A domain is a logical container that:
- Segregates data: Users, accounts, vaults, and other entities belong to specific domains
- Defines governance boundaries: Policies are defined at the domain level and control actions within that domain
- Establishes user access: Users can only operate within their assigned domain (and potentially its subdomains)
Think of domains as organizational units that mirror your business structure — headquarters, regional offices, business units, or client segregation.
Domains form a tree structure with a single root domain at the top and subdomains beneath it.
| Rule | Description |
|---|---|
| Single root | Every environment has exactly one root domain |
| Parent-child relationships | Each subdomain has exactly one parent domain |
| No upward access | Users cannot submit intents to parent domains, only to their own domain or its subdomains |
| Inheritance | Subdomains can inherit policies from parent domains (depending on configuration) |
A compliance domain is a specialized domain that manages transaction screening and Travel Rule compliance. When you enable compliance features, you create a compliance domain as a child of the root domain. Transaction screening then applies to all accounts in the compliance domain's child domains.
This pattern uses the domain hierarchy to scope compliance:
- The compliance domain contains compliance-specific users (compliance managers, supervisor agents)
- Child domains inherit the compliance policies from the compliance domain
- You can use domain injection to insert a compliance domain between the root and existing child domains
For setup instructions, see Create a compliance domain.
The domain hierarchy enables multi-tenancy patterns:
- Business unit segregation: Separate domains for different parts of your organization
- Client segregation: Each client in its own subdomain with isolated data
- Regulatory boundaries: Domains aligned with jurisdictional requirements
- Environment separation: Development, staging, and production as separate domain trees
Data entities (accounts, vaults, users) belong to exactly one domain and cannot be directly accessed from other domains.
A domain's governing strategy determines how its policies interact with subdomain policies.
The parent domain's policies are considered alongside subdomain policies. Both the parent and child policies may apply to intents in the subdomain.
Use case: Establishing baseline rules while allowing subdomains to add their own requirements.
The parent domain's policies override subdomain policies for matching intents. The subdomain's own policies are ignored when the parent has a matching policy.
Use case: Enforcing organization-wide rules that cannot be weakened by subdomains. Essential for breakglass policies—emergency override mechanisms that allow senior management to bypass normal approval workflows in exceptional circumstances (e.g., court orders, lost keys, misconfigured policies).
Policies use scope settings to define where they apply:
| Scope | Description |
|---|---|
Self | Policy applies only to intents targeting this domain |
Descendants | Policy applies only to intents targeting subdomains |
SelfAndDescendants | Policy applies to both this domain and all subdomains |
The combination of governing strategy (on domains) and scope (on policies) determines the complete policy application behavior.
For detailed examples, see Policy scope.
Domains progress through several states:
| State | Description |
|---|---|
| Created | Domain exists and is operational |
| Locked | Domain is disabled; no intents can be executed within it |
| Unlocked | Domain is re-enabled after being locked |
Locking a domain is useful for:
- Suspending a business unit
- Freezing operations during an investigation
- Decommissioning an organizational unit
Ripple Custody supports domain injection — inserting a new domain between an existing parent and its children. This allows you to:
- Add a new governance layer without restructuring
- Apply new policies to a subset of existing subdomains
- Reorganize hierarchy as your business evolves
For implementation details, see Domain injection.
- Governance framework: Return to the governance overview
- Intents: Learn about the intent lifecycle
- Policies: Understand how policies control actions
- Domain management: Learn how to manage domains