# Roles & duties

Source: https://docs.settlemint.com/docs/concepts/compliance-and-identity/roles-and-segregation-of-duties
Every role a DALP deployment checks, what each one permits, and which pairs of roles or people the platform keeps apart.

The platform checks three separate sets of roles. Organisation and platform roles decide which organisation and platform actions a signed-in person can take. They are Owner or Member in the organisation, and Administrator on the platform. On-chain roles decide which address can make a privileged contract call, or for a few roles which Platform API and Console actions a holder can take. Trading venue roles decide who can configure and settle a venue. Holding a role in one set grants nothing in the other two. The custody gateway add-on keeps its own roles in its own access manager, granted by the Gateway permission manager role.

To change who holds an on-chain role, use [Roles and permissions](https://docs.settlemint.com/docs/console/organisation-settings/admins-and-roles).

[Figure] Three role sets, each checked in a different place. Organisation and platform roles (Owner, Member, Administrator) are checked by the Console and Platform API for a signed-in person. On-chain roles, 33 in total, are checked by the system access manager and each token's access manager when an address calls a contract. Trading venue roles (admin, operator, submitter) are checked by the venue's own access manager. The three sets share no record, so a grant in one set gives no authority in another. Labels: Owner, Member, Administrator; Organisation and platform roles; Checked for a signed-in person by the Console and Platform API; 33 roles in the system and token access managers; On-chain roles; Checked for an address when it calls a contract; Admin, operator, submitter; Trading venue roles; Checked by each venue's own access manager.

Each set is checked in a different place, so a grant in one set gives no authority in another.

## Organisation and platform roles [#organisation-and-platform-roles]

An organisation member holds one of two organisation roles, Owner or Member. The Administrator platform role is set on a person's account, not in one organisation, and the Console shows it as the "Platform role". The role decides which resource actions the platform allows the person to perform. A person who needs to sign a contract call also needs the matching on-chain role.

| Resource | Owner | Member | Platform administrator |
| --- | --- | --- | --- |
| Organisation | update | none | list every organisation, archive, restore |
| Members and invitations | add, change and remove members, create and cancel invitations | none | add members |
| Settings | read, list, upsert, remove | read, list | read, list, upsert, remove, set the global theme |
| System | read, list, create | read, list | read, list, create, operate |
| Exchange rates | read, list | read, list | read, list |
| Webhooks | manage | none | manage |
| Corporate actions | approve | none | approve |
| Users | list, get, update | none | create, list, get, update, set role, ban, impersonate, delete, set password, set email |
| Sessions | none | none | list, revoke, delete |

The platform switches organisation deletion off, so no role deletes an organisation. The members, invitations, users and sessions rows come from the authentication library that the platform uses for sign-in. The platform defines the other rows itself. A platform administrator can impersonate a user and sign in as them. A platform administrator who is also an Owner of the organisation has the Owner column as well. Renaming the organisation, changing a member's role, removing a member and sending an invitation need the Owner role in that organisation, even for a platform administrator. Removing a member also needs the Identity manager on-chain role.

Owner and platform administrator are the two roles that count as eligible approvers for a partial redemption and for reporting sign-off. See [Maker-checker](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker) for the rules.

## On-chain roles [#on-chain-roles]

The platform defines 33 on-chain roles. Ten are held by contracts and never by people.

The other 23 are human roles, and the Console groups them under Platform, Compliance, Assets, and Oversight. The system-wide table lists 17 of them, and the Console and the Platform API grant 15 of those. The system grants Organisation identity manager to the account that bootstraps it, and no platform route grants Add-on manager. The tables name each role by its Console label, with the API field name where the two differ. Two scopes apply. A system-wide role is checked in the organisation's system access manager. An asset role is checked in the access manager of one token, so holding it on one token gives no authority on another. The Permission manager role, `admin` in the API, exists in both managers. Once the organisation switches to smart wallets, the organisation's own wallet holds system roles too. The Console lists that wallet under the organisation's name and does not count it as a person, for example when it warns that only one person holds Permission manager.

Granting or revoking a role needs the target role's administrator. In the system access manager, Permission manager can grant and revoke every role. In a token's access manager, Permission manager administers all of that token's roles. The [Role Grant](https://docs.settlemint.com/docs/concepts/compliance-and-identity/role-grant) page explains the model.

The Console marks each human role with a risk level. Permission manager and System manager are critical. Gas manager, Gateway permission manager, Escrow manager, Compliance manager, Identity manager, Bank rail manager, Venue manager, Governance, Supply management, Custodian, Emergency and Funds manager are elevated. Identity manager is elevated because one holder can replace any user's wallet and move that user's tokens with [an identity recovery](https://docs.settlemint.com/docs/console/my-account/onchain-identity#recover-a-user-who-lost-their-wallet). The other roles carry no risk mark.

### System-wide roles [#system-wide-roles]

| Role | Group | What it permits |
| --- | --- | --- |
| Permission manager (`admin`) | Platform | Grants and revokes every role in the system access manager, including to itself. Can upgrade the system access manager to any implementation. Gives no authority in a token's access manager. |
| System manager | Platform | Bootstraps and upgrades the system, including the system access manager, the implementation that every token access manager runs, and the token logic of every token a factory deployed. Points any add-on factory at new code, which every add-on that factory created runs from its next call: add-on access managers, custody gateways, escrows, token sales, token distributions, XvP settlements, trading venues, yield schedules, token governance and token features. One holder does it with no second approval, and the factory checks only that the new code reports the add-on's interfaces through ERC-165. Registers token factories, add-ons, and compliance modules. Creates trading venues. Sets the paymaster signer, and withdraws and stakes paymaster funds. |
| Gas manager | Platform | Funds and configures the paymaster and its fee splitter, as an API and Console permission. Rotating the paymaster's signing key needs System manager. No contract function checks it. |
| Escrow manager | Platform | Creates escrows from the escrow factory, such as the escrow a bank rail token link needs. An escrow sits on the compliance bypass list and its creator picks who controls it. Cannot upgrade the factory: that stays with the System manager. |
| Gateway permission manager (`custodyGatewayPermissionManager`) | Platform | Grants and revokes the custody gateway add-on's roles: its gateway managers, keepers and screeners. The add-on's own access manager checks it on chain against the system access manager. |
| Add-on manager | Platform | Manages protocol add-ons and their factories. Only the first version of the settlement factory checked it on chain. |
| Compliance manager | Compliance | Registers and configures compliance modules. Manages global compliance settings. Also holds the on-chain permission to edit the bypass list, which the Console and the Platform API do not expose. |
| Verification policy manager (`claimPolicyManager`) | Compliance | Registers topic schemes and manages trusted issuers and the claim topics they may issue. |
| Verification issuer (`claimIssuer`) | Compliance | Creates and revokes identity claims through the Platform API. Holding the role does not make an issuer trusted: trust is set in the trusted issuers registry. No contract function checks it. |
| Identity manager | Compliance | Registers, updates, recovers, and deletes identities in the identity registry. Onboards users. A recovery marks a holder's wallet lost and names its replacement, which can then claim that wallet's whole balance of every token, so this role can move holdings. |
| Organisation identity manager | Compliance | Manages the organisation's own identity, including its claims and keys and its organisation-level verifications. |
| Asset manager (`tokenManager`) | Assets | Deploys and configures tokens, registers external tokens, and creates token sales and yield schedules. |
| Asset designer | Assets | Designs asset classes and instrument templates. Cannot mint tokens or upgrade contracts. An API and Console permission only. |
| Bank rail manager | Assets | Sets up and runs the organisation's bank rail, the bank connection that mints tokens when the bank credits the account. An API and Console permission only. No contract function checks it. |
| Venue manager | Assets | Creates trading venues. The account that creates a venue holds its default administrator role. The venue contract checks its own roles after that, covered below. |
| Feeds manager | Assets | Registers, replaces, and removes data feeds. Sets price resolver staleness limits. |
| Auditor | Oversight | Read-only access to permissions, identities, audit logs, and system state. No contract function checks it, and it cannot change anything. |

### Asset roles [#asset-roles]

Asset roles are checked in the access manager of one token. On the "People" tab, Governance counts in the Compliance group, Permission manager in Platform, and the other asset roles in Assets. The asset's own role editor groups them as Administration, Compliance, Operations and Other.

| Role | What it permits on one token |
| --- | --- |
| Governance | Renames the token, replaces its compliance and identity registry bindings with any contract, which can take the token out of the global controls, edits metadata, adds and removes compliance modules, and sets feature parameters such as fee rates. On a bond, sets the cap and marks maturity. |
| Supply management | Mints, and burns from any holder's wallet, singly or in batches. No compliance rule can block a burn. Withdraws the denomination asset from the token's yield schedule. |
| Custodian | Freezes an address or part of a balance, forces a transfer, and recovers tokens from a lost wallet. A forced transfer skips the compliance modules, still runs the recipient's identity check, and runs while the token is paused or the sending wallet is frozen. It refuses a frozen recipient. Claims yield on a holder's behalf. |
| Emergency | Pauses and unpauses the token and recovers ERC-20 tokens sent to it by mistake. A pause does not stop a custodian forced transfer or a recovery. Can end a bond early. |
| Offering admin | Activates, pauses, extends and ends a token sale, finalises it, and withdraws unsold tokens. Sets its terms hash, step, whitelist and allocations, and on a book-built sale its application mode, greenshoe and lock-ups. |
| Funds manager | Funds a token sale, finalises it, withdraws the payment currencies it collected, and refunds a purchase that cannot be delivered. |

### Contract roles [#contract-roles]

Contract roles belong to platform contracts and are granted during bootstrap or registration. Do not assign them to a person. They matter to an auditor because they show which contract may write to which registry.

| Role | Held by | What it permits |
| --- | --- | --- |
| System module | The system contract | Acts as an alternative caller on the compliance, topic scheme, and trusted issuers registries. Binds identity registries. |
| Identity registry module | The identity registry | Writes identities, countries, and wallet recovery links in identity storage. |
| Token factory registry module | The token factory registry | Administers the token factory module role. No function checks it directly. |
| Token factory module | Each registered token factory | Registers identities, binds tokens to compliance, and issues organisation claims when a factory deploys a token. |
| Add-on factory registry module | The add-on registry | Updates add-on factory implementations. Administers the add-on module role. |
| Add-on factory module | Each registered add-on | Creates access managers, registers feeds, and registers identities for add-on contracts. |
| Trusted issuers meta registry module | The trusted issuers meta registry | Manages the trusted issuers registry on the meta registry's behalf. |
| Compliance engine module | Each token's compliance engine | Deploys module instances from the compliance module registry. |
| Token compliance factory module | The token compliance factory | Creates each token's compliance engine and grants it the compliance engine module role. |
| Token identity registry factory module | The token identity registry factory | Deploys each token's identity registry. |

## Trading venue roles [#trading-venue-roles]

Each trading venue has its own access manager with three roles. The venue contract checks them, not the system access manager. The account that creates the venue holds the default administrator role, which administers the venue admin role. The venue admin role administers the operator and submitter roles.

| Role | Holder | What it permits |
| --- | --- | --- |
| Venue admin | A person | Admits and revokes member identities. Sets the admission policy and calendar commitment. Resumes a paused venue. Sweeps tokens the venue's escrow holds beyond what it owes. Manages the venue identity's claims. Can also pause. |
| Venue operator | A person | Creates, halts, resumes, and delists instruments. Sets holding periods, fee schedules, fee accounts, price bands, and the per-fill gas limit. Pauses the venue. Flags and clears flags on trades. Cancels orders. Cannot undo a trade, resume a paused venue, or grant a role. |
| Venue submitter | The organisation's operations signer | Settles batches and auctions, reserves and releases holdings, flags trades and clears flags, and undoes a trade after the second approver has approved it. Never grant it to a person. |

Provisioning a venue in the Console grants the submitter role to the organisation's operations signer. See [Venue operations](https://docs.settlemint.com/docs/console/asset-lifecycle/venues) for the workflow.

## What the platform enforces [#what-the-platform-enforces]

For each control in this table, the platform rejects a decision made by the same person who proposed it. [Maker-checker](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker) describes the full rules, including the cases where an organisation can waive a control.

| Control | The platform rejects | How it is enforced |
| --- | --- | --- |
| Trading venue approvals | The proposer approving their own trade bust, desk trading limit, fee schedule, order cancellation, mass order cancellation or venue configuration change | A database rule on the venue approval record requires the checker to differ from the proposer. |
| Wallet checker approval | The wallet's checker starting a transaction from the wallet they check | The approval flow refuses the transaction and a different person must start it. |
| Reporting sign-off and acknowledgement | The preparer signing off their own filing, or the approver entering the authority's acknowledgement | A database rule on the submission requires the checker to differ from the preparer. The platform also checks the signing user and refuses an impersonated session. |
| Partial redemption and in-kind payout | The person who recorded or previewed the action approving it | A database rule on the corporate action requires the checker to differ from the proposer and from the last previewer. An organisation can switch the control off. |
| Bank account approval | The proposer approving the bank account they proposed for a client | The platform refuses the approval and a different Bank rail manager must make it. The rule holds when the Bank rail approval is off. |
| Recall execution or abandon | The manager who asked to execute or abandon a recall approving or rejecting that request | The platform refuses the decision, and an impersonated session cannot decide it either. The rule holds when the Bank rail approval is off. |

An owner or a platform administrator can also require a second person for ten families of change in the organisation's [Approvals](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals) settings. The Administration family covers privileged changes such as role management, compliance configuration, freezes, pauses, forced transfers and recovery. Every family is off by default, except the "Recovery" group of Administration, which starts on.

The platform always enforces one segregation rule for system roles through its routes: one address cannot hold `auditor` together with any of the other 14 system roles the platform grants. A grant made directly on chain is not checked, and the conflict report does not list it. A grant of either side to an address that holds the other is refused, and a request cannot grant both together. The refusal is `PLATFORM_ROLE_SEGREGATION_CONFLICT`, and `data.conflicts` names each pair with scope `platform` and mode `block`. The administrator role appears there as `DEFAULT_ADMIN_ROLE`. A request that revokes the conflicting role at the same time is evaluated after that revoke and goes ahead when no other conflict remains.

Each organisation can also keep its own segregation-of-duties rules, stored in the `ROLE_SEGREGATION` organisation setting. A rule names two on-chain roles, such as `GOVERNANCE_ROLE` and `CUSTODIAN_ROLE`, and a scope: `contract` when the two roles conflict only on the same token, token sale or venue, `platform` when they conflict anywhere in the organisation's system. Each rule also has a mode, which decides what happens to a grant that breaks it:

| Mode | A grant that breaks the rule |
| --- | --- |
| `warn` | Is refused until it carries a `reason`, with `data.reasonRequired` set to `true`. The grant then goes ahead and the audit trail keeps the reason with the broken rules. |
| `block` | Is refused. The answer is `PLATFORM_ROLE_SEGREGATION_CONFLICT` and `data.conflicts` names each broken pair and its mode. |

Both modes stop a grant that has no reason. `warn` lets it through once someone records why.

The setting's `enabled` switch turns the check on. While it is off, grants go ahead and the rules still feed the conflict report. An organisation owner or a platform administrator saves the setting with `POST /api/v2/settings`. In the Console, an owner sets the switch and the rules in the [Segregation of duties](https://docs.settlemint.com/docs/console/organisation-settings/general#segregation-of-duties) section of General.

The check runs on every role grant route, for system, token, token-sale and venue roles, before any chain write. It also covers the initial permissions of a new token and the roles an invitation grants. It counts the roles the address already holds anywhere in the system, after the same request's revokes, and the other roles named in the same grant. It compares addresses, not people, so one person can hold both roles of a pair on two wallets, or use the second by working as a party whose wallet holds it. An address that holds a system module role is a platform contract and is not checked. The frozen v1 grant routes and the token create routes cannot send a `reason`, so they refuse a grant that breaks a `warn` rule. While the setting is enabled, the platform refuses a grant it cannot check, because the system's access manager or the target access manager is not in its record of the chain yet.

In the Console, a refused role change names each conflicting pair and its scope, for example "Custodian cannot be held with Governance on the same contract." The Console's role sheets send no `reason`, so they also refuse a grant that breaks a `warn` rule. Send that grant through the Platform API with a `reason` instead.

No organisation pair is enforced until the organisation saves and enables the setting. Until then its rules are the default pairs marked in the next table, each set to `block`, as a starting list.

`GET /api/v2/system/role-conflicts` lists every address that holds a pair the organisation's rules name, for a Permission manager or Auditor. It reads the platform's record of role holdings, so it also shows roles granted directly on chain outside the platform. It does not apply the always-on Auditor rule, so an address that holds Auditor and another system role does not show there. Narrow it with `filter[mode]`, `filter[scope]` or a `filter[q]` search, and sort it by `account`, `mode` or `scope`.

A system role grant may carry an `expiresAt` at least one minute in the future. A settled response repeats the expiry, and a durable workflow revokes the granted roles after it.

## Role pairs to keep apart [#role-pairs-to-keep-apart]

The table lists pairs where one holder would remove an independent check.

| Pair | Why to separate them | Enforced by the platform |
| --- | --- | --- |
| Identity manager and Verification issuer | One holder can register an identity and attach the claim that qualifies it, with no second review. | A default organisation rule, once enabled |
| Verification policy manager and Verification issuer | One holder can decide which issuers and topics are trusted and then issue claims under that trust. | No |
| Compliance manager and Custodian | One holder can relax the compliance rules and then force a transfer or move frozen balances. | A default organisation rule, once enabled |
| Governance and Custodian | Governance replaces a token's compliance bindings and the custodian forces transfers, so one holder controls both the rule and its exception. | A default organisation rule, once enabled |
| Supply management and Custodian | One holder can mint tokens and move them to another address without the holder's consent. | A default organisation rule, once enabled |
| Offering admin and Funds manager | One holder can run a sale and withdraw the funds it collects. | A default organisation rule, once enabled |
| Auditor and any other system role | An Auditor is read-only, while every other system role changes protocol or operational state. One holder could change the state that they also review. | Yes, for system role grants through the platform |
| Permission manager and any operational role | Permission manager can grant itself every other role, so it undermines every other pair in this table. Hold it on as few accounts as possible. | No |
| Identity manager and any other role | A recovery lets one holder redirect any holder's balances to a wallet it names. Hold it on as few accounts as possible. The **Recovery** protection group under Administration in [Approvals](https://docs.settlemint.com/docs/console/organisation-settings/general#approvals) is on by default, so a second person approves each recovery made through the platform. | No |
| System manager and any operational role | System manager can replace the logic of the system access manager and of every token access manager. Hold it on as few accounts as possible. | No |
| Venue operator and Venue submitter | The operator configures instruments and the submitter settles trades. One holder configures and settles. The contract also permits a person to hold the submitter role, which the venue design reserves for the operations signer. | A default organisation rule, once enabled |
| Venue admin and Venue operator | One holder admits participants and also sets their instruments and fees. | A default organisation rule, once enabled |

"A default organisation rule, once enabled" means the platform refuses the pair only after the organisation saves and enables the `ROLE_SEGREGATION` setting. A role change made through the platform is recorded in the [Audit trail](https://docs.settlemint.com/docs/console/reporting/audit-trail) with the person who made it, their platform and organisation role at the time, and the roles before and after. Review the conflict report at each access review. Review the pairs no rule covers, such as Permission manager or System manager with another role, on the "People" tab of Roles and permissions.

## Frequently asked questions [#frequently-asked-questions]

### Does the platform warn when one account holds two conflicting roles?

It refuses a system role grant that would leave one address holding `auditor` and any other system role, in every organisation. For the organisation's own rules it refuses or asks for a reason according to each rule's mode once the `ROLE_SEGREGATION` setting is enabled. `GET /api/v2/system/role-conflicts` lists the addresses that already hold a pair the organisation's rules name, including roles granted on chain outside the platform.

### Which controls need a second person without any role setup?

The controls in the enforcement table. They compare the people involved, not their roles, so they apply even when one person holds every role. A wallet checker is the exception in one respect: it applies only to a wallet that has a checker configured.

### Is an on-chain role the same as a platform administrator?

No. The Administrator platform role is set on a person's account and checked by the Console and Platform API. The on-chain Permission manager role, `admin` in the API, is held by an address and checked by the contracts. A platform administrator or an organisation owner has no contract authority until an address the organisation can act on for them holds the matching on-chain role.

### How many roles does DALP have?

The role vocabulary has 33 on-chain roles, 23 of them human and ten held by contracts. Organisation and platform roles add three more, Owner, Member and Administrator, and trading venues add three more. The sets are separate.

## Related concepts [#related-concepts]

- [Role Grant](https://docs.settlemint.com/docs/concepts/compliance-and-identity/role-grant): How a role is granted, checked on chain and ended.
- [Maker-Checker](https://docs.settlemint.com/docs/concepts/custody-and-signing/maker-checker): The controls that need a second person whatever roles people hold.
- [Delegated Authority](https://docs.settlemint.com/docs/concepts/compliance-and-identity/delegated-authority): Why working as another participant adds no role of its own.
- [Add-on approvals](https://docs.settlemint.com/docs/concepts/compliance-and-identity/addon-approvals): A second approver on one exact add-on call.