Security and compliance posture

One complete provider entry under auth.oidcProviders replaces local Console sign-in for the whole deployment. The Investor portal keeps email and password for investors. Single sign-on covers the entry, the administrator claim, the lockout risk and its recovery.

Local passwords follow a server-side policy under auth.passwordPolicy. By default a password has at least 12 characters and three character classes, cannot repeat one of the last five, and never expires. By default, five wrong passwords within 15 minutes lock the account for 30 minutes. A session expires seven days after its last renewal, and the platform renews a session in use once a day, so an active session has no fixed end.

Two-factor authentication#

Login two-factor guards sign-in. Wallet verification confirms a signing request after sign-in. They are separate challenges, and enrolling one does not enrol the other.

Login two-factor#

auth.enforce2fa is off by default. When you turn it on, the API refuses every authenticated call from a browser session whose account has no login two-factor, with LOGIN_2FA_REQUIRED. On a deployment without an OIDC provider, the Console sends the user to two-factor setup. A request with an API key is not subject to this check. An account whose only sign-in is your OIDC identity provider is not subject to it either, because the identity provider owns the login challenge. An account that also has a password or a passkey still needs login two-factor. Before you roll SSO out, set an MFA policy at the identity provider.

Each organisation chooses which second factors its members may use at sign-in: an authenticator app, an email code or a text message code. A new organisation allows the authenticator app only. Sign-in codes covers the email and text message options. At the two-factor step a user can tick “Trust this device”. That device then skips the second factor until 30 days pass without a sign-in from it.

Wallet verification#

Wallet verification accepts a transaction PIN, a transaction code from an authenticator app, a single-use recovery code, or a code from a FusionAuth identity provider. Each account enrols its own methods, and the platform refuses a request that names a method the account never enrolled. The identity-provider method exists only when you configure the wallet verification fields of an OIDC provider entry, and the platform checks the code through FusionAuth's user and two-factor API, so other identity providers cannot act as a wallet factor.

Repeated failed attempts lock wallet verification for the whole account, across every method. A wrong code reports how many attempts remain. Once the account locks, the platform refuses further attempts, correct codes included, until the reported wait passes. The refusals are catalogued in the Platform API error reference, so an integration can tell an unenrolled method from a wrong code and from a locked account.

A request authenticated with an API key skips the wallet challenge, because the scoped key is the machine credential for that request. Authorisation, the asset's compliance rules and the signing policy still review it. Scope each key to the operations it needs, and revoke it when the integration or its owner changes.

Login is not enough to move assets#

A session or an API key authenticates the caller and authorises nothing on its own. An asset operation also has to pass authorisation, any required wallet verification, the signing policy of the key, and the asset's on-chain rules.

Authorisation checks whether the caller may request the operation. Wallet verification challenges an eligible browser-session request. Prechecks can predict a compliance rejection before signing, but the contract makes the authoritative decision when the signed transaction executes. Custody policy decides whether the provider releases a signature. A self-custody holder signs with their own wallet, so no platform request can release or withhold that signature, and the contract still enforces its rules. Each layer can refuse on its own.

These layers govern requests made through the platform. A contract checks role membership, not the platform session, so a key that holds an on-chain role can call the contract from any tooling on a public EVM network. Keep role-holding keys behind a signing path you trust, and record who controls them.

Segregation of duties and maker-checker#

The platform separates duties in three ways: role-pair rules on role grants, five built-in second-person checks and ten maker-checker approval families. The first two always apply, and the approval families apply once the organisation switches them on.

Role-pair rules act when a role is granted. The platform always refuses to give one address the Auditor system role together with any of the other 14 system roles the platform grants, whichever is granted second. Each organisation can also keep its own rules, which block or warn on a grant that gives one address two conflicting on-chain roles, such as Governance and the custodian role. Those rules apply once the organisation enables them, and a report lists every address that already holds a conflicting pair.

Five built-in controls refuse a decision by the person who proposed it: a trade bust, a desk trading limit, a wallet checker approval, a reporting sign-off with its acknowledgement, and a partial redemption or payout in new tokens. A bust of a delivered trade always waits for a second person. Other trade busts and desk limits wait for one only while the Trading venues approval family is on, and an organisation can switch the partial redemption control off. Maker-checker states when each control applies.

Maker-checker approvals cover ten families of change, which an owner or a platform administrator switches on in the organisation's Approvals settings. The Administration family sends privileged changes, such as role management, compliance configuration, freezes, pauses, forced transfers and recovery, to a second person for approval. Every family is off by default, so a new organisation asks nobody for a second approval until someone turns a family on.

Roles and segregation of duties lists every role, rule and enforced pair. Approvals describes the families and who decides each request.

Privileged access#

The platform administrator is the one role with authority across every organisation and user account on the instance. The organisation Owner and Member roles act inside one organisation, and on-chain roles act on contracts.

The platform administrator role is granted in three ways:

• The first account created locally on a new instance, before any other account exists, becomes one. Without an OIDC provider, anyone who can reach the Console or the Investor portal can create an account, so create the first administrator before you expose the instance. Keep at least one administrator at all times: once accounts exist, a new account is always a member, and the steps below restore the role when none is left.
• A platform administrator gives the role to a local account on that account's page under Platform admin › Platform users.
• With SSO, the identity provider decides at every sign-in. adminClaim is either a value that must appear in the user's roles or groups claim, or the name of a claim that must be true. A grant made in DALP is overwritten at the user's next sign-in, and with no adminClaim every SSO user signs in as a member. Whoever can set that claim at your identity provider controls who is a platform administrator.

A platform administrator can impersonate a member to investigate a problem. The impersonated session lasts one hour, cannot target another platform administrator, and records the administrator who started it in the audit trail. An impersonated session cannot approve or reject anything that waits for a second person, and cannot loosen the approval policy. The Platform API refuses such a decision with DALP-200386. An impersonated session also cannot approve a device sign-in, add a passkey or connect an MCP client, so the administrator cannot sign in later as the member without the impersonation mark. Maker-checker lists the decisions it covers.

The Helm value global.dalpApp.config.auth.allowImpersonatedDecisions lets an impersonated session decide. It exists for demo deployments only. It is false by default and in every shipped values file. Leave it false on any deployment that holds real assets or real people: with it on, one administrator can approve their own proposal by impersonating a second operator.

A platform administrator signed in as themselves can change the organisation's approval policy and decide held requests in the Administration family, the same as an owner. Review who holds the role as part of your privileged access review.

On chain, version 2 of the system access manager refuses a revoke or a renounce that would leave its Admin role with no holder. A system access manager upgraded from version 1 refuses Admin grants and revokes until its administrator count is initialised, and the guard does not cover a contract upgrade by an Admin or system manager. Version 2 of the token access manager protects the last Admin of each token created on it, and of a token created on version 1 once one of its administrators migrates it.

The platform has no break-glass account. If an SSO configuration locks every operator out, the recovery is a redeploy with an empty provider list, which Single sign-on describes. Keep deploy access to the cluster under your own privileged access controls, because it reaches every secret the platform holds.

Restore the platform administrator role#

Once accounts exist, no new account becomes a platform administrator. When the last one has lost the role, or no administrator can sign in, the migration Job restores the role to an existing account. With its default hook settings, the chart runs that Job on every install and upgrade, and its recover-platform-admin step acts only on an upgrade that names the account. The recovery needs deploy access to the cluster, not a Console session or an API key.

The recovery is for a deployment where the Console accepts password sign-in. Pick an account that has a password and is not banned. The step refuses an account with no password, such as one created through single sign-on or an invited account that has not finished signing up. With single sign-on configured, the Console refuses password sign-in, and the identity provider sets each account's role at every sign-in. Set the administrator claim at your identity provider instead, as Single sign-on describes.

1. Find the chart version the release runs: the CHART column of helm list --namespace dalp shows it as dalp-<version>. Upgrade the release with that version and your usual values file, and add the account's email address. Replace the release name and namespace dalp with your own.

   helm upgrade dalp oci://pkg.distribution.settlemint.com/settlemint/dalp \
     --version <current chart version> \
     --namespace dalp \
     --values my-values.yaml \
     --set [email protected]

   Upper and lower case in the address do not matter. Keep the chart version and values as they are, so the upgrade changes nothing else.

2. Wait for helm upgrade to succeed. The migration Job has then granted the role, or found that the account already held it and changed nothing.

   When the account does not qualify, the step fails the Job with the error dalp.migrator.PLATFORM_ADMIN_RECOVERY_REFUSED and the role does not change. The message says why: no account has the address, the account has no password sign-in, or the account is banned or closed. A retry with the same address fails the same way. With the default pre hook type, Helm stops before it changes any running pod and keeps the failed Job, so you can read the message with kubectl logs job/dalp-migrations --namespace dalp. Correct the address or pick another account, then run step 1 again.

3. Sign in to the Console with that account's password. The account holds the role from its next request.

4. Run the upgrade again without the --set line. While PLATFORM_ADMIN_RECOVERY_EMAIL stays set, every upgrade gives that account the role back if someone removes it. Once that account is banned or deleted, every upgrade fails at the migration Job until you remove the value.

Each grant writes one entry to the audit trail: the route auth.admin.setRole, the system actor platform-admin-recovery, the account as its target, and the role before and after. The entry belongs to no organisation, so a platform administrator reads it through the platform-wide query of the audit trail. When the account already held the role, the step records nothing.

Secrets and key handling#

Deployment secrets reach the pods in one of three ways, and you can mix them:

• Values you set in the chart's shared environment block, which the chart renders into a Kubernetes Secret. Helm stores every chart value in its release history, so pass production secrets through an existingSecret or Conjur instead.
• An existingSecret you create for the Blockscout and DApp PostgreSQL connections and the DApp Redis connection under global.datastores.
• Conjur, through global.conjur. A Conjur authenticator init container signs the pod in, and summon injects each mapped secret as an environment variable when the process starts.

The platform's own secrets, such as signing keys, custody provider credentials, and the Xero app secret and refresh token that connect an organisation's ledger, go to the secret manager selected by secretManager.provider: local, aws, gcp, azure or vault. With local, the platform encrypts each secret and stores it in its own database. With the other four, the secret lives in your AWS Secrets Manager, Google Secret Manager, Azure Key Vault or HashiCorp Vault, under its controls and audit. Values and secrets covers each option.

Four values are always yours to generate: the encryption master password, at least 16 characters and 128 bits of estimated entropy, the session signing secret, at least 32 characters, the custody credential identity key, and the governance ballot domain scope. A production pod refuses to start on the chart's placeholder session secret and on the development master password.

Signing keys sit in one of two places:

• The platform key store, the local signer. The platform generates the key and stores it through the selected secret manager. With the local secret manager, the key and the password that protects it are inside the same deployment, so this gives no independent custody control.
• A custody provider: DFNS, Fireblocks, Ripple Custody, Utila or a Thales Luna HSM. With Luna, the platform generates each secp256k1 key pair inside the HSM partition over PKCS#11, marked sensitive and non-extractable, and the HSM signs. The provider's own policy, such as an MPC policy or an HSM quorum, can hold a request before it signs.

Prerequisites lists the credentials each custody provider needs.

Encryption in transit#

TLS for browser and API traffic terminates at the edge you configure. The Console Ingress takes a tls list with your certificate Secret, a Gateway API httpRoute attaches to a Gateway you supply, and an OpenShift Route takes a tls block and can request its certificate from cert-manager. The chart sets no certificate and no cipher policy of its own, so TLS versions and ciphers are those of your ingress controller, Gateway or router. OpenShift describes the edge, passthrough and reencrypt options.

Inside the cluster, the services talk over plain HTTP on the Service network, so a service mesh or CNI encryption is your control where you need encryption there. A network policy, on by default, admits to the Platform API only the Console, the Investor portal and the Utila signing agent of the same release, plus any edge namespace you trust.

Datastore TLS is a value you set, and the chart default is off. With the default PgBouncer pooler, the application connects to PgBouncer in plaintext inside the cluster, and the datastore sslMode sets the TLS mode from PgBouncer to PostgreSQL. For a private CA, leave sslMode empty and give the CA through pgbouncer.upstreamTls. Without the pooler, sslMode applies to each direct connection, or use the typed database.tls with a CA file. Set tls for Redis. An object store with a self-signed certificate gets its CA through s3SslCertSecret. A custody provider is reached over its own HTTPS API, and a Luna HSM over its client, with mutual TLS when your HSM requires it.

Encryption at rest#

The platform encrypts these items with AES-256-GCM before it stores them:

• Secrets in the local secret manager, which include platform key store signing keys and custody provider credentials.
• KYC documents in object storage, and the values of KYC templates in the database.
• Credentials of RPC endpoints that an administrator adds at runtime, and the input of a participant import.

The key comes from the encryption master password through PBKDF2 with SHA-256 over 600,000 iterations. The platform refuses a master password shorter than 16 characters or weaker than 128 bits of estimated entropy. A master password rotates in one deploy through the migration Job, as Values and secrets describes.

Login authenticator secrets, login backup codes and the private ES256 keys that sign the platform's short-lived JSON Web Tokens are encrypted with XChaCha20-Poly1305 under a key derived from the session signing secret. Those signing keys rotate every 30 days. Sessions themselves are database records behind a cookie signed with HMAC-SHA256.

Login passwords are stored as scrypt hashes and wallet PINs as Argon2id hashes. Login codes sent by email or text message are stored hashed.

Everything else at rest belongs to the stores you operate: disk and volume encryption of PostgreSQL, Redis and object storage, their backups, and the encryption of the external secret manager. Record those controls with the store, because the chart neither sets nor checks them.

Logging and audit trail#

The audit trail records every state-changing request and selected reads, with the person, the role they held, their organisation, and the outcome. Audit trail lists what it covers.

Each organisation's rows form a SHA-256 hash chain. Database triggers refuse to update a row, except that a pending request's outcome is written as a new appended row. They refuse to truncate the table, and refuse to delete a row before its day is anchored. A role that owns the table can still remove the triggers, so the hash chain and its daily on-chain anchor are what reveal a change. A daily job anchors each closed day's chain head on the organisation's default network once it has a deployed system and an active anchor signer, and records each anchor in a table that only accepts new rows. Until then the job retries each day, and that day's rows cannot be deleted. Rows of platform-wide operations, recorded without an organisation, form one more chain. It has no anchor, so the triggers refuse every delete of its rows. The Helm value global.dalpApp.config.monitoring.auditRetentionYears takes 5, 7 or 10 years, or indefinite, which is the default.

You read the trail in the Console, export it as CSV in the Console or through GET /api/v2/reporting/trail/export, and check a date range for tampering through GET /api/v2/reporting/trail/integrity. A platform administrator checks the platform chain through GET /api/v2/reporting/trail/operator/integrity.

Each service exports traces, metrics and logs over OpenTelemetry (OTLP) to the collector endpoints you set under telemetry. Forward them from that collector to your SIEM. Observability lists the keys and defaults.

Two features send data to third parties. The Console assistant and the docs site's Ask AI send questions, with the context they gather, to OpenRouter when an assistant key is set. The exchange-rate refresh calls a public currency API unless you point it at your own source. Hosting and access names both.

Secure development and supply chain#

SettleMint builds every release image from source in an automated release build. Each DALP image is published with a provenance attestation in the SLSA format and a software bill of materials in the SPDX format, attached to its registry entry. Neither the records nor the images are signed, so a reviewer compares image digests and reads the records. The Platform API images run compiled binaries, so their bill of materials lists the image's OS packages but not the JavaScript dependencies inside the binary. PgBouncer and the two metrics exporters are third-party images and carry only what their publishers attach.

Source changes are scanned for committed secrets before they merge. Dependencies are pinned to exact versions and image digests, and most updates wait two days after their upstream release. Report a suspected vulnerability to [email protected]. SettleMint publishes no response time, fix time or advisory channel for a report.

Supply chain and support policy shows how to read the records, how a version maps to one build, which release lines take patches, and how a report becomes a fix.

Cryptographic agility#

No setting selects a post-quantum algorithm. The signing curve is the network's rule, so a post-quantum signature on chain depends on the network.

Custody and compliance are separate decisions#

Compliance decides whether an address, claim or transfer is allowed under the asset's rules. Custody decides whether the signing path releases a signature for an authorised request. Each check passes or fails on its own, so a reviewer traces both.

An organisation picks its custody provider during onboarding, and the choice locks when its first wallet is created. A later switch is refused, because it would orphan the keys already issued. The deployment sets the platform's default signer and which providers are switched on.

Two on-chain roles carry most custody authority. The custodian role covers exceptions for one holder, such as freezing an address or part of a balance, forcing a transfer, or recovering a wallet. The emergency role covers stops that affect every holder, such as pausing the asset. Through the platform, a wallet holding either role still clears authorisation, wallet verification and the signing policy.

Whether one person may hold both compliance configuration authority and custody execution authority is your decision. The platform gives you separate roles, role-pair rules and approval families to enforce the split, as Segregation of duties and maker-checker describes. Confirm the split during review.

A public EVM network makes activity discoverable#

On a public EVM network, treat wallet addresses, calldata, event logs, registry links, claim relationships, settlement timing and contract state as public. The contracts write only the state they need to enforce rules. Identity evidence, screening reports and internal review notes stay in your off-chain systems.

• Token contracts expose their addresses, operations, role changes, mints, transfers, burns, pauses and configuration values. Keep personal data and confidential terms out of names, symbols, metadata and configuration values.
• The identity registry exposes wallet-to-identity links and which claim checks apply.
• Claims and trusted issuers publish claim topics, issuers, signatures, claim lifecycle events, and which issuers are trusted for which topics. Keep raw verification evidence off chain.
• Compliance modules reveal their addresses, parameters and pass-or-fail outcomes through transaction behaviour.
• Transaction history stays on chain as hashes, event logs and block timestamps, so regulated activity can be correlated over time.

What supports a technical review#

Four kinds of evidence let you verify a deployed instance yourself. A deployment record lists the contract addresses and parameters you expect. Reading bytecode at those addresses confirms what is deployed. Checking contract wiring and versions after a migration confirms both are correct. Indexed events connect submitted transactions to accepted state changes. Put these into an evidence pack with your change-control and signing records and the deployment choices this page names. The pack feeds a formal smart contract audit and your own approval process.

For a SettleMint-hosted or managed deployment, add two SettleMint sources to the pack: the SettleMint Trust Centre, and the SettleMint status page, which reports platform availability and incident history. This page claims no certification. Exit and data portability covers where each kind of data lives and what you can export.

Frequently asked questions#