Admin operating model
Configure DALP administration across organizations, users, system roles, API keys, webhooks, providers, and operator wallets.
DALP administration has two control planes. The organisation controls users, API keys, webhook endpoints, and provider records. The default system and asset roles control sensitive blockchain actions such as minting, pausing, compliance administration, gas management, and asset administration.
Configure the organisation first, then connect automation only after access, roles, provider records, webhook endpoints, and operator wallets are tied to the correct organisation and system.
Keep each operator, API key, provider integration, and webhook endpoint scoped to the right organisation. For operator wallets, check the chain, system, address, and native gas balance before workflows depend on them.
A new or reviewed DALP environment follows this operating order:
- Confirm the active organisation and its administrators.
- Grant only the organisation permissions and system roles needed for each responsibility.
- Create separate API keys, webhook endpoints, and provider records for the workloads that use them.
- Check operator wallets before asset workflows depend on platform-managed transactions.
Administration map
| Admin area | What it governs | Where to configure it | First check |
|---|---|---|---|
| Organisation profile | The active organisation context, name, and branding visible to operators. | Organisation settings > Organisation profile | Confirm the active organisation before changing settings. |
| Users and invitations | People who can sign in and act inside the organisation. | User management and invitation flows | Invite only the people who need console access. |
| Roles and permissions | Which users can list, grant, or change platform roles and system permissions. | Organisation settings > Admins & roles | Match each role to a named operating responsibility. |
| API keys | Machine-to-machine credentials scoped to the organisation active when the key is created. | Account, API keys | Create one key per organisation and workload. |
| Webhook endpoints | Outbound event delivery, signing state, endpoint health, and delivery history. | Organisation settings > Webhooks | Check signing state and failed delivery visibility. |
| Providers and platform services | Compliance providers, trusted issuers, verification topics, exchange rates, pricing, asset classes, and templates. | Organisation settings > Compliance & verification and Operations | Configure dependencies before asset workflows use them. |
| Operator wallets | Deployment-level wallet balances used by the platform for supported administrative workflows. | Admin, Operator wallets | Confirm chain, system, address, and native balance. |
Configure the admin model
Start with organisation and access controls before connecting automation. The organisation context determines which off-chain records and API-key scopes a user can reach. A key created while the wrong organisation is active can point automation at the wrong records, even when the user belongs to multiple organizations.
- Create the first administrator and organization. See first admin setup. For API-led onboarding, see organization deployment API.
- Invite administrators and operators who need console access. See add admins.
- Grant or change platform roles only after the user has the wallet and identity state required by the target role. See change admin roles.
- Create separate API keys for integration workloads that need REST API access. See API integration getting started.
- Configure webhook endpoints for systems that consume DALP events. See webhook endpoints.
- Configure provider and platform settings that your asset programs depend on, such as compliance providers, trusted issuers and verification topics, exchange rates, pricing, and templates.
- Check operator-wallet balances before workflows depend on platform-managed transactions. See operator wallets.
Access model
DALP uses two access layers that meet in administration pages: off-chain organisation permissions and on-chain system roles.
Off-chain organisation permissions control organisation-level administration. They cover organisation management, membership, API keys, and webhook endpoint management.
Organisation owners and admins can manage webhook endpoints. Ordinary members cannot.
On-chain system roles control asset and system operations that require blockchain authority. The platform settings permissions page reads the default system and shows which users can list or grant system roles. Operator wallet visibility also depends on system-level administrative roles such as admin, system manager, or gas manager.
Keep those two layers separate when you review access. A browser user may be allowed to manage organisation settings without having every on-chain system role, and a system role does not replace organisation membership for off-chain admin tasks.
| Review question | Check this surface first | Why it matters |
|---|---|---|
| Who can sign in and manage organisation records? | Organisation users and roles | Organisation roles govern membership, settings, API keys, and webhook access. |
| Who can grant or use blockchain authority? | System roles and permissions | System roles govern asset, compliance, gas, and administrative operations. |
| Which workload is calling the REST API? | API keys in the active organisation | API keys inherit the creating user's permissions and organisation context. |
| Which systems receive DALP events? | Webhook endpoints and deliveries | Webhooks expose event delivery, signing state, endpoint health, and history. |
| Which workflows depend on external checks? | Providers and verification topics | Provider configuration decides which verification path asset workflows use. |
| Which platform wallets need gas? | Operator wallets | Operator wallets show whether supported administrative workflows can pay gas. |
API keys and automation
API keys inherit the permissions of the creating user and are scoped to the organisation active at creation time. Create a separate key for each organisation and integration workload. Do not reuse one organisation key for another organisation.
API keys authenticate REST API requests. They are not accepted on RPC-only routes. For route, header, and organization scoping rules, see API integration getting started and organization and system scope.
Webhooks and provider operations
Webhook endpoints connect DALP events to external systems. Administrators can create endpoints and inspect signing state. The Webhooks area shows delivery history and endpoint settings.
Provider configuration sits next to webhooks because provider events often feed compliance and verification workflows. Configure compliance providers, trusted issuers, and verification topics before relying on automated checks in an asset workflow. See compliance provider paths when you need to choose between manual claim issuance and provider-driven ClaimSource issuance.
Operating checks
Review these checks before moving a platform from setup into production operations.
| Check | Why it matters |
|---|---|
| Active organisation | Confirms administrators, API keys, users, and provider records operate in the intended organisation. |
| Administrator list | Confirms only the expected users can manage organisation and system controls. |
| Role assignments | Confirms on-chain system authority matches the operating model for minting, pausing, compliance, gas, and asset administration. |
| API key inventory | Confirms machine credentials are scoped, rotated, and separated by workload. |
| Webhook endpoint health | Confirms downstream systems receive signed events and failed deliveries are visible. |
| Provider status | Confirms compliance provider integrations and verification topics are ready before asset workflows depend on them. |
| Operator wallet balance | Confirms operational wallets have enough funds for workflows that require gas or platform-managed transactions. |
Related pages
Organisation deployment API
Start organisation deployment, read the deployment tree, track account-abstraction setup, and separate organisation deployment from system creation for API-based platform setup.
First administrator setup
Create the first administrator, organisation, wallet security, identity, system, currency, and token factories by API.