Per-Asset RBAC

Purpose: Define the per-asset role model that governs who can perform which operations on each token contract, and the separation-of-duties invariants that prevent unilateral action.

• Doc type: Reference
• What you'll find here:
  • All seven per-asset roles from DALPAssetRoles.sol with scope and key actions
  • Separation-of-duties invariants
  • Token holder permissions
  • Link to the full 4-layer authorization taxonomy
• Related:
  • Asset Contracts
  • Authorization
  • Token Features
  • Legacy-Equivalent Presets
  • Deployment Architecture

---

Per-asset role model

Every token contract — DALPAsset and specialized types — uses the same seven roles defined in DALPAssetRoles.sol. Roles are scoped per asset: holding GOVERNANCE_ROLE on Token A grants no power over Token B.

Sale Admin and Funds Manager are available only on assets with the token sale addon attached. They have no effect on tokens without a sale.

---

Separation-of-duties invariants

The role model enforces the following invariants. No single role can act unilaterally across operational boundaries:

• Admin grants roles but has no operational powers --- cannot mint, burn, freeze, pause, or configure. This prevents the role-granting authority from also executing privileged operations.
• Supply Management cannot freeze; Custodian cannot mint --- operational segregation ensures that the entity issuing tokens is not the same entity that can freeze or recover them.
• Emergency is limited to pause and recovery --- cannot mint, configure compliance, or execute forced transfers. The incident-response role can halt the system but cannot alter its state.
• Governance configures policy; Supply Management executes issuance --- the entity that sets compliance rules and identity contracts does not control token supply.
• Sale Admin configures sales; Funds Manager withdraws proceeds --- separating sale lifecycle management from fund withdrawal prevents a single operator from both launching a sale and extracting its funds.

These invariants hold for all asset types. The contract enforces them via OpenZeppelin AccessControl modifiers --- violations revert on-chain.

---

Token holder permissions

Any address holding a token balance can perform the following actions, subject to compliance module checks:

• Transfer tokens --- standard ERC-20 transfers, validated by attached compliance modules before execution
• Redeem at maturity --- if Maturity Redemption is attached, holders can redeem tokens after the maturity date
• Vote and delegate --- if Voting Power is attached, holders can delegate voting weight and participate in governance
• Claim yield --- if Fixed Treasury Yield is attached, holders can claim accrued yield distributions

Token holder actions require no on-chain role assignment. The holder's address must pass the identity and compliance checks configured by the Governance role.

---

Full authorization taxonomy

The seven per-asset roles are Layer 3 of the four-layer DALP authorization model:

For the complete taxonomy --- including all 26 roles across all four layers, the dual-layer permission model, and multi-tenant architecture --- see Authorization.

---

See also

• Asset Contracts --- contract types and common foundation
• Authorization --- full 4-layer role taxonomy with 26 roles
• Token Features --- runtime-pluggable feature catalog
• Compliance Modules --- transfer and supply rule engine