SettleMint
Platform setup

Platform setup overview

Understand the platform setup model, ownership responsibilities, administrator roles, and next setup guide to read.

Platform setup prepares an organisation 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.

Organisation access, platform administrator roles, Organisation 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. Organisation roles decide what a signed-in user or API key can do in the active organisation. 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.

Rendering diagram...

The diagram shows the split that matters most during setup: Organisation settings prepares the organisation and platform capabilities. Asset creation uses those capabilities later and assigns token-specific roles per asset.

Admin operating sequence

Start with the organisation and administrator responsibility model, then open the task guide for the control you need to change.

  1. Create or select the organisation, then complete first administrator setup.
  2. Add the platform administrators who manage system, identity, verification, compliance, add-on, and gas duties.
  3. Keep organisation roles, platform administrator roles, and asset roles separate. Organisation roles affect application and API-key defaults. Platform administrator roles affect platform setup. Asset roles affect one token.
  4. Configure Organisation settings for the active organization: products and assets, compliance and verification settings, operations, admins and roles, and webhooks.
  5. Create API keys only from an account whose organisation and permissions match the integration job. API keys inherit the issuing user's permissions and stay scoped to the active organisation.
  6. Register webhook endpoints for downstream systems that need DALP event delivery, then monitor delivery history and endpoint settings from Organisation settings.
  7. 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 nextOwner
Create the organisation, first administrator wallet, system infrastructure, and first supported asset typesFirst administrator setupThe first administrator
Grant another wallet platform-wide administrative dutiesAdd administratorsA Permission manager
Prepare users, roles, test data, and readiness checks for an evaluation environmentPrepare users for an evaluation environmentPlatform administrators, Identity managers, and Verification issuers
Expand, reduce, or remove an existing administrator's rolesChange admin rolesA Permission manager
Understand advanced accounts and decide whether to enable transaction funding and gasless transactionsAdvanced accountsAdmin or System manager
Review or manage the gas reserves, bundler, and paymaster infrastructureAdvanced accounts control centerAdmin, System manager, Gas manager, or Auditor, depending on the action
Fund or troubleshoot the submission and sponsorship gas reservesGas reserves operationsSystem manager
Check configured operator wallet gas balancesOperator WalletsAdmin, System manager, or Gas manager
Monitor user lifecycle events after setup changesWebhook eventsIdentity managers and organisation administrators
Create an API key for an integrationAPI integration getting startedThe user or service owner that holds the required organisation role
Register or monitor webhook endpointsEvents catalogueIntegration owners and platform administrators
Add, review, or revoke compliance provider records and their trusted claim topicsOnboard a compliance providerCompliance managers, System managers, and Admins
Define trusted verification sources for compliance checksConfigure trusted issuersVerification policy and compliance operators
Understand the full user, identity, role, API-key, webhook, and operator-wallet modelAdmin operating modelPlatform administrators and security reviewers
Understand auditor access, system roles, and token-level rolesAuthorizationSecurity reviewers, permission managers, and auditors

Setup responsibilities

In this sectionOut of scope
First organisation setup, administrator grants, administrator role changes, Organisation settings, advanced accounts controls, and operator wallet monitoringAsset terms, token issuance, investor eligibility evidence, transfer restrictions, custody design, and lifecycle operations
Organisation and platform permissionsToken-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 controlsOff-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 layerWhere it appliesWhat it controls
Organisation rolesAuthenticated application sessions and API-key defaultsWhether a user can administer the organisation, manage settings, operate system functions, manage webhooks, or read data only
Platform administrator rolesPlatform-wide administrationSystem setup, identity administration, compliance configuration, add-on management, and platform-level permission management
Asset rolesIndividual tokensToken-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.

Match users to interfaces

Start from the job the person needs to perform, then grant the narrowest organisation, platform, or asset role that lets them do that job. The same person may use more than one surface, but permissions stay scoped to the active organisation and, for asset operations, to the specific token. This keeps setup readable for the operator and defensible for a reviewer.

User or teamPrimary interfaceTypical access modelWhat they should do first
First administratorConsole and Organisation settingsOrganisation Admin plus the initial platform administrator duties needed to initialize the systemComplete First administrator setup.
Permission managerOrganisation settings > Admins & rolesPermission manager for platform role grants; organisation role only as needed for the same workspaceAdd or change administrators only for the duties each operator owns.
Identity or verification operatorOrganisation settings > Compliance & verificationIdentity manager, Verification issuer, or Verification policy managerConfigure trusted issuers before relying on claims in compliance checks.
Asset operations teamConsole, asset servicing guides, and API keysToken-scoped asset roles such as governance, custodian, supply management, funds, or emergencyConfirm the asset role on the token before minting, burning, servicing, or freezing.
Auditor or read-only reviewerConsole, exported evidence, and read APIsAuditor system role or Member organisation role for read accessReview the relevant system, asset, and event records without granting operating rights.
Integration owner or service agentAPI keys, SDK, CLI, and webhook configurationAPI key issued by a user with the minimum organisation permissions required by the integrationCreate the API key from the correct organisation and avoid write scope for read-only jobs.

Read-only is still scoped

A read-only reviewer or API key can inspect only the organisation and systems its session can access. Read-only access does not grant asset authority, custody policy control, or permission to change platform setup.

Organisation roles

Organisation roles set the default application and API-key permissions for signed-in users in the active organisation. 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 organisation. Platform administrator roles and token-level asset roles remain separate controls.

Organisation roleUse forPermission scope
AdminOrganisation administrators who manage settings, system operations, exchange-rate operations, and compliance recall workflowsFull organisation, settings, system, exchange-rate, and webhook permissions
OwnerOrganisation operators who manage organisation settings and permitted operational workflows without global theme control or exchange-rate maintenanceSettings read, list, upsert, and remove; system read, list, and create; exchange-rate read and list; webhook management and compliance recall
MemberRead-only users, reviewers, and team members who need visibility but should not change configuration or recall compliance webhooksSettings read and list; system read and list; exchange-rate read and list; no webhook permissions

Organisation settings surface

Use Console > Organisation settings for controls that apply to the active organisation or system component inventory. These controls prepare the operating surface. They do not replace asset roles or create token state.

SectionUse it forScope
OrganisationMaintain the organisation profile and theme settingsBranding changes affect the application experience, not token permissions
Products & assetsReview asset classes and instrument templates before using them in asset workflowsTemplates define reusable setup patterns; they are not live token state
Compliance & verificationManage policy templates, verification topics, trusted issuers, and compliance providersVerification settings define trusted claim sources and provider intake; individual claims still come from issuers
OperationsReview platform status, run system updates, manage advanced accounts and operator wallets, and configure data feedsOperational controls depend on system manager permissions and the registered system directory
Admins & rolesReview and change organisation permissionsOrganisation roles control application and API-key defaults; asset roles remain token-specific
WebhooksConfigure outbound event delivery and endpoint settingsThese controls support integrations and operating data; they do not create assets by themselves

Component management filters

System updates 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 such as distribution, settlement, and treasury capabilities, then narrow by functional category. The page groups visible add-ons by enabled, registered, and unregistered status.

Available platform roles

RoleUse forScope
Permission managerGranting and changing administrator rolesPermission changes affect platform duties, not asset roles
System managerSystem configuration and component deploymentSystem changes depend on the active organisation and system directory
Asset managerStarting asset creation workflowsToken authority is assigned on the asset after creation
Identity managerInviting users and managing identitiesIdentity administration does not grant custody or supply roles
Verification issuerIssuing verification recordsIssued claims are separate from trusted-issuer policy
Verification policy managerMaintaining trusted issuers and verification topicsPolicy changes define accepted claim sources
Compliance managerConfiguring global compliance controlsCompliance settings do not replace provider SLAs or legal approval
Addon managerInstalling and configuring platform add-onsAdd-ons become available through the platform component inventory

Setup guides

Platform initialization

Administrator management

Advanced accounts

On this page