Security overview
DALP security separates identity, access, wallet verification, on-chain compliance, and custody controls so reviewers can see which gate owns each asset-operation decision.
DALP protects digital asset operations through layered controls. A browser session or API credential can start a request, but the platform still verifies permissions, wallet confirmation when required, on-chain compliance rules, and signer or custody policy before submitting a transaction to an EVM network.
Use this overview to map each control before you read the detailed pages.
One rule governs the platform's security model: login is not enough to move assets. To complete an asset operation, a request must pass the platform checks for the caller and the per-operation checks, plus the EVM contract checks for the current token state. Use this page to understand where the platform stops a bad request and where that responsibility shifts to the EVM contract.
System context
Security model
Each layer owns a separate control decision. Keeping those decisions separate prevents the system from treating any single gate, such as login, a role assignment, or a wallet challenge, as a complete approval on its own.
The diagram shows the normal path. A request can stop at any layer before any asset state changes on chain: the caller can fail authentication, lack the right role, miss wallet verification, fail a compliance rule, or be blocked by signer or custody policy.
| Control area | DALP check | Control owner | What changes when it passes | Out of scope for this section |
|---|---|---|---|---|
| Identity | Authentication through session, API key, SSO, or passkey-backed flow | Console and Platform API | DALP knows which organisation, user, or API credential made the request | The customer's identity-provider policy and staff lifecycle |
| Access | Role-based and resource-level authorization | Platform API middleware | The request can continue for the specific organisation, resource, and operation | Customer role design, approval policy, and segregation-of-duties model |
| Operator confirmation | Wallet verification through PIN, TOTP, or backup codes | Platform API before browser-session blockchain writes | A browser-session write has fresh operator confirmation | Lost-wallet recovery and customer endpoint protection |
| Asset-rule compliance | Identity claims and compliance modules | SMART Protocol contracts | A standard token operation satisfies configured holder and asset rules | Legal advice, off-platform KYC operations, and non-EVM enforcement |
| Signing approval | Custody-provider policy and MPC or signer backend | Key Management and custody providers | The prepared transaction can be signed by the configured signing path | Custody-provider SLA, quorum governance, and customer key ceremonies |
| Deployment evidence | Address records, bytecode checks, wiring checks, and indexed events | Contract deployment and indexing surfaces | Reviewers can compare deployed addresses, code, and indexed activity | Customer DR targets, external SIEM retention, and unrelated chain data |
The layers are independent. A request can be authenticated and still fail authorization. An authorized request can still require wallet verification. A verified request can still fail on-chain compliance or custody-provider policy. If an operator or holder loses access to a registered wallet, use the identity recovery workflow rather than editing the registered wallet binding directly.
Request path
The same checks run whether you use the Console or the Platform API:
- The caller signs in or presents an API credential.
- The API checks the caller's permission for the organisation, resource, and operation.
- Browser-session blockchain writes enter the execution path with a wallet-verification payload for the Platform API to validate. API-key write requests follow the API-key authorization path and omit that payload.
- After authorization and any required wallet verification pass, execution services prepare the transaction and run the SMART Protocol compliance pre-check for standard token operations.
- Transactions that pass the pre-check route signing through the configured signer or custody provider. The SMART Protocol enforces identity and compliance modules again when the transaction changes asset state on chain.
- Indexing and audit surfaces record the resulting transaction and state for later review.
This means the browser and API are entry points, not the whole security perimeter.
Tokenization control responsibilities
For tokenized assets, DALP separates platform controls from EVM contract enforcement. Platform controls decide who can request an operation and whether that request carries the required operator confirmation and signing approval. Contract controls decide whether the submitted transaction can change token state on chain.
| Control area | Enforced by | Examples | If the platform layer is unavailable |
|---|---|---|---|
| Sensitive user and organisation data | Console, Platform API, and customer identity systems | Sessions, API credentials, SSO, passkeys, roles, and resource checks | New console or API requests cannot be approved through DALP until the platform path is available again. Existing on-chain token state is not weakened by the platform outage. |
| Operator confirmation | Platform API before browser-session blockchain writes | Wallet PIN, TOTP, or backup-code verification | Browser-session writes that need fresh wallet verification cannot proceed through DALP until verification is available. |
| Privileged platform operation | Platform API and execution services | Token deployment requests, mint requests, burn requests, compliance configuration requests, and role-management requests | DALP does not create new platform-originated signed transactions while the required authorization, validation, or execution path is unavailable. |
| Signing approval | Configured signer or custody provider | MPC signing, custody-provider policy, and provider-side approval before transaction submission | Transactions that have not been signed cannot be submitted through that signing path until the signer or custody provider is available and approves the request. |
| Token state change | EVM contracts | Access-manager roles, identity registry checks, compliance modules, supply mint and burn roles, freeze functions, and pause controls | Contract rules continue to apply on chain. A transaction that reaches the chain still needs the required contract role, and standard token operations must satisfy the identity, compliance, freeze, and pause checks that apply to that operation. |
| Evidence and review | Chain indexer and audit views | Transaction hashes, deployed addresses, indexed events, and current role or compliance state | Chain state remains the source of truth. Review surfaces may lag until indexing catches up, so operators should compare against the configured EVM network for time-critical verification. |
The key control handoff is the last EVM state change. DALP services can stop a bad request before signing or submission. After submission, the contract decides whether the operation has the required role and token-state conditions to mutate asset state on chain.
Smart contract vulnerability controls
DALP uses Solidity 0.8.x arithmetic checks, role-gated privileged operations, and path-specific reentrancy controls. External-call entrypoints that own a payout or settlement call use OpenZeppelin ReentrancyGuard where that guard applies. Treasury-funded redemption and yield payout paths update accounting before the ERC20 payout. Reviewers should verify each deployed external-call path against its guard coverage, checks-effects-interactions ordering, audit pack, role assignments, and scanner outputs.
This section uses a table rather than a diagram so each control can be matched to deployment evidence without implying identical treatment across all payout paths.
| Vulnerability class | DALP control | What reviewers should verify in an evidence pack |
|---|---|---|
| Reentrancy | Token operations run through ordered checks and revert if a required identity, compliance, freeze, pause, or role condition fails. Guarded token payout and settlement entrypoints use OpenZeppelin ReentrancyGuard where the contract owns the external call. Treasury-funded redemption and yield payouts update accounting before the ERC20 payout. | Confirm which deployed functions make external calls, then verify ReentrancyGuard coverage or checks-effects-interactions evidence for each path. Include rejected-call review for unauthorized or invalid paths, plus audit findings, remediation notes, and retest evidence. |
| Integer overflow and underflow | DALP contracts use Solidity 0.8.x arithmetic, where overflow and underflow revert by default. Accepted unchecked arithmetic is limited to reviewed exceptions such as bounded loops or invariants that prove the subtraction cannot underflow. | Confirm the Solidity compiler version, review accepted unchecked-arithmetic exceptions, and match each invariant to the deployed contract scope. Include scanner output and audit evidence for any accepted exception. |
| Access control | Privileged token operations are role-gated. Examples include supply management for mint and burn, custodian authority for freezes and forced transfers, emergency authority for pause and recovery, and governance authority for identity, compliance, metadata, and feature configuration. | Confirm role assignments, signer or custody policy, negative tests or rejected-call review for missing roles, and CI/CD static-analysis evidence for missing-access-control findings before deployment, including Slither and MythX output when those scans are part of the evidence pack. Include audit findings, remediation notes, and retest evidence. |
The contract layer is the final enforcement point for token state. Authentication, authorization, and wallet verification can stop a request before submission. Signer policy can stop it during signing. A submitted transaction still needs the required contract role and token-state conditions to mutate assets on chain.
Use this page for the control model. Use source verification and deployment auditability for address, bytecode, audit, remediation, retest, and deployed-scope evidence.
Reader paths
| Reader path | Start with | Continue with |
|---|---|---|
| Product and buyer | Identity and compliance for the asset eligibility model | Claims and identity and compliance and custody split for control responsibilities |
| Operator | Authentication for sign-in, sessions, SSO, passkeys, and API keys | Authorization, Wallet verification, Recover user identity, and Identity recovery API for roles, confirmation checks, lost-wallet recovery, and API-led recovery status |
| Security reviewer | Public chain privacy for public EVM visibility and off-chain data | Signing flow, source verification and deployment auditability, and Custody providers for transaction and deployment evidence |
| Procurement reviewer | Vendor governance responsibility model for DORA, outsourcing, and third-party risk responsibility splits | Deployment topology, High availability, and Operational integration patterns for deployment, recovery, and provider evidence |
| Integration reviewer | From external mint instruction to on-chain transaction | Stablecoin control responsibilities, Compliance modules, and Bridge and cross-chain security for asset-rule responsibilities and EVM-only scope |
Responsibility model
Three control layers define where responsibility changes between callers, DALP services, and blockchain execution:
- Platform controls: external users and systems enter DALP through the Console or Platform API. Authentication, API credentials, and rate limits apply here. Customers own their identity-provider configuration, staff lifecycle, endpoint security, and API-key handling.
- Execution services: validated API requests move into backend services. Authorization, request validation, durable execution, browser-session wallet verification, and signer routing apply here. Customers own the approval model that decides who receives each role.
- Chain execution: prepared transactions reach the EVM network. SMART Protocol compliance rules and custody-provider policy decide whether a transaction can change on-chain state. Custody providers and network operators own their external approval policy, availability, and final transaction inclusion.
Use the page map to find the detailed behaviour of each control that applies to your integration.
See also
- Stablecoin control responsibilities for the stablecoin mint, burn, reserve, governance, and operating responsibility split.
- Signing flow for the complete transaction security sequence.
- Source verification and deployment auditability for contract address, bytecode, and indexed-event evidence.
- Vendor governance responsibility model for DORA, outsourcing, and third-party risk splits.
- Replay protection and mint controls for mint retry, idempotency, and supply controls.
- Key Management for cryptographic key protection and signer routing.
- SMART Protocol integration for on-chain enforcement details.
- Authorization for role-based and resource-level access control.
Audit evidence
How to answer vulnerability-control, formal-verification, and smart-contract audit evidence requests with DALP's deployed-scope evidence pack.
Authentication
DALP authenticates browser operators and API integrations before authorization and wallet verification decide what each request may do.