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