Admin operating model
Configure DALP administration across organizations, users, system roles, API keys, webhooks, providers, and operator wallets.
DALP administration starts with the organization that owns the platform workspace. That organization sets the user context for console access, API keys, webhook endpoints, provider records, and other off-chain operating records. Platform administrators then grant the on-chain roles that authorize sensitive system and asset tasks.
Treat this page as the operating map before you follow the setup tasks. It separates user access, blockchain authority, machine credentials, event delivery, provider setup, and operator-wallet funding.
Plan this split before you connect automation or invite a broader operations team. Every human operator, API key, provider integration, and webhook endpoint should belong to the right organization.
Operator wallets are deployment-level resources. Review each wallet against the chain, system, address, and gas balance it supports. Each operating surface should have only the authority it needs.
Administration map
| Admin area | What it governs | Where to configure it | First check |
|---|---|---|---|
| Organization profile | The active organization context, name, and branding visible to operators. | Platform settings, Organization | Confirm the active organization before changing settings. |
| Users and invitations | People who can sign in and act inside the organization. | 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. | Platform settings, Permissions | Match each role to a named operating responsibility. |
| API keys | Machine-to-machine credentials scoped to the organization active when the key is created. | Account, API keys | Create one key per organization and workload. |
| Webhook endpoints | Outbound event delivery, signing state, endpoint health, and delivery history. | Platform 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. | Platform settings | 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 organization and access controls before connecting automation. The organization context determines which off-chain records and API-key scopes a user can reach. A key created while the wrong organization 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.
- 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 organization permissions and on-chain system roles.
Off-chain organization permissions control organization-level administration. They cover organization management, membership, API keys, and webhook endpoint management.
Organization 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 organization settings without having every on-chain system role, and a system role does not replace organization membership for off-chain admin tasks.
| Review question | Check this surface first | Why it matters |
|---|---|---|
| Who can sign in and manage organization records? | Organization users and roles | Organization 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 organization | API keys inherit the creating user's permissions and organization 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 organization active at creation time. Create a separate key for each organization and integration workload. Do not reuse one organization key for another organization.
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 organization | Confirms administrators, API keys, users, and provider records operate in the intended organization. |
| Administrator list | Confirms only the expected users can manage organization 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
Organization deployment API
Start organization deployment, read the deployment tree, and separate organization deployment from system creation for API-based platform setup.
First administrator setup
Create the first administrator, organization, wallet security, identity, system, currency, and token factories by API.