Roles and segregation of duties reference
Every role a DALP deployment checks, what each one permits, and which pairs of roles or people the platform keeps apart today.
DALP checks three separate sets of roles. Organisation membership roles (Owner, Admin, Member) decide what a signed-in person can do in the Console and the Platform API. On-chain roles decide which address can make a privileged contract call. Trading venue roles decide who can configure and settle a venue. No set implies another: holding a role in one set grants nothing in the other two.
This page lists every role in each set and what it permits. It then states which duty splits the platform enforces and which it leaves to the organisation's own role assignments. To change who holds an on-chain role, use Admins and roles.
Each set is checked in a different place and shares no record with the others. A grant in one set gives no authority in another.
Organisation membership roles
An organisation member holds one of three roles. 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 | Admin | Member |
|---|---|---|---|
| Organisation | update, delete | update, delete, list | none |
| Settings | read, list, upsert, remove | read, list, upsert, remove, set the global theme | read, list |
| System | read, list, create | read, list, create, operate | read, list |
| Exchange rates | read, list | read, list | read, list |
| Webhooks | manage, compliance recall | manage, compliance recall | none |
| Corporate actions | approve | approve | none |
| Users | list, get, update | none from the platform statements | none |
The Admin role also includes the user-administration statements of the authentication library, and the Owner and Member roles include its organisation statements. The table lists only the statements DALP defines itself.
Owner and Admin 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 27 on-chain roles. Seven are held by contracts and never by people. The other 20 are human roles, and the Console groups them under Platform, Compliance, Assets, and Oversight. 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 Admin role exists in both managers.
Granting or revoking a role needs the target role's administrator. In the system access manager, the Admin role can grant and revoke every role. In a token's access manager, the Admin role administers all of that token's roles. The Role Grant page explains the model.
System-wide roles
| Role | Group | What it permits |
|---|---|---|
| Admin (shown as Permission manager) | Platform | Grants and revokes every role, including to itself. Full protocol control. |
| System manager | Platform | Bootstraps and upgrades the system. Registers token factories, addons, and compliance modules. Creates trading venues. Sets the paymaster signer. |
| Gas manager | Platform | Funds the bundler and paymaster and rotates signer keys, as an API and Console permission. No contract function checks it. |
| Addon manager | Platform | Manages protocol addons 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 and the bypass list. |
| Claim policy manager | Compliance | Registers topic schemes and manages trusted issuers and the claim topics they may issue. |
| Claim issuer | 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. |
| Organisation identity manager | Compliance | Manages the organisation's own identity, including its claims and keys and its organisation-level verifications. |
| Token manager | 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. |
| Trading venue operator | Assets | Appears in the system role vocabulary and the Console. The venue contract checks its own operator role instead, 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. Governance also appears in the Compliance group in the Console, and the rest sit in Assets.
| Role | What it permits on one token |
|---|---|
| Governance | Renames the token, replaces its compliance and identity registry bindings, 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, singly or in batches. |
| Custodian | Freezes an address or part of a balance, forces a transfer, and recovers tokens from a lost wallet. |
| Emergency | Pauses and unpauses the token and recovers ERC-20 tokens sent to it by mistake. Can end a bond early. |
| Sale admin | Configures, activates, pauses, extends, and ends a token sale. Sets its soft cap and terms hash. |
| Funds manager | Withdraws the funds a token sale collected, in native and ERC-20 currencies, 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. |
| Addon registry module | The addon registry | Updates addon factory implementations. Administers the addon module role. |
| Addon module | Each registered addon | Creates access managers, registers feeds, and registers identities for addon contracts. |
| Trusted issuers meta registry module | The trusted issuers meta registry | Manages the trusted issuers registry on the meta registry's behalf. |
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 the escrow vault. Manages the venue identity's claims. Can also pause. |
| Venue operator | A person | Creates, halts, resumes, and delists markets. 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 settlement service | Settles batches and auctions, reserves and releases holdings, 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 managed operations signer. See Venue operations for the workflow.
What the platform enforces today
The platform enforces a second person on five controls. Each 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 |
|---|---|---|
| Trade bust | The proposer approving their own bust | A database rule on the approval record requires the checker to differ from the proposer. |
| Desk trading limit | The proposer approving their own limit | The same approval record and rule. |
| 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 | The platform 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 | The platform checks the approving user. An organisation can switch the control off. |
The platform does not enforce any conflict between roles. It accepts any combination of roles for one person or address, and a grant never fails because the holder already has a conflicting role. Separation of duties across roles depends on how the organisation assigns them. The next table lists the pairs that most need that care.
Role pairs to keep apart
The table lists pairs where one holder would remove an independent check. The last column states whether the platform stops the combination. Today it does not stop any of them.
| Pair | Why to separate them | Enforced by the platform |
|---|---|---|
| Identity manager and Claim issuer | One holder can register an identity and attach the claim that qualifies it, with no second review. | No |
| Claim policy manager and Claim 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. | No |
| 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. | No |
| Supply management and Custodian | One holder can mint tokens and move them to another address without the holder's consent. | No |
| Sale admin and Funds manager | One holder can run a sale and withdraw the funds it collects. | No |
| Admin and any operational role | The Admin role can grant itself every other role, so it undermines every pair above. Hold it on as few accounts as possible, and keep it away from Auditor holders. | No |
| Venue operator and Venue submitter | The operator configures markets 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 settlement service. | No |
| Venue admin and Venue operator | One holder admits participants and also sets their markets and fees. | No |
A role grant is recorded in the Audit trail with the account that made it. Review the holders of each role pair periodically, because the platform will not warn when one account holds both.
Frequently asked questions
Does the platform warn when one account holds two conflicting roles?
No. A grant succeeds regardless of the roles the account already holds, and the Console shows no conflict marker. Compare the holder lists on the Roles tab of Admins & roles to find overlaps.
Which controls need a second person without any role setup?
The five 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 an organisation Admin?
No. The organisation Admin role is a membership role checked by the Console and Platform API. The on-chain Admin role is held by an address and checked by the contracts. An organisation Admin has no contract authority until an address they control holds the matching on-chain role.
How many roles does DALP have?
The count depends on what is counted. The role vocabulary has 27 on-chain roles, 20 of them human and seven held by contracts. Organisation membership adds three roles and trading venues add three more. The sets are separate, so DALP does not publish one combined number.