Authorization
DALP authorizes asset operations through platform RBAC, organization context, wallet verification for browser-session writes, and on-chain roles for the contract action being requested.
DALP authorization answers two questions before an asset operation can continue:
- Can this caller use the protected console or API route for the active organization?
- Does the submitting wallet or service have the on-chain role required for the contract action?
Use this page to design operator roles, review segregation of duties, or explain why organization-owner access is not enough to mint, burn, pause, recover, or change token policy.
Related security references:
System context
Authorization architecture
DALP separates platform access from blockchain authority.
Platform RBAC is organization-scoped. It decides whether a signed-in user, API credential, or service can reach a protected console or API route for the active organization.
On-chain authorization is role-scoped. It decides whether the submitting wallet or contract address can perform the requested token, identity, compliance, or system operation.
How the authority chain works:
- The caller authenticates through a platform session or API credential.
- DALP resolves the active organization and resource scope for the request.
- The protected route checks the required platform permission before it prepares a write operation.
- For browser-session blockchain writes, DALP also requires wallet verification through PIN, secret code, or OTP before signing can proceed.
- The contract action still needs the matching on-chain role. DALP indexes role events such as
RoleGrantedandRoleRevokedso the console can render the current permission state.
Key invariant: platform access does not grant blockchain authority by itself. Organization owner or admin access can let a user administer the platform, but minting, burning, pausing, recovering wallets, changing token policy, or managing compliance still requires the relevant on-chain role and the applicable signing gate.
Dual-layer permissions
Every blockchain operation requires both off-chain and on-chain authorization. Missing either layer results in denial.
Key invariant: Read operations require a valid session and any route-specific read permission. Write operations require the platform permission for the route and the on-chain role for the contract action.
How platform RBAC maps to system actions
Platform RBAC is organization-scoped. The platform permission check controls who can use DALP's protected console and API routes before an on-chain transaction is built. Platform RBAC does not grant blockchain authority by itself.
| Platform role | DALP permissions | Typical use |
|---|---|---|
| admin | Organization management; settings read, list, upsert, remove, and global theme; system read, list, create, and operate; exchange-rate read/list; webhook management and compliance recall | Platform administration and sensitive system operations |
| owner | Organization-owner permissions; user list/get/update; settings read, list, upsert, and remove; system read, list, and create; exchange-rate read/list; webhook management and compliance recall | Organization ownership, user administration, and configuration |
| member | Organization-member permissions; settings read/list; system read/list; exchange-rate read/list | Standard operator access with narrower permissions |
For protected routes, DALP checks the required platform permission against the signed-in account or active organization. If the platform permission is missing, the request stops before any contract call is prepared. If the platform check passes, the requested blockchain action still needs the matching on-chain role.
Role taxonomy
DALP uses three platform roles and 27 current on-chain roles. The on-chain role map includes people roles, per-asset roles, and system module roles.
One deprecated add-on manager people role remains in the contracts for compatibility. It is not part of the current operating count.
| Layer | Scope | Count | Roles |
|---|---|---|---|
| 1. Platform | Off-chain platform access | 3 | owner, admin, member |
| 2. System People | On-chain (DALPPeopleRoles.sol) | 10 | systemManager, identityManager, tokenManager, complianceManager, claimPolicyManager, organisationIdentityManager, claimIssuer, auditor, feedsManager, gasManager |
| 3. Per-Asset | On-chain (DALPAssetRoles.sol) | 7 | admin (DEFAULT_ADMIN_ROLE), governance, supplyManagement, custodian, emergency, saleAdmin, fundsManager |
| 4. System Modules | On-chain (DALPSystemRoles.sol) | 10 | systemModule, identityRegistryModule, tokenFactoryRegistryModule, tokenFactoryModule, addonFactoryRegistryModule, addonFactoryModule, trustedIssuersMetaRegistryModule, complianceEngineModule, tokenComplianceFactoryModule, tokenIdentityRegistryFactoryModule |
Layer 1: Platform roles
Organization-scoped, managed by DALP platform access controls.
| Role | Capabilities |
|---|---|
| owner | Full administrative access, role assignment, organization configuration |
| admin | User management, platform configuration |
| member | Standard operations based on assigned permissions |
Layer 2: System people roles
Assigned to human operators. Defined in DALPPeopleRoles.sol.
| Role | Responsibilities |
|---|---|
| systemManager | Bootstrap system, manage upgrades, register factories/addons/modules |
| identityManager | Register and recover identities, manage user onboarding |
| tokenManager | Deploy and configure tokens |
| complianceManager | Register compliance modules, configure global settings, manage bypass |
| claimPolicyManager | Manage trusted issuers and claim topics |
| organisationIdentityManager | Manage claims for the organisation identity |
| claimIssuer | Create and attach claims to identity contracts |
| auditor | View-only: permissions, identities, audit logs, and system state |
| feedsManager | Register, replace, and remove feeds in the FeedsDirectory |
| gasManager | Manage paymaster deposits and paymaster configuration |
Note: The deprecated add-on manager role remains excluded from the count above.
Layer 3: Per-asset roles
Scoped per token contract. Defined in DALPAssetRoles.sol.
| Role | Responsibilities |
|---|---|
| admin (DEFAULT_ADMIN_ROLE) | Grant and revoke all other per-asset roles |
| governance | Configure identity registry, compliance modules, features, metadata |
| supplyManagement | Mint, burn, batch operations, set supply cap |
| custodian | Freeze/unfreeze, forced transfers, wallet recovery |
| emergency | Pause/unpause operations, recover stuck ERC20 tokens |
| saleAdmin | Manage token sale configuration and lifecycle |
| fundsManager | Withdraw funds from token sales |
Layer 4: System module roles
Assigned to contract addresses. Defined in DALPSystemRoles.sol.
| Role | Responsibilities |
|---|---|
| systemModule | Manage system modules, register compliance modules |
| identityRegistryModule | Modify identity registry storage |
| tokenFactoryRegistryModule | roleAdmin of tokenFactoryModule |
| tokenFactoryModule | Add token contracts to compliance allow list |
| addonFactoryRegistryModule | roleAdmin of addonFactoryModule |
| addonFactoryModule | Add addon instance contracts to compliance allow list |
| trustedIssuersMetaRegistryModule | Add trusted issuers to the registry |
| complianceEngineModule | Deploy compliance module instances |
| tokenComplianceFactoryModule | Create per-token compliance proxies |
| tokenIdentityRegistryFactoryModule | Deploy per-token identity registries |
Role scopes for common operator personas
DALP separates platform membership from on-chain operating authority. A user can sign in to the platform without having every on-chain role, and a wallet can hold one role without inheriting unrelated asset or system powers.
| Persona or responsibility | Typical scope | Roles to assign |
|---|---|---|
| Platform administrator | Organisation setup and user access | Platform owner or admin, plus on-chain roles only for the administrator's system or asset responsibilities |
| System operator | System configuration, upgrades, factories, shared modules, and paymaster operations | systemManager, with narrower roles such as tokenManager, complianceManager, identityManager, feedsManager, or gasManager when the operator only owns one domain |
| Compliance operator | Trusted issuers, claim topics, compliance modules, and user eligibility controls | complianceManager, claimPolicyManager, claimIssuer, or identityManager, depending on whether the user configures policy, issues claims, or manages identities |
| Asset operations team | Day-to-day actions for one tokenized asset | Per-asset roles such as governance, supplyManagement, custodian, emergency, saleAdmin, or fundsManager on that asset |
| Auditor or regulator view | Review permissions, identities, audit logs, and system state without operating the asset | Platform access plus the system-level auditor role; do not grant write roles unless the same person also performs operations |
Use the narrowest role set that matches the person's responsibility. System people roles apply across the system. Per-asset roles apply only to the specific token contract.
Segregation of duties for administration
DALP supports segregation of duties by splitting account access, platform permissions, system roles, and per-asset roles. A policy administrator, contract administrator, compliance operator, and issuance operator can be assigned different role sets so one persona does not automatically inherit the others.
| Control area | DALP mechanism | Practical separation |
|---|---|---|
| Account and session access | Sign-in session, active organization context, optional account 2FA, and fresh-session checks for sensitive account operations | Proves who is using the console before authorization starts |
| Console and API access | Organization-scoped platform permissions checked before protected routes continue | Lets platform owners and admins grant console capabilities without granting every on-chain role |
| Policy and compliance administration | complianceManager, claimPolicyManager, claimIssuer, and identityManager system roles | Separates compliance module configuration, claim-topic policy, claim issuance, and identity operations |
| Contract and asset administration | Per-asset governance, supplyManagement, custodian, emergency, saleAdmin, and fundsManager roles | Separates asset configuration, mint and burn authority, custody actions, emergency controls, sale administration, and fund withdrawal |
| Audit and review | auditor role and indexed role events | Gives reviewers visibility without granting write authority |
A deployment can enforce independent control by assigning these roles to separate accounts, wallets, custody policies, or approval groups. DALP does not treat organization owner or admin as automatic permission to mint, burn, recover wallets, or change token policy. Those actions still need the matching on-chain role and, for browser-initiated blockchain writes, wallet verification before signing.
DALP does not impose a universal rule that one human can never hold two roles. If your operating model forbids the same person from changing policy and executing issuance, encode that rule in role assignment, custody approval policy, and operational review. The platform gives the separate permissions and failure gates; the deployment policy decides who may hold them together.
Per-asset permission matrix (summary)
| Action | Required role | Asset-specific notes |
|---|---|---|
| Set OnchainID / identity registry / compliance | governance | All asset types |
| Set features / metadata | governance | DALPAsset only (Configurable extension) |
| Set yield schedule / mature bond | governance | Bond only |
| Mint / burn / batch operations | supplyManagement | RealEstate and PreciousMetal: no burn |
| Set supply cap | supplyManagement | Bond and RealEstate only |
| Freeze / forced transfer / recovery | custodian | All asset types |
| Pause / unpause / recover ERC20 | emergency | All asset types |
| Configure / manage token sale | saleAdmin | Assets with sale addon |
| Withdraw sale funds | fundsManager | Assets with sale addon |
See Legacy-Equivalent Presets for per-instrument feature and compliance configuration across all seven asset types.
Multi-tenant architecture
The platform supports configurable multi-tenancy through organization-scoped membership and permissions.
- Single tenant: all users operate inside one organization, and organization creation is blocked after the first organization exists.
- Multi tenant: separate organizations have isolated membership, roles, assets, compliance records, and audit trails.
Tenant boundary: every API request resolves organization context before protected data or actions continue. That organization context is separate from on-chain role checks, so a user needs both the right tenant-scoped platform permission and the relevant on-chain role for write operations.
Authentication
DALP authenticates browser operators and API integrations before authorization and wallet verification decide what each request may do.
Identity and compliance control model
How DALP links wallets to OnchainID identities, keeps evidence off chain, trusts claim issuers by topic, and evaluates claims before regulated token operations execute.