Roles and permissions shows who holds each on-chain role in the organisation, and lets a Permission manager grant and revoke a person's roles and check the result. An on-chain role is a permission held by a wallet in an access manager contract, which checks it before a privileged call such as a mint, a freeze or a compliance change. A few system roles, such as “Auditor”, unlock Platform API and Console actions only. Roles sit in three scopes: system roles on the organisation's system access manager, asset roles on one token's access manager, and offering roles, which are asset roles on the token an offering sells.
On-chain roles are separate from the roles that control sign-in. The organisation role, Owner or Member, and the platform role, Administrator or Member, grant no contract authority. The “Roles and permissions” page and several other Console screens open for a holder of an on-chain role, whatever the person's organisation role.
The organisation's own wallet, whose key the platform manages, also sends role changes: it grants the on-chain roles an invitation names when the invitee accepts, and revokes a time-bound system role when it ends. An owner changes a person's organisation role on Users.
Role Grant explains the model, and the Roles and segregation of duties reference lists every role and what it permits.
A person can have two wallets. The signing wallet holds the key that approves their transactions. When the organisation uses smart wallets, a smart wallet executes those transactions. The access manager checks the wallet that executes the call, so in an organisation that uses smart wallets the smart wallet must hold the role.
The People tab of Roles and permissions lists each person with their role group counts and risk.
Each row shows the person's email, when they were last active, a count for each of the Platform, Compliance, Assets and Oversight role groups, and a Risk column that names critical roles and counts elevated ones. A notice above the table appears when only one person holds the Permission manager role.
Steps
Review who holds each system role
Open “Organisation settings”, then Roles and permissions. The page opens on the “People” tab. “People” and “Roles” each have their own link, so a reload keeps the tab you were on. An organisation with the custody gateway add-on also has an “Add-on roles” tab with its own link.
The “People” tab lists one row per person, in these columns:
- Name, then on a wide screen “Email” and “Last active”.
- Platform, “Compliance”, “Assets” and “Oversight”, one per role group with a count of the roles the person holds in it.
- Risk, which names the two critical roles, “Permission manager” and “System manager”, and counts the elevated ones, such as “2 elevated”. The reference lists the elevated roles.
An asset role counts once per role and shows how many assets grant it, such as “3 assets” beside “Custodian”. A person who holds a role through several wallets counts once, and the role counts include every wallet the person holds, not only the signing and operations wallets the row names. Expand a row to see every role by group and the person's signing wallet, with a copy button.
Narrow the list with “Role”, “Role group” and “Risk” in the toolbar, and search with “Search by name or wallet…”. The search also matches the identifiers of the roles a person holds, such as complianceManager, but not the role labels the table shows. When exactly one person holds “Permission manager”, not counting contracts or the organisation's own wallets, a notice says so and warns “If this wallet is lost, nobody can grant or revoke roles again.” Grant “Permission manager” to a second person, so that the loss of one wallet does not stop role changes.
Grant or revoke system roles for one person
Choose Grant role in the page header, select a person's row, or choose “Change roles” on the row. On the “Roles” tab, “Add holder” opens the same editor with that role already selected.
- Under “Account”, search for the person. The change reaches every wallet the organisation can act on for that person: their signing wallet and, when the organisation uses smart wallets, their smart wallet. The editor shows the roles of one wallet and says “Roles shown reflect the participant's primary wallet. Changes apply to every wallet they own.” To change one address only, choose Use specific wallet instead.
- Select or clear roles in the four groups. The editor shows the person's asset roles read-only under Asset roles, because those change on each asset.
- Watch the status line under the roles. While you change the selection, the Console asks the platform whether it would accept the change. A refusal shows in the editor with its fix, for example that the change would remove the last “Permission manager” or that it breaks a segregation pair. A segregation refusal names each pair, such as “Custodian cannot be held with Governance on the same contract.”, and says what to do. When the rule asks for a reason, which the editor cannot send, the line says to make the grant through the Platform API. The rules are set in General. Review stays disabled, so you learn the refusal before you confirm. The check stores nothing and signs nothing. The platform checks again when you save, because the roles can change in between.
- Choose Review. The summary lists the roles under “Grant” and “Remove”.
- Choose Save and confirm with your transaction PIN or transaction code.
The system role editor has no end date. A time-bound system role exists only through the Platform API.
With a person selected, the editor does not remove “Permission manager”. To take that role away, switch to Use specific wallet instead and remove it from one wallet at a time. The platform sends all grants first, then all revokes. It sends a revoke of “Permission manager” and any revoke on your own wallet last, so you keep the authority to finish the change.
Grant or revoke the same roles for several people
On the “People” tab, select the people and choose Grant roles or “Revoke roles” in the selection bar. Pick the roles, check the line that counts who changes, such as “3 people change”, then confirm once with your wallet verification. One batch covers at most 50 people. The Console sends every person you select, and the platform refuses a larger batch with “Send at most 50 participants in one batch”. Select 50 people or fewer and send the rest in a second batch.
The sheet states how the platform sends the batch. With a smart wallet it reads “Your smart wallet sends every change as one transaction, so the batch lands whole or not at all.” With a signing wallet it shows “Changes are sent one call at a time”: if one call fails, the calls before it stay applied. In Revoke roles, you cannot select “Permission manager”. Remove it per person from the role editor, one wallet at a time. When the revoke removes a role you hold yourself, the sheet warns “You are in this selection”. Picking a role you do not hold shows no warning, even with yourself selected.
Export an access review
On the “People” tab, select the people to include, or select every row, and choose Export CSV in the selection bar. The selection bar shows only to a “Permission manager”. The file has one row per person with “Name”, “Wallet”, “Role” and “Risk”. “Wallet” is the person's signing wallet. “Role” lists every system role the person holds and, for each asset role, the number of assets that grant it.
A System manager has no selection bar and exports the table as it shows with “Export” in the toolbar.
The file shows who holds which role at the time of the export. It does not name the assets, show end dates, or include wallets that hold only asset roles, venue roles or add-on roles. Take those from each asset's Permissions tab and from the “Roles” tab. For who changed a role and when, use the Audit trail: its entry for a role change shows the roles before and after the change.
Copy roles to smart wallets
When the organisation uses smart wallets, a person's roles must sit on the smart wallet that executes their transactions. A person whose signing wallet holds roles their smart wallet lacks shows Out of sync.
- On the “People” tab, open the row's menu and choose Sync permissions to copy the missing system roles.
- On an asset's “Permissions” tab, the “Warning” column carries the same flag. Choose Sync permissions on the row.
- On the “Overview” tab of an asset with such holders, a banner reads “Roles not migrated to smart wallets”. A “Permission manager” of the asset chooses Migrate roles, which grants the missing roles to the smart wallets of up to 200 listed people in one run. Anyone else sees “The token admin must migrate these roles. Ask them to open this token and run the migration.”
The sync grants only the missing roles. It leaves the signing wallet's roles in place.
Grant add-on roles
The Add-on roles tab shows the roles of the custody gateway add-on, which sit in an access manager of their own: “Manager”, “Keeper” and “Screener”. It reads “One grant covers every gateway of the add-on. Managers change gateway settings and approve each other's changes. Keepers and screeners are the signers that move and check deposits.” It is the only tab a holder of “Gateway permission manager” sees, and it shows only to an organisation with the custody gateway add-on.
The “Add-on roles” tab lists each wallet with its custody gateway role, with “Search wallets” and a “Grant role” button.
- Select Grant role. The sheet “Grant a role” opens.
- Choose the “Role” and enter the Wallet address.
- Select Grant role. The tab confirms “The
<role>role grant to<wallet>is submitted.” and a refusal reads “The role could not be granted.” - To remove a role, select “Revoke” on the wallet's row, then Revoke role, or “Keep role” to stop. The tab confirms “The
<role>role revocation from<wallet>is submitted.”
The tab lists “Wallet” and “Role” columns. Without the custody gateway permission manager role it says “Only holders of the custody gateway permission manager role can grant or revoke these roles.” When the add-on is not deployed on the network, it reads “Custody gateway is not enabled on this network”, and an organisation owner deploys the add-on first. With no holder yet, it reads “Nobody holds a gateway role yet” and “Grant the manager role so someone can set up the gateway.”
Change asset roles on an asset
Open the asset and its Permissions tab. The table lists each holder with “Address”, “Roles”, “Ends” and “Warning”.
- Choose Grant role for a new holder, or “Change roles” on a holder's row. For a new holder, search for the person under “Account”, or choose “Use specific wallet instead” for one address. On a person's row, the change reaches every wallet of that person.
- Select or clear roles. The editor groups the asset roles in four groups. “Administration” holds “Permission manager”, “Compliance” holds “Governance”, “Operations” holds “Supply management”, “Custodian” and “Emergency”, and “Other” holds “Funds manager” and “Offering admin”. To let a person mint and burn the token, grant Supply management. The reference states what each role permits.
- To make the roles you add time-bound, set Ends. The field is optional, and the platform removes the roles you add at that time. The Console checks the end when you confirm the change: an end less than two minutes ahead fails with “Choose an end at least two minutes from now.” The Platform API accepts an end one minute ahead. The end applies only to roles the change adds.
- Watch the status line under the roles. While you change the selection, the Console asks the platform whether it would accept the change. A refusal shows in the editor with its fix, for example that the change would leave the asset with no “Permission manager” without an end, or that it breaks a segregation pair. Review stays disabled, so you learn the refusal before you confirm. The check stores nothing and signs nothing. The platform checks again when you save, because the roles can change in between.
- Choose Review. The summary lists the roles under “Grant” and “Remove” and repeats the end.
- Choose Save and confirm with your transaction PIN or transaction code.
Change offering roles on an offering
Open the offering under “Asset lifecycle”, then “Offerings”, and its “Permissions” tab. The table lists each “Account” with its “Role”. Choose Manage roles, search for the person in “Assign offering roles”, select or clear “Offering admin” and “Funds manager”, then continue and confirm. Give the two roles to different people: one runs the sale and the other withdraws what it collects.
This pair is one of the platform's default segregation pairs. The platform refuses a grant that puts both roles on one wallet only after the organisation saves and enables its segregation rules, which the reference describes. Until then, nothing stops one wallet holding both.
Read the Roles tab
The Roles tab shows the same data by role: one row per role, with the people and contracts that hold it. A person who holds a role through several wallets is listed once, with the number of wallets, and for an asset role the number of assets. A role the organisation's own wallet holds also carries “Organisation wallet”, and that wallet is listed under the organisation's name.
A system role held by one person, not counting contracts or the organisation's own wallets, carries “Single holder”, and a role nobody holds carries “No holder”. The top of the tab counts the roles with a single holder, such as “9 roles have a single holder”, and the people with only asset roles, such as “2 people hold only asset roles”. The second figure counts each person once, however many wallets they hold.
Those people are not on the “People” tab: you manage them on each asset's “Permissions” tab. Contract roles, which only platform contracts hold, stay behind “Show contract roles”. Search with “Find a role by what it allows”.
Where each role is changed
An offering role sits on the sold token's access manager, so it covers every offering of that token, not one sale. Each change in any of the three places is an on-chain transaction that you confirm with your wallet verification. Trading venue roles and the roles of the custody gateway add-on sit in access managers of their own: the Add-on roles tab shows the add-on roles, and Venue operations covers the venue roles.
Read roles without changing them
Three screens show roles without the controls to change them.
- A person's user page: open “Organisation participants”, then “Users”, select the person and open Roles & permissions. The page opens for a holder of “System manager”, “Identity manager” or “Verification issuer” on the system. “Organisation” shows their organisation role, “Member since” and, for a time-bound owner, “Owner role ends”. “System and asset roles” lists the system roles their wallets hold and, per asset role, how many assets grant it. The on-chain roles are read-only there, and an organisation owner can still change the organisation role. A user who can grant roles sees “Manage roles”, which opens the People tab.
- An asset you manage nothing on: when you hold no role on an asset, every tab of the asset shows Settings are read-only with “You don't hold a role that manages this asset, so its settings are read-only. Actions open to every holder or requester stay available.” The banner has no action. The “Permissions” tab still lists every holder.
- The People and Roles tabs as a System manager: a System manager without “Permission manager” sees both tabs with “Permission managers change roles.” in the header and no change controls.
Where a role change shows
A saved change shows a “Roles changed” toast, or “Roles granted” or “Roles revoked” after a bulk change, and the tables reload. The access manager enforces a grant or revoke once its transaction confirms on chain. The Console tables read the platform's record of the chain, which updates a few moments after the transaction confirms. When a row still shows the old roles, reload the tab.
At the end of a time-bound grant, the platform revokes the role on chain and the row drops it. For an asset role it also sends the access- webhook event once the end is less than 24 hours away, and access- after the revoke. A grant whose end has already passed when the platform first checks it sends only access-. A time-bound system role sends neither event. Every grant and revoke also reaches webhook subscribers as access- or access-.
Troubleshooting
The requested roles conflict.
The grant would put two roles the organisation keeps apart on one wallet. The message names each pair and its scope,
such as “Custodian cannot be held with Governance on the same contract.” Grant the second role to another person, or
remove the conflicting role in the same change. The platform always keeps Auditor apart from every other system
role it grants. It checks the organisation's own pairs only after the organisation enables its rules. The platform
runs these checks before it sends a role change. The access manager contract does not check role pairs, so a role
change sent to the contract outside DALP is not checked. The Console also refuses a grant that breaks a warn pair,
because the grant needs a written reason and the Console has no field for one. Send that grant through POST / or the token route with a reason. The segregation
reference lists
the default pairs and the modes.
The last system Permission manager cannot be revoked
On a token, the same refusal reads “The token's last Permission manager cannot be removed”. Without a Permission manager, nobody can grant or revoke a role on that access manager again, so the platform refuses a change that would remove the last holder. On an asset, a holder whose “Permission manager” role has an end does not count. Grant “Permission manager” to another person first, then remove the one you no longer need. A system on the current access manager version, and a token whose access manager counts its administrators, also refuse the change on chain, even outside the Console.
The system's administrator count is not initialised
The system's access manager was upgraded but has not counted its Permission manager holders yet. Until a holder of “Permission manager” or “System manager” on the system completes the upgrade by counting the holders, it refuses any change to who holds “Permission manager”. Other roles change as normal.
The role expiry is not allowed
An asset role change was refused for its end. Either the end was less than one minute after the request, or you tried to grant Permission manager on the asset while your own “Permission manager” role there has an end. Pick a later end, or ask a holder whose role has no end to make the grant. On the system route, an end less than one minute away returns “expiresAt must be at least one minute in the future.” instead.
Some role changes may already have been applied.
A batch sent from a signing wallet failed part-way, and the calls before the failure stayed applied. When the message names a transaction, open it to see each call's outcome. Reload the People tab, then send only the changes that are still missing.
Participant has no on-chain wallet
The role editor shows this warning with “The selected participant has no resolved wallet. Submitting will have no effect.” The person has no wallet the organisation can act on, so the change has nothing to reach. Finish the person's onboarding on Users, then grant the role.
The participant has no usable wallet
An asset role change for a person was refused, because the person has no wallet or one of their wallets is outside the organisation. Choose Use specific wallet instead and pick a wallet the organisation holds for that person.
The role is granted but the person still cannot act
Check that the wallet that executes their transactions holds the role. In an organisation that uses smart wallets, look for Out of sync and sync the roles. Check that the role is on the correct network and covers the action they try: an asset role on one token gives nothing on another, and an organisation role gives no contract authority.
API routes
The Console screens call the Platform API, and an integrator can call the same routes. Each role write route needs a wallet verification. The settings route does not. The API v2 reference holds the request and response schemas. For a time-bound system role, the expiresAt value must be at least one minute after the request.