# Per-asset RBAC Source: https://docs.settlemint.com/docs/architecture/components/asset-contracts/rbac Per-asset role-based access control separates token governance, supply, custody, emergency, and sale operations. Roles are scoped to one asset contract and do not grant authority over other assets. Per-asset RBAC controls who can change a token, issue or burn supply, pause operations, protect holders, or manage sale-specific work. The model is scoped per asset: a wallet with a role on one token has no authority over another token unless that role is granted there as well. ## Per-asset role model [#per-asset-role-model] Every DALP asset uses the same role set defined for asset access control. The Default Admin role manages role membership. Operational roles control specific token surfaces. | Role | Scope | Key permissions | | ----------------- | ---------------------------- | --------------------------------------------------------------------------------------- | | Default Admin | Role management | Grant and revoke all other per-asset roles; no token operations | | Governance | Configuration and compliance | Set identity contracts, compliance modules, DALPAsset-only token features, and metadata | | Supply Management | Minting and burning | Mint, burn, batch operations, and set supply cap | | Custodian | Asset protection | Freeze addresses or partial amounts, forced transfers, and wallet recovery | | Emergency | Incident response | Pause and unpause operations, and recover stuck ERC-20 tokens | | Sale Admin | Token sale addon | Manage token sale configuration and lifecycle | | Funds Manager | Token sale addon | Withdraw funds from token sales | Sale Admin and Funds Manager only matter when a token sale addon is attached to the asset. They do not add sale powers to tokens without a sale. ## Role boundary map [#role-boundary-map] Default Admin changes who holds roles. Governance changes policy and token configuration, with configurable token features limited to flexible DALPAsset contracts. Supply Management changes supply. Custodian handles freezes, forced transfers, and wallet recovery. Emergency handles pause and recovery paths. Sale roles apply only to sale-enabled assets. ![Role-based access control configuration for asset operations](/docs/screenshots/asset-designer/asset-designer-step-7-asset-permissions-config.webp) ## Separation-of-duties invariants [#separation-of-duties-invariants] DALP asset roles keep role administration separate from token operations. | Invariant | Meaning | | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Default Admin grants roles but does not operate the token | A role administrator cannot mint, burn, freeze, pause, or configure the asset through that admin role alone. | | Supply Management and Custodian are separate | The role that issues or burns tokens is not the same role that freezes balances, forces transfers, or recovers wallets. | | Emergency is limited to pause and recovery paths | The incident-response role can pause or unpause operations and recover stuck ERC-20 tokens. The role does not mint, configure compliance, or force transfers. | | Governance configures policy; Supply Management executes issuance | The role that sets identity, compliance, DALPAsset-only features, and metadata does not control token supply. | | Sale Admin and Funds Manager are separate | A sale operator can manage sale configuration and lifecycle without also withdrawing sale proceeds. | When a caller does not hold the required role on the asset, the on-chain access-control check rejects the operation. Granting the same role on a different asset does not satisfy the check. ## Token holder permissions [#token-holder-permissions] Token holder permissions come from balances and asset configuration, not per-asset role assignments. A holder can perform them only when the asset feature is available and the configured identity and compliance checks pass. | Holder permission | Condition | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Transfer tokens | The transfer must pass the asset's attached compliance modules. | | Redeem at maturity | [Maturity Redemption](/docs/architecture/components/token-features/maturity-redemption) must be attached and the maturity date must have passed. | | Vote or delegate | [Voting Power](/docs/architecture/components/token-features/voting-power) must be attached. | | Claim yield | [Fixed Treasury Yield](/docs/architecture/components/token-features/fixed-treasury-yield) must be attached and a completed distribution must be claimable. | Holders do not need a per-asset role for these operations. Their wallet still needs to satisfy the identity and compliance rules configured for the asset. ## How DALP surfaces role state [#how-dalp-surfaces-role-state] DALP represents role state as role-to-account assignments. Asset-scoped role views use the seven asset roles: `admin`, `governance`, `supplyManagement`, `custodian`, `emergency`, `saleAdmin`, and `fundsManager`. Role checks are address based. When a participant has more than one wallet, DALP role views can show the roles held by any wallet in the supplied wallet set. Treat that as a view of current role membership, not as a rule that moves authority across wallets. ## Full authorization taxonomy [#full-authorization-taxonomy] The seven per-asset roles are one layer of the DALP authorization model. | Layer | Scope | Where it applies | | ----------------- | -------------------------------- | ----------------------------------------------------------------------------------- | | 1. Platform | Off-chain API and console access | User sessions, API access, and organization context | | 2. System People | On-chain system-wide operations | System-level operations such as identity, feeds, compliance, and factory management | | 3. Per-Asset | On-chain per-token operations | Asset-specific token configuration, supply, custody, emergency, and sale operations | | 4. System Modules | On-chain contract-to-contract | Contracts that need system module authority | For the complete authorization model, including system roles and read-only audit roles, see [Authorization](/docs/architecture/security/authorization). ## See also [#see-also] * [Asset Contracts](/docs/architecture/components/asset-contracts) for the shared asset-contract foundation. * [Authorization](/docs/architecture/security/authorization) for the full authorization model. * [Change asset admin roles](/docs/user-guides/asset-servicing/change-asset-admin-roles) for the operator workflow. * [Claims and identity model](/docs/architecture/concepts/claims-and-identity) for identity and claim prerequisites. * [Compliance modules](/docs/architecture/security/compliance) for transfer and supply rule checks.