Administration operating model
Understand how DALP separates organisation administration, invitations, platform permissions, API keys, webhooks, providers, security settings, and operator wallets.
Use this page when you need to decide which administration surface to use before changing users, credentials, providers, webhooks, security settings, or platform wallets.
DALP administration is split across organisation membership, invitations, platform permissions, personal API access, outbound webhooks, provider configuration, account security, and operator wallets. The split keeps routine user administration separate from integration credentials, provider setup, account protection, and wallet funding.
Each surface answers a different operating question:
- Who belongs to the organisation?
- Which people still need to accept an invitation?
- What can each role administer?
- Which credentials act on behalf of an account?
- Where are outbound events sent?
- Which provider and security settings affect onboarding or signing?
- Which platform wallets need funding or monitoring?
Administration surfaces
| Surface | Where operators use it | What it controls |
|---|---|---|
| Organizations | Platform admin > Organizations | Organisation records, owners, member counts, asset counts, and organisation creation. |
| Users and participants | Participants > Users and user detail pages | User accounts, invitations, identity registration, KYC evidence, holdings, activity, and security follow-up. |
| Account API keys | Account > API keys | API credentials for the active organization context of the signed-in account. See organization and system scope before using a key in automation. |
| Webhooks | Organisation settings > Webhooks | Outbound endpoint delivery, signing secret lifecycle, delivery history, and endpoint settings. |
| Compliance providers | Organisation settings > Compliance & verification > Compliance providers | Provider credentials, hosted-flow settings, webhook authentication details, and provider monitoring. |
| Account security | Account > Security and user detail security views | Two-factor authentication, active sessions, passkeys, and account protection controls that are enabled for the deployment. |
| Operator wallets | Organisation settings > Operations > Operator wallets | Operator-wallet accounts and native balances used for platform operations. |
Role and permission model
Use roles to decide who can administer the platform. Use the surface map above to decide where that administration happens.
DALP combines three permission layers. Organisation roles decide the day-to-day administration available to a signed-in user. System roles govern platform operations such as identity, claims, compliance modules, feeds, paymasters, and operator wallets. Token roles govern actions on a specific asset, such as minting, burning, pausing, freezing, role changes, metadata updates, fee changes, collateral updates, and compliance module changes.
| Layer | What it answers | Examples |
|---|---|---|
| Organisation roles | What can this user administer in the organisation? | Admin, owner, and member access to settings, users, systems, exchange rates, and webhooks. |
| System roles | Which platform operation can this actor run? | System manager, identity manager, claim issuer, compliance manager, feeds manager, gas manager, and auditor. |
| Token roles | Which action can this actor run on a specific asset? | Admin, governance, supply management, custodian, emergency, sale admin, and funds manager roles for the relevant action. |
The built-in organisation roles have these current boundaries:
- The admin role can list and create organizations, manage platform settings, operate systems, read exchange rates, and manage webhooks.
- The owner role can manage users, platform settings, systems, exchange rates, and webhooks inside the organisation.
- The member role can read settings, systems, and exchange rates, but does not manage webhooks.
Some views also check on-chain or system-level roles before showing operational data. For example, operator-wallet access is available to administrators, system managers, or gas managers because that page is about operational wallet funding and monitoring. Token workspaces use token roles for asset actions, so organisation ownership alone does not automatically grant permission to mint, freeze, pause, or change asset-level controls.
Operating flow for administrators
- Confirm the active organisation before creating users, invitations, API keys, providers, or webhooks. API keys, provider settings, and webhook permissions are evaluated against the organisation context of the current session.
- Use Platform admin > Organizations when the task is organisation-level setup or review. The page is available to platform administrators.
- Use Participants > Users when the task is a person, invitation, identity, KYC, holdings, activity, or account-security review. User detail pages show the evidence and follow-up actions available for that participant.
- Use Account > API keys when an integration needs account-scoped API credentials. Treat API keys as credentials for the current organization context, not as a replacement for user, provider, or webhook permissions. Before you wire a background job or external service, confirm the key, organization, and system scope in organization and system scope.
- Use Organisation settings > Compliance & verification > Compliance providers when onboarding flows depend on a KYC, KYB, AML, or wallet-monitoring provider. Provider pages hold vendor credentials, webhook authentication settings, and provider monitoring views.
- Use Organisation settings > Webhooks when an external system needs outbound event delivery. Webhook-management permission grants access to the webhook list and management entry point. Endpoint overview, deliveries, and settings pages require administrator or system-manager access because they expose operational delivery data.
- Use Account > Security when the task is account protection. The available cards depend on deployment configuration and the signing methods already enabled for the user.
- Use Organisation settings > Operations > Operator wallets when operations need to inspect operator-wallet balances. Low native balances can affect operational workflows that rely on those wallets.
What stays outside this page
This page is an overview and routing map. Use it to choose the right administration surface, then follow the task guide for the change you need to make.
It does not replace task guides for inviting users, creating users, registering identities, configuring providers, configuring webhooks, managing API keys, or reviewing account security.
Use the related pages for task steps and deeper reference material.
Related pages
Global search
Use the DALP Console global search palette to find assets, users, contacts, and system contracts, then open a record or copy its address.
Invite users
Send invitations for team members and external partners to join your platform from the Users page, and understand what the recipient completes after accepting.