Platform setup overview
Understand the platform setup model, ownership responsibilities, administrator roles, and next setup guide to read.
Platform setup prepares an organization before asset teams start token operations. First administrators, permission managers, system managers, and reviewers use it to separate platform-level controls from token-level controls.
Organization access, platform administrator roles, Platform Settings, component availability, compliance provider controls, operator wallets, and account abstraction infrastructure belong in platform setup. Asset terms, investor onboarding, custody policy, and token lifecycle operations belong in later asset guides.
Setup model
Platform setup separates access into three layers. Organization roles decide what a signed-in user or API key can do in the active organization. Platform administrator roles decide who can change system, identity, compliance, component, and infrastructure controls. Asset roles decide who can operate a specific token after that token exists.
The diagram shows the split that matters most during setup: Platform Settings prepares the organization and platform capabilities. Asset creation uses those capabilities later and assigns token-specific roles per asset.
Admin operating sequence
Start with the organization and administrator responsibility model, then open the task guide for the control you need to change.
- Create or select the organization, then complete first administrator setup.
- Add the platform administrators who manage system, identity, verification, compliance, add-on, and gas duties.
- Keep organization roles, platform administrator roles, and asset roles separate. Organization roles affect application and API-key defaults. Platform administrator roles affect platform setup. Asset roles affect one token.
- Configure Platform Settings for the active organization: components, templates, verification settings, compliance providers, branding, access, developer operations, and infrastructure.
- Create API keys only from an account whose organization and permissions match the integration job. API keys inherit the issuing user's permissions and stay scoped to the active organization.
- Register webhook endpoints for downstream systems that need DALP event delivery, then monitor delivery history and endpoint settings from Platform Settings.
- Review account security, operator wallets, and account abstraction controls before asset teams rely on the setup for production workflows.
Choose the next setup guide
| If you need to... | Read next | Owner |
|---|---|---|
| Create the organization, first administrator wallet, system infrastructure, and first supported asset types | First administrator setup | The first administrator |
| Grant another wallet platform-wide administrative duties | Add administrators | A Permission manager |
| Prepare users, roles, test data, and readiness checks for an evaluation environment | Prepare users for an evaluation environment | Platform administrators, Identity managers, and Verification issuers |
| Expand, reduce, or remove an existing administrator's roles | Change admin roles | A Permission manager |
| Review or manage bundler and paymaster infrastructure | Account Abstraction Control Center | Admin, System manager, Gas manager, or Auditor, depending on the action |
| Check configured operator wallet gas balances | Operator Wallets | Admin, System manager, or Gas manager |
| Monitor user lifecycle events after setup changes | Webhook events | Identity managers and organization administrators |
| Create an API key for an integration | API integration getting started | The user or service owner that holds the required organization role |
| Register or monitor webhook endpoints | Events catalogue | Integration owners and platform administrators |
| Add, review, or revoke compliance provider records and their trusted claim topics | Onboard a compliance provider | Compliance managers, System managers, and Admins |
| Define trusted verification sources for compliance checks | Configure trusted issuers | Verification policy and compliance operators |
| Understand the full user, identity, role, API-key, webhook, and operator-wallet model | Admin operating model | Platform administrators and security reviewers |
| Understand auditor access, system roles, and token-level roles | Authorization | Security reviewers, permission managers, and auditors |
Setup responsibilities
| In this section | Out of scope |
|---|---|
| First organization setup, administrator grants, administrator role changes, Platform Settings, Account Abstraction controls, and operator wallet monitoring | Asset terms, token issuance, investor eligibility evidence, transfer restrictions, custody design, and lifecycle operations |
| Organization and platform permissions | Token-specific roles such as Asset Operator, Custodian, Supply Management, and Emergency |
| Component availability, templates, verification settings, compliance provider records, branding, exchange-rate operations, webhooks, and infrastructure controls | Off-chain approval policy, provider SLAs, legal sign-off, and operating runbooks outside the DALP UI |
Platform setup does not create asset authority
Platform administrator roles let operators prepare and maintain the platform. Asset-specific authority starts during asset creation and stays scoped to the token that receives the role grant.
Permission model
DALP separates application access from platform administration and token-specific authority. Use the narrowest role that fits the operator's duty. Split critical functions across different operators when your control framework requires it.
| Permission layer | Where it applies | What it controls |
|---|---|---|
| Organization roles | Authenticated application sessions and API-key defaults | Whether a user can administer the organization, manage settings, operate system functions, manage webhooks, or read data only |
| Platform administrator roles | Platform-wide administration | System setup, identity administration, compliance configuration, add-on management, and platform-level permission management |
| Asset roles | Individual tokens | Token-specific operations such as asset administration, custody actions, supply management, and emergency controls |
For the full model, including the auditor role, system roles, and per-asset roles, see Authorization.
Role changes apply immediately after the permission update is confirmed. Users may need to refresh their session before newly available functions appear in the interface.
Organization roles
Organization roles set the default application and API-key permissions for signed-in users in the active organization. When a user creates an API key, the key starts with the issuing user's admin permissions. If the issuing user is not an admin, the key starts with the user's owner or member permissions in the active organization. Platform administrator roles and token-level asset roles remain separate controls.
| Organization role | Use for | Permission scope |
|---|---|---|
| Admin | Organization administrators who manage settings, system operations, exchange-rate operations, and compliance recall workflows | Full organization, settings, system, exchange-rate, and webhook permissions |
| Owner | Organization operators who manage organization settings and permitted operational workflows without global theme control or exchange-rate maintenance | Settings read, list, upsert, and remove; system read, list, and create; exchange-rate read and list; webhook management and compliance recall |
| Member | Read-only users, reviewers, and team members who need visibility but should not change configuration or recall compliance webhooks | Settings read and list; system read and list; exchange-rate read and list; no webhook permissions |
Platform settings surface
Use Asset Console > Platform Settings for controls that apply to the active organization or system component inventory. These controls prepare the operating surface. They do not replace asset roles or create token state.
| Area | Use it for | Scope |
|---|---|---|
| Components | Review system components, deploy instrument types, manage add-ons, and review asset classes | Component deployment depends on the registered system directory and the operator's system permissions |
| Templates | Review instrument templates and policy templates before using them in asset or compliance workflows | Templates define reusable setup patterns; they are not live token state |
| Verification | Maintain verification topics and trusted issuers used by compliance checks | Verification settings define trusted claim sources; individual claims still come from issuers |
| Compliance providers | Add providers, attach supported claim topics, manage webhook authentication, and revoke provider trust | Provider records control intake from supported KYC, KYB, AML, and wallet-monitoring systems |
| Branding | Maintain organization details and theme settings | Branding changes affect the application experience, not token permissions |
| Access | Review and change organization permissions | Organization roles control application and API-key defaults; asset roles remain token-specific |
| Developer operations | Review exchange rates, pricing inputs, and webhooks | These controls support integrations and operating data; they do not create assets by themselves |
| Infrastructure | Configure account abstraction where the system supports it | Smart-wallet controls depend on the required add-ons and system manager permissions |
Component management filters
Platform Settings separates deployable components into instruments and add-ons. Each page includes search, filters, and status grouping so operators can find the right component before taking action.
- Instruments - Search and filter fixed income, flexible income, cash equivalent, and real-world asset instruments. The page groups instrument types by enabled, registered, and unregistered status. Enabled means the type is already deployed for the system. Registered means the type is available in the directory but not deployed yet. Unregistered means the type is not available for this system.
- Add-ons - Search and filter system add-ons, token features, and feeds, then narrow by functional category such as distribution, income and fees, exchange, data, and infrastructure. The page groups visible add-ons by enabled, registered, and unregistered status.
Available platform roles
| Role | Use for | Scope |
|---|---|---|
| Permission manager | Granting and changing administrator roles | Permission changes affect platform duties, not asset roles |
| System manager | System configuration and component deployment | System changes depend on the active organization and system directory |
| Asset manager | Starting asset creation workflows | Token authority is assigned on the asset after creation |
| Identity manager | Inviting users and managing identities | Identity administration does not grant custody or supply roles |
| Verification issuer | Issuing verification records | Issued claims are separate from trusted-issuer policy |
| Verification policy manager | Maintaining trusted issuers and verification topics | Policy changes define accepted claim sources |
| Compliance manager | Configuring global compliance controls | Compliance settings do not replace provider SLAs or legal approval |
| Addon manager | Installing and configuring platform add-ons | Add-ons become available through the platform component inventory |
Setup guides
Platform initialization
- First administrator setup - Create the first administrator and initialize platform infrastructure.
Administrator management
- Add administrators - Grant platform roles to team members.
- Prepare users for an evaluation environment - Prepare users, roles, test data, and readiness checks for a controlled demo, sandbox, or production rehearsal.
- Change admin roles - Modify existing role assignments.