Security and compliance posture

A DALP InstanceA DALP Instance is one self-contained copy of the platform, deployed inside a boundary you choose and connected to ledger networks you approve.Read the concept controls authentication, authorization, wallet verification, and signing. Its contracts enforce the asset's on-chain rules when a transaction executes. Review those controls together with the deployment configuration, role assignments, and custody policy. This page identifies the boundaries to verify and the information a public EVM network exposes.

Login is not enough to move assetsCopy Anchor Link

Signing in to the Console, or authenticating an API client, grants a session and nothing more. An asset operation also depends on authorization, any required wallet verification, signing policy, and on-chain compliance.

Authorization checks whether the caller may request the operation. Wallet verification challenges an eligible browser-session request. Prechecks can identify a likely compliance rejection before signing, but the contract makes the authoritative decision when the signed transaction executes. Custody policy controls whether the configured provider releases a signature.

For a self-custody account, the holder's own wallet signs, no platform request can release or withhold that signature, and the contract still enforces its rules at execution. Each layer reviews something different, each can refuse on its own, and passing one proves nothing about the next.

Record the three layers your deployment configuresCopy Anchor Link

Three of the five layers are configuration, not fixed platform behavior. Each choice changes what a reviewer may assume about a signed request, so each one belongs in the evidence pack: the deployment and verification record you assemble for the instance, covered under What supports a technical review.

Account two-factor enforcement is on or off per deployment, and off by default. When it is on, a signed-in operator without two-factor enrollment is routed to setup before reaching protected Console areas. When it is off, session sign-in alone reaches those areas, and authorization, wallet verification, on-chain compliance, and custody or signer policy each still stand between that session and a signed transaction.

One condition changes the picture: when sign-in runs through an external OpenID Connect (OIDC) provider, the identity provider owns the login challenge, and the platform does not push its own two-factor setup. Single sign-on covers that configuration and its lockout risks.

Wallet verification accepts a PIN, an authenticator code, a single-use recovery code, or an identity-provider code. Each account enrolls its own methods, and a request naming a method the account never enrolled is refused.

The deployment shapes the challenge in two ways. It sets the authenticator parameters: six digits on a 30-second rotation by default, hashed with SHA512. Confirm the authenticator app your operators use accepts SHA512 before rolling enrollment out.

The deployment also decides whether the identity-provider method exists at all, because that method delegates the check to an external OIDC provider configured with the wallet-verification fields described on the Single sign-on page.

Weigh friction against exposure when you decide what operators enroll. A PIN confirms fastest, but a shoulder-observed PIN keeps working until the operator changes it, so pair a PIN with an authenticator for any role that signs in from a shared or public space rather than enrolling the PIN alone. An authenticator code rotates every 30 seconds but needs the device on hand, and a recovery code is a one-time fallback for a lost device, never a routine signing method.

A request authenticated with an API key skips the wallet challenge entirely; the scoped key is the machine credential for that request. Authorization, the asset's compliance rules, and the signing policy still review that request on their own, so skipping wallet verification skips only that one layer. Scope every issued key to the narrowest set of operations it needs, and rotate or revoke it when the integration or its operator changes.

What goes wrong: repeated failed attempts lock wallet verification for the whole account, across all four methods, not just the method that failed. A wrong credential reports how many attempts remain, and once the account locks, the platform refuses further attempts, correct codes included, until the reported wait passes. The refusals are catalogued errors in the Platform API error reference, so an integration can distinguish an unenrolled method from a wrong code from a locked account. The catalogue also carries two retryable codes for wallet verification, one for capacity and one for a dependency that did not answer; back off and retry those rather than treating them as a credential failure. Treat a locked account as a signal to check for a compromised session or a confused operator, not as a bug to route around.

Custody and compliance are separate decisionsCopy Anchor Link

Compliance and custody signing answer different questions, and a reviewer traces both, never one. Compliance decides whether an address, claim, or transfer is allowed under the asset's configured rules. Custody decides whether the configured signing path releases a signature for an authorized request that can still fail contract checks at execution. That a transfer met the rules is not proof its signature was authorized, and a released signature is not proof the transfer met the rules.

An organization admin picks the custody provider during onboarding, and that choice locks once made: an organization's custody provider is fixed when its first wallet is created. A later request to switch providers is refused as a catalogued error, because switching would orphan the keys already issued under the locked provider. The deployment does not make that pick for the organization; it sets the platform's default provider and curates the signing policy layer around whichever provider the organization ends up on.

An instance signs through the platform key store or a configured custody provider. The organization selects its provider during onboarding; the deployment supplies the provider configuration and signing policy.

A provider can also run in a sign-only approval mode, where the provider's own policy engine approves each payload before the signature releases; that mode defaults on for Ripple, off for DFNS and Fireblocks, and is not available on Luna. Turn it on for a network DFNS does not support natively, or for a Fireblocks workspace configured to reject direct contract-call transactions; Ripple ships with it on because that is its primary signing path today. The deployment sets that mode through the provider's executionMode setting, not the organization admin. A signature in that mode waits on the provider's policy engine to answer, so an unreachable engine delays every signing request until it responds. Sign-only mode separates transaction preparation from provider signing. A four-eyes process also requires a provider approval policy with an independent reviewer; the execution mode alone does not require human approval.

Two on-chain roles carry most custody authority, and they answer different operating problems. A custodian role covers holder-specific exceptions such as freezing an address or part of a balance, forcing a transfer, or forcing a wallet recovery, each scoped to one holder and reversible only by another custodian move. An emergency role covers asset-level stops such as pausing or unpausing the whole asset, an early-maturity wind-down, or recovering ERC-20 tokens the asset contract holds by mistake, each affecting every holder at once. Neither role bypasses the earlier layers when exercised through the platform: a wallet holding one still clears authorization, wallet verification, and the signing policy before the step executes.

Whether one person may hold both compliance-configuration authority and custody-execution authority is your deployment's decision, not the platform's. The platform exposes separate roles and separate refusal points for each. If your operating model requires that the person who changes compliance policy never executes a custodian step, encode that split in role assignment and in the signing approval policy. Confirm it during review rather than assuming the platform enforces it.

A public EVM network makes activity discoverableCopy Anchor Link

Treat wallet addresses, calldata, event logs, registry links, claim relationships, settlement timing, and contract state as publicly discoverable on a public EVM network, unless your selected network or provider proves a stronger control. The instance limits what it writes on-chain to the state its contracts need to enforce rules; identity evidence, screening reports, and internal review notes stay in your off-chain systems.

Plan for what each part of the deployment exposes:

• Token contracts carry their addresses, operations, role changes, mints, transfers, burns, pauses, and configuration values in the open. Keep personal data and confidential terms out of names, symbols, metadata, and configuration values.
• The identity registry exposes wallet-to-identity relationships and which claim checks apply; treat identity addresses and wallet links as public-chain information.
• Claims and trusted issuers publish claim topics, issuers, signatures, claim lifecycle events, and which issuers are trusted for which topics. Use claim topics for eligibility state, and keep raw verification evidence off-chain.
• Compliance modules reveal their addresses, parameters, and pass-or-fail transfer outcomes through transaction behavior, so configure only the data enforcement needs.
• Transaction history stays on-chain as hashes, event logs, block timestamps, and the historical operation sequence; assume regulated activity can be correlated over time.

This list describes public EVM chain behavior generally, not a DALP-specific guarantee: any contract you deploy on a public EVM network is exposed the same way.

What supports a technical reviewCopy Anchor Link

Four kinds of evidence let you verify a deployed instance independently. A deployment record lists the contract addresses and parameters the operator expects. Reading bytecode at those addresses confirms what is actually deployed. Checking contract wiring and version after a migration confirms both are correct. Indexed events connect submitted transactions to accepted state changes. Assemble all of it into an evidence pack for the instance, alongside your own change-control and signing records. None of it substitutes for a formal smart contract audit or for your organization's own approval process; the pack supports those, it does not replace them.

For a SettleMint-hosted or managed deployment, add two more sources to that pack. The SettleMint Trust Center publishes the security questionnaires, compliance frameworks, and governance policies a compliance reviewer asks for; the SettleMint status page reports published platform availability and incident history.

Frequently asked questionsCopy Anchor Link