DALP roles and segregation of duties reference

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.

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

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 for the rules.

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 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. The other roles carry no risk mark.

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

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 for the workflow.

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

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

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.