# Security overview
Source: https://docs.settlemint.com/docs/architecture/security
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 security separates the controls that protect digital asset operations. A browser session or API credential can start a request, but the platform still checks permissions, wallet confirmation when required, on-chain compliance rules, and signer or custody policy before a transaction is submitted to an EVM network.
This overview is for product, operator, integration, and security reviewers who need the control map before reading the detailed pages. It explains which layer controls each decision, who operates that layer, what changes when the decision passes, and which topics sit outside this section.
## System context [#system-context]
## Security model [#security-model]
Each layer owns a separate control decision. Keeping those decisions separate avoids treating login, a role assignment, a wallet challenge, a compliance claim, or a custody approval as a complete security decision on its own.
The diagram shows the normal path. A request can stop at any layer: the caller can fail authentication, lack the right role, miss wallet verification, fail a compliance rule, or fail signer or custody policy before any asset state changes on chain.
| 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 | Asset Console and Unified 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 | Unified API middleware | The request can continue for the specific organisation, resource, action | Customer role design, approval policy, and segregation-of-duties model |
| Operator confirmation | Wallet verification through PIN, TOTP, or backup codes | Unified API before browser-session blockchain writes | A browser-session write has fresh operator confirmation | Recovery of lost factors 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 Guardian 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 authorised request can still require wallet verification. A verified request can still fail on-chain compliance or custody-provider policy.
## Request path [#request-path]
Security checks run across the same path used by the Asset Console and the Unified API:
1. The caller signs in or presents an API credential.
2. The API checks the caller's permission for the organisation, resource, and operation.
3. Browser-session blockchain writes enter the execution boundary with a wallet-verification payload for the Unified API to validate. API-key write requests follow the API-key authorization path and omit that payload.
4. 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.
5. 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.
6. 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 trust boundaries [#tokenization-trust-boundaries]
For tokenized assets, DALP separates platform controls from EVM contract enforcement. Platform controls decide who can request an operation and whether the request has the required operator confirmation and signing approval. Contract controls decide whether the submitted transaction can change token state on chain.
| Boundary | Enforced by | Examples | If the platform layer is unavailable |
| ------------------------------------ | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sensitive user and organisation data | Asset Console, Unified 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 | Unified 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 action | Unified 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 boundary 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 token state.
## Smart contract vulnerability controls [#smart-contract-vulnerability-controls]
DALP uses contract-level controls for arithmetic overflow and privileged access, plus path-specific controls for reentrancy. The answer is yes for Solidity 0.8.x arithmetic checks, role-gated privileged operations, and external-call entrypoints that use OpenZeppelin ReentrancyGuard. Treasury-funded redemption and yield payout paths rely on accounting updates before the ERC20 payout, so reviewers should verify each deployed external-call path against its guard coverage, checks-effects-interactions ordering, audit pack, source verification, role assignments, and scanner outputs.
This section uses a table rather than a diagram so each control can be matched to its 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. Platform authentication, API authorization, wallet verification, and signer policy can stop a request before submission, but a submitted transaction still needs the required contract role and token-state conditions to mutate assets on chain.
For evaluator responses, use this page for the control model and pair it with [source verification and deployment auditability](/docs/architecture/security/source-verification-auditability) for address, bytecode, audit, remediation, retest, and deployed-scope evidence.
## Reader paths [#reader-paths]
| Reader path | Start with | Continue with |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Product and buyer | [Identity and compliance](/docs/architecture/security/identity-compliance) for the asset eligibility model | [Claims and identity](/docs/architecture/concepts/claims-and-identity) and [compliance and custody split](/docs/architecture/security/compliance-custody-boundary) for the control boundaries |
| Operator | [Authentication](/docs/architecture/security/authentication) for sign-in, sessions, SSO, passkeys, and API keys | [Authorization](/docs/architecture/security/authorization) and [Wallet verification](/docs/architecture/security/wallet-verification) for roles and confirmation checks |
| Security reviewer | [Public chain privacy](/docs/architecture/security/public-chain-privacy) for public EVM visibility and off-chain data | [Signing flow](/docs/architecture/flows/signing-flow), [source verification and deployment auditability](/docs/architecture/security/source-verification-auditability), and [Custody providers](/docs/architecture/integrations/custody-providers) for transaction and deployment evidence |
| Procurement reviewer | [Vendor governance responsibility model](/docs/architecture/security/vendor-governance) for DORA, outsourcing, and third-party risk responsibility splits | [Deployment topology](/docs/architecture/overview/deployment-topology), [High availability](/docs/architecture/self-hosting/high-availability), and [Operational integration patterns](/docs/developer-guides/api-integration/operational-integration-patterns) for deployment, recovery, and provider evidence |
| Integration reviewer | [From external mint instruction to on-chain transaction](/docs/architecture/security/replay-idempotency-mint-controls) | [Stablecoin trust boundaries](/docs/architecture/security/stablecoin-architecture-trust-boundaries), [Compliance modules](/docs/architecture/security/compliance), and [Bridge and cross-chain security](/docs/architecture/security/bridge-cross-chain) for asset-rule and EVM-only boundaries |
## Trust boundaries [#trust-boundaries]
Three trust boundaries define where responsibility changes between callers, DALP services, and blockchain execution:
1. Platform boundary: external users and systems enter DALP through the Asset Console or Unified API. Authentication, API credentials, and rate limits apply here. Customers own their identity-provider configuration, staff lifecycle, endpoint security, and API-key handling.
2. Execution boundary: validated API requests move into backend services. Authorization, request validation, durable execution, browser-session wallet verification, and signer routing apply here. Customers own the business approval model that decides which people should receive each role.
3. Chain boundary: prepared transactions reach the EVM network. SMART Protocol compliance rules and custody-provider policy decide whether the transaction can change on-chain state. Custody providers and network operators own their external approval policy, availability, and final network inclusion.
The boundary view explains which control stops a bad request. The page map points to the detailed behaviour of each control.
## See also [#see-also]
* [Stablecoin trust boundaries](/docs/architecture/security/stablecoin-architecture-trust-boundaries) for stablecoin mint, burn, reserve, governance, and operating boundaries.
* [Signing flow](/docs/architecture/flows/signing-flow) for the complete transaction security sequence.
* [Source verification and deployment auditability](/docs/architecture/security/source-verification-auditability) for contract address, bytecode, migration, and indexed-event evidence.
* [Vendor governance responsibility model](/docs/architecture/security/vendor-governance) for DORA, outsourcing, and third-party risk responsibility splits.
* [Replay protection and mint controls](/docs/architecture/security/replay-idempotency-mint-controls) for mint retry, idempotency, and supply controls.
* [Key Guardian](/docs/architecture/components/infrastructure/key-guardian) for cryptographic key protection and signer routing.
* [SMART Protocol integration](/docs/architecture/components/asset-contracts/smart-protocol-integration) for on-chain security enforcement.
* [Authorization](/docs/architecture/security/authorization) for role-based and resource-level access control.