Role Grant
A role grant turns an institution's segregation-of-duties policy into a check the ledger itself runs before every privileged call.
An address attempting a privileged call is checked against the access manager's role grants, not against anything a screen shows. If the role is present, the call passes its authorization check. Other checks can still reject it. A missing or revoked role makes the call revert.
A role grant lives in one of two access managers, system-wide or per token, and that manager alone decides whether the caller holds the role. System Manager and Auditor sit in the system-wide manager, Custodian and Supply Management in a token's own, and standing in one says nothing about the other.
Granting or revoking a role needs the target role's own admin role, and every admin chain traces back to one DEFAULT_ADMIN_ROLE per access manager.
A Console screen and an on-chain role check are two different systems. A button appearing does not mean the transaction behind it will succeed.
Why a role grant matters
A role grant turns "who is allowed to do this" from a policy your institution writes down into something the ledger itself enforces. Naming who can mint, move funds, or only view is the segregation-of-duties control your compliance function already expects, expressed on chain instead of in a spreadsheet.
Every operation an asset goes through after issuance is a call gated by a role in exactly this sense: paying a coupon, freezing a holding, collecting a fee. Asset Lifecycle names that as the shape of an asset's whole working life after issuance, and a role grant is the one check every stage of it relies on.
The platform splits authority into named roles rather than one broad administrator flag. A Token Manager can deploy and configure a security token. A separate Funds Manager can withdraw from its sale proceeds instead, kept apart from sale administration on purpose. The person who opens a sale is not automatically the person who can move the money it raises. An Auditor role exists purely to view permissions, identities, audit logs, and system state, and has no power to change anything.
Revocation is immediate, not a request that takes effect at the next login. That gives a board asking who can move client funds one place to check: the access manager's own record, the same one the chain enforces.
Who can do what, day to day
A role grant decides which team member can complete which task, whether the role is a system-wide assignment like Token Manager or an asset-specific one like Custodian.
The platform's named roles map onto a real operational split of duties. System Manager bootstraps the deployment and manages upgrades. Identity Manager and the separate Organisation Identity Manager register and recover identities, at the person level and the organisation level respectively. Token Manager deploys and configures tokens. Claim Issuer attaches identity claims, though holding that role alone does not make an address a trusted source. Trust is a separate decision made in the trusted issuers registry. Gas Manager funds and rotates the infrastructure that sponsors transactions. That check runs off chain, in the API and UI layer that fund and rotate it. The paymaster's own withdrawal and stake operations are gated on chain by System Manager, not Gas Manager, because they move funds out of the paymaster.
A role revoked mid-shift blocks the very next call that role would have covered, including a retry of a request already queued. The person is not logged out. The block happens only when the transaction reaches the access manager, not before.
Two access managers, not one
Two kinds of access manager hold role grants on a DALP deployment: one system-wide instance for platform-level roles, and one per token for that asset's own roles. A single admin address can hold broad standing in one and no standing at all in the other. The two contracts do not automatically mirror each other's grants. One exception: the token factory that deploys a token's access manager keeps a standing DEFAULT_ADMIN_ROLE on it alongside the account that created the token.
The system access manager is a single upgradeable contract holding the platform's system-level roles: System Manager, Identity Manager, Organisation Identity Manager, Token Manager, Compliance Manager, Claim Policy Manager, Claim Issuer, Auditor, Gas Manager, and more. It also holds the module-level roles contracts grant each other during bootstrap. The token access manager is the equivalent contract for a token's own roles: Governance, Supply Management, Custodian, Emergency, Sale Admin, and Funds Manager. It is deployed behind its own proxy and retrieved through the system contract rather than hand-rolled per token.
Both build on the same access-control foundation. Granting and revoking a role is itself gated: a caller needs the target role's own admin role, and that admin chain is walked back to DEFAULT_ADMIN_ROLE, the one role that can set every other role's admin.
Addon contracts can define their own narrower role sets again, granted through an access manager owned by the addon. The Trading Venue addon is a worked example: each venue deliberately splits the operator who configures markets from the submitter that settles trades, each function gated by its own role check. Nothing on chain stops an admin granting both roles to one address. The two are meant for different kinds of holder: the submitter role belongs to the backend settlement-submitter system signer and should never go to a human account, while the operator role belongs to the human who configures the venue. The venue's access manager makes that split possible. It does not enforce which kind of address holds which role.
The two managers differ in how they are reached, not only in which roles they hold.
System access manager
One upgradeable instance for the whole deployment. A caller reaches it directly. Its own DEFAULT_ADMIN_ROLE chain is the only one that can grant System Manager, Auditor, Gas Manager, and the rest.
Token access manager
One instance per token, deployed behind its own proxy and retrieved through the system contract rather than hand-rolled per token. The token factory that deployed it keeps a standing DEFAULT_ADMIN_ROLE on it, alongside the account that created the token.
Holding a role in one says nothing about the other: a Token Manager still needs a role in a token's own access manager to act on that token directly.
Checking a role before you rely on it
hasRole(role, account) is a plain view call against whichever access manager holds the role, and every governed contract exposes accessManager() so a caller can find the right instance without guessing. Read hasRole on chain for the exact current answer, or read the platform's indexed access-control views, which resolve the same roles into named flags for a faster lookup that can lag the block a change landed in. Check one of the two before submitting a transaction that depends on the answer: a role-management call from a caller who lacks the target role's own admin role reverts with the access manager's unauthorized-account error. Recover by reading getRoleAdmin(role) for the admin role that can grant it, following that chain back to DEFAULT_ADMIN_ROLE if needed, and asking a holder of that role to act.
Every role identifier but one is a hash of a name, defined once as a constant so integrations reference the constant rather than recompute the hash. The exception is DEFAULT_ADMIN_ROLE itself, the zero value OpenZeppelin's access-control base reserves. Two shapes of batch helper exist: one applies one role to a list of addresses, gated the same as a single grant or revoke, and the other applies a list of roles to one address. On the system access manager, that second shape is gated to DEFAULT_ADMIN_ROLE specifically, stronger than a single role's own admin check. A caller who can grant one role at a time can still be refused the multi-role helper. The token access manager's equivalent has no such extra gate. Confirm which manager and which helper you are calling before assuming one caller can use both the same way.
Renouncing a role, including through the multi-role helper, lets a holder remove their own permission, and an authorized administrator can grant it again. Removing the last DEFAULT_ADMIN_ROLE holder can leave default-admin-controlled roles with no recovery path, so confirm another holder exists before removing one. Separately administered roles keep their own configured administrators regardless.
Meta-transactions resolve the real caller rather than the trusted forwarder relaying it, so a role check inside a sponsored call still checks the real caller. The system access manager also exposes hasAnyRole, a set-membership read some of its own gated functions use internally. The token access manager has no equivalent, so a caller checking a per-asset role checks hasRole once per role instead.
On-chain role, Console permission, delegated authority
An on-chain role, a Console permission, and delegated authority sound interchangeable but answer different questions. Only the on-chain role is the guarantee the access manager itself checks before a privileged call runs. A Console permission just decides what a screen renders, and delegated authority changes whose context an operator acts in without granting any role at all.
An on-chain role lives in an access manager and is checked at the moment of the call. A missing or revoked role reverts the transaction. A Console permission, such as the flag that shows or hides the platform's own admin navigation, is an off-chain decision about what a screen renders. Most Console controls gate on the platform's indexed view of those on-chain roles, refreshed as new blocks index rather than instantly. The admin-navigation flag is the exception: a separate off-chain switch gates it and never touches the access manager. Neither kind of permission has power over the chain. A screen can show a control to someone whose on-chain role was revoked an hour ago, and the underlying call still reverts.
Delegated authorityDelegated Authority lets a signed-in operator work inside another party's account. One check decides who may enter; the party's own roles decide the rest.Read the concept is a third, separate thing again. Acting as another participant decides whose context an operator steps into. It does not itself grant that operator any role. What the operator may then do is governed entirely by the on-chain roles of the account executing the call, exactly as if they held them directly. Entering a context widens nothing on its own, and a reviewer asking who can do a given task needs the answer from the access manager, not from what a screen happens to show or which party someone was acting as.
Frequently asked questions
Does a role apply to every asset, or just one?
It depends which access manager the role lives in. Addon roles are the case worth knowing separately. A role an addon defines, such as a Trading Venue's operator and submitter roles, is checked in that venue's own access manager and grants no standing on another venue. Per-asset roles, like Custodian or Governance, are checked against a single token's own access manager. Holding Custodian on one security token grants no standing on a second token deployed later, even under the same organisation.
What happens to work already underway when a role is revoked?
Nothing already confirmed on chain is undone: revocation is not retroactive, and a transaction that passed the access manager's check before the revocation keeps its effect permanently. What still needs handling is the indexer's own lag: the revocation first lands as a provisional event, access-control.role-revoked.provisional, and can be followed by a retraction, access-control.role-revoked.retracted, if a reorg reverses the block it was read from. A grant follows the same two-stage lifecycle. Store the event ID, idempotency key, role, account, and access manager address so a retraction updates the same record instead of creating a duplicate.
Who can upgrade the access manager contracts themselves?
The two managers differ here too. The system access manager authorizes its own upgrade: the call needs DEFAULT_ADMIN_ROLE or the System Manager role, checked on that same contract. The token access manager has no equivalent function of its own. Its proxy resolves its logic address from the system contract on every call. Every token access manager on the deployment upgrades when the system contract's registered implementation changes. No token's own admin can move or block that change.
Who grants the very first role on a new deployment?
The access manager grants DEFAULT_ADMIN_ROLE to a fixed list of initial admin addresses at deployment, before any other role exists. From there, DEFAULT_ADMIN_ROLE, or a role it delegates admin authority to, grants every other role. The system access manager and each token access manager hold their own separate instance of that chain, and an admin on one contract has no standing on the other, aside from the token factory's own standing grant noted above.
Transfer-Path Compliance
Transfer-Path Compliance enforces a regulated token's rules inside the on-chain transfer itself, so a movement that fails any rule reverts and never settles.
Delegated Authority
Delegated Authority lets a signed-in operator work inside another party's account. One check decides who may enter; the party's own roles decide the rest.