# User and role examples

Use these examples as starting points for role design. Adapt role names to your operating model, then use the same names in users, policies, and read access.

Roles are role-name strings that you can define whenever you need them. In the standard governed user-management flow, assigning a role to a user or changing a user's roles requires an approved `v0_CreateUser` or `v0_UpdateUser` intent.

## Role catalog

| Role | Type | Common use |
|  --- | --- | --- |
| `platform-admin` | Human | Root-domain administration and emergency governance. |
| `domain-admin` | Human | Domain administration for a specific domain or domain family. |
| `policy-operator` | Human | Policy creation and policy changes. |
| `transaction-operator` | Human | Routine transfer or transaction creation. |
| `transaction-operator-bot` | Bot user | Automated transaction creation under controlled policies. |
| `compliance` | Human | Screening, quarantine release, and exception review. |
| `auditor` | Human | Read-only review of requests, events, policies, and transactions. |
| `emergency-operator` | Human | Breakglass or recovery approval. |


## Minimal launch model

Use this only for small launch environments where duties are simple but quorum is still required.

| Role | Minimum users | Purpose |
|  --- | --- | --- |
| `platform-admin` | 2 | Root administration and recovery. |
| `policy-operator` | 2 | Policy changes. |
| `transaction-operator` | 2 | Routine transaction operations. |
| `compliance` | 1 or 2 | Compliance review, if used at launch. |


Policy implication: do not require a quorum that this user model cannot satisfy.

## Segregated operating model

Use this when administration, policy management, operations, and compliance are separate teams.

| Role | Minimum users | Typical workflows |
|  --- | --- | --- |
| `platform-admin` | 2 | Domain and emergency operations. |
| `user-admin` | 2 | User creation, user role-assignment changes, lock and unlock. |
| `policy-operator` | 2 | Policy create, update, lock, unlock. |
| `transaction-operator` | 2 or more | Transfer creation. |
| `compliance` | 2 | Quarantine and exception approval. |
| `auditor` | As needed | Read-only review. |


Policy implication: role elevation and policy changes should require stronger approval than routine operations.

## Automation model

Use bot users for automated workflows such as gas funding, scheduled transfers, or integration with external systems.

| Use case | Intent types | Additional restrictions |
|  --- | --- | --- |
| Gas Station | `v0_CreateTransactionOrder` | Native token transfers only, specific source accounts. |
| Scheduled transfers | `v0_CreateTransactionOrder` | Specific source/destination accounts. |
| Account management | `v0_CreateAccount` | Specific domains. |


Policy implication: for fully automated operation, create policies that allow automatic approval of the bot user's transactions. Without auto-approval, transactions created by the bot user queue for manual approval.

## Emergency model

Emergency roles should be independent from routine operators where possible.

| Role | Purpose |
|  --- | --- |
| `emergency-operator` | Approves breakglass or recovery workflows. |
| `platform-admin` | Coordinates root-domain recovery. |
| `compliance` | Reviews regulatory or legal emergency actions. |


Policy implication: emergency workflows should be explicit, high quorum, and scoped to the emergency intent types they are meant to govern.

For planning guidance, see [Plan your first users](/products/custody/governance/genesis/plan-your-first-users). For fields and naming guidance, see [User and role reference](/products/custody/governance/users/reference).