Authorization
DALP enforces authorization through a dual-layer model: off-chain platform roles via Better Auth control API and console access, while on-chain roles in Solidity contracts govern blockchain operations. 26 distinct roles span platform, people, asset, and system module layers.
Purpose: How the platform decides what authenticated users and contracts are allowed to do.
- Doc type: Reference
- What you'll find here:
- Dual-layer permissions model (off-chain + on-chain)
- 26 roles across 4 layers
- Per-asset permission matrix
- Multi-tenant architecture
- Related:
Authorization architecture
The on-chain AccessManager contract is the authoritative source for all role assignments in DALP. This is a key architectural invariant: roles granted or revoked on-chain are immediately reflected in the UI — there is no separate off-chain permission database.
How the authority chain works:
- Role assignments are made directly on-chain via the
AccessManagercontract - Role events (
RoleGranted,RoleRevoked) are emitted and indexed by DALP's chain indexer - The UI queries indexed on-chain state — never a separate database — to determine what features and actions to render
- Write operations require: (1) an active platform session (Better Auth) AND (2) the appropriate on-chain role — neither alone is sufficient
- Role granted on-chain → indexer processes the event → UI reflects the change immediately
Key invariant: The chain is the source of truth. If a role is revoked on-chain, the UI hides or disables the corresponding operation without any manual synchronization step.
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 only a valid session. Write operations require both the platform permission and the on-chain role.
Role taxonomy
26 distinct roles organized into four layers (excluding one deprecated role):
| Layer | Scope | Count | Roles |
|---|---|---|---|
| 1. Platform | Off-chain (Better Auth) | 3 | owner, admin, member |
| 2. System People | On-chain (DALPPeopleRoles.sol) | 9 | systemManager, identityManager, tokenManager, complianceManager, claimPolicyManager, organisationIdentityManager, claimIssuer, auditor, feedsManager |
| 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) | 7 | systemModule, identityRegistryModule, tokenFactoryRegistryModule, tokenFactoryModule, addonFactoryRegistryModule, addonFactoryModule, trustedIssuersMetaRegistryModule |
Layer 1: Platform roles
Organization-scoped, managed by Better Auth.
| 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, system state |
| feedsManager | Register, replace, and remove feeds in the FeedsDirectory |
Note:
addonManagerfrom v1 is still defined inDALPPeopleRoles.solfor backward compatibility but is deprecated and 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 |
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 Better Auth's organization system.
- Single-tenant: All users in one organization. Creation blocked after the first exists.
- Multi-tenant: Separate organizations with isolated membership, roles, assets, compliance records, and audit trails.
Tenant boundaries: Isolation enforced at the database query level on every API request. Cross-tenant operations are not possible.
Authentication
DALP implements multi-method authentication using Better Auth with passkeys, API keys, session cookies, and wallet verification. Enterprise SSO protocols are supported via installable plugins but are not active by default.
Identity & Compliance
Architecture of the DALP identity and compliance system built on ERC-3643 and OnchainID (ERC-734/735). Covers on-chain identity binding, claim-based permissions, compliance engine orchestration, and the two-layer policy model.