Administration operating model

Use this page to choose the right administration surface before you change users, credentials, providers, webhooks, security settings, or platform wallets.

DALP spreads administration across organisation membership, invitations, platform permissions, personal API access, outbound webhooks, provider setup, account security, and operator wallets. That split keeps your routine user tasks separate from integration credentials, provider configuration, account protection, and wallet funding.

Each surface answers a different question for you:

• 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

Role and permission model

Use roles to decide who can administer the platform, then use the surface map above to find where that work happens.

DALP combines three permission layers. Organisation roles decide the day-to-day administration available to you as a signed-in user. System roles govern platform operations such as identity, claims, compliance modules, data feeds, gas paymasters, and operator wallets. Token roles govern what an actor can do on a specific asset: minting, burning, pausing, freezing, role changes, metadata updates, fee changes, collateral updates, and compliance module changes.

The built-in organisation roles have these current boundaries:

• The admin role can list and create organizations, configure 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, exchange rates, and system data. It cannot configure 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 covers operational wallet funding and monitoring. The Data feeds list under Operations requires the feeds manager system role. A user without that role does not see the data feeds navigation item; opening the list directly returns a not-found page instead. Token workspaces use token roles for asset operations, so organisation ownership alone does not automatically grant permission to mint, freeze, pause, or change asset-level controls.

View-only access to an asset

A user can open an asset without holding any role that lets them act on it. When that happens, the asset detail stays fully readable and the platform makes the read-only state explicit instead of failing an action.

The asset detail shows a View only access banner at the top of every tab when the viewer has no enabled action on that asset. The banner explains that the user can review the asset's details, but actions and changes are disabled because they do not have management permissions for it. Write controls on the page stay disabled to match.

The banner reflects the viewer's enabled actions, not organisation membership. A participant who still has an open action on the asset, such as transferring tokens they hold, keeps that action and does not see the view-only banner. A user with no enabled action sees the banner across the whole asset detail.

Use this signal when a colleague reports that asset actions are greyed out: it confirms the asset is readable and that the missing capability is a token role. Grant the matching token role for the action they need, rather than an organisation or system role, to restore the action. See Asset role-based access control for the token roles that map to each asset action.

Operating flow for administrators

1. 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.
2. Use Platform admin > Organizations when the task is organisation-level setup or review. The page is available to platform administrators.
3. 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 next steps available for that participant.
4. Use Account > API keys when an integration needs account-scoped API credentials. API keys are scoped to the current organization context. They do not replace the user permission model, provider credentials, or webhook access. Before you wire a background job or external service, check the key scope and organization context in organization and system scope.
5. 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.
6. 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. The endpoint overview, delivery history, and settings pages require administrator or system-manager access because they expose operational delivery data.
7. 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.
8. 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.
9. Use Organisation settings > Operations > Data feeds when the task is creating, registering, or reviewing on-chain data feeds. Grant the feeds manager system role first, because the data feeds list stays hidden and is not directly reachable for any user who lacks the feeds manager role. See Feeds overview for the feed model and task guides.

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 the task guides for inviting users, creating users, registering identities, configuring providers, configuring webhooks, managing API keys, or reviewing account security. Follow the related pages below for task steps and deeper reference.

Related pages

• User lifecycle events
• Invite users
• Create users
• User onboarding
• Account security
• Organization and system scope
• Authentication
• Webhook events
• Compliance providers
• Feeds overview
• Onboarding a provider