# Public chain privacy boundaries

Source: https://docs.settlemint.com/docs/architecture/security/public-chain-privacy
How DALP separates public EVM chain data from off-chain identity and compliance records.
Covers wallet visibility, identity claims, personal-data boundaries, and operator controls.




## Purpose [#purpose]

Use this page before designing an asset, identity, or compliance flow on a public EVM chain.

* **Doc type:** Explanation
* **What you'll find here:**
  * Which DALP records become public blockchain data
  * Which identity and KYC records stay off-chain
  * How wallet addresses, identities, claims, and compliance checks relate
  * What not to put on-chain
* **Related:**
  * [Identity & Compliance](/docs/architecture/security/identity-compliance)
  * [Compliance Modules](/docs/architecture/security/compliance)
  * [Wallet Verification](/docs/architecture/security/wallet-verification)
  * [API Reference](/docs/developer-guides/api-integration/api-reference)
  * [CLI Command Reference](/docs/developer-guides/cli/command-reference)
  * [Privacy Policy](/docs/legal/privacy-policy)
  * [Terms of Service](/docs/legal/terms-of-service)

***

## Public-chain baseline [#public-chain-baseline]

DALP operates on EVM networks. On public EVM chains, blockchain transactions and contract state can be read by anyone with access to that network. That includes token contract addresses, wallet addresses, transaction hashes, transfer events, and data written into smart contracts. Use the [API Reference](/docs/developer-guides/api-integration/api-reference) and [CLI Command Reference](/docs/developer-guides/cli/command-reference) to check the exact identity, claim, trusted-issuer, and token operations your flow uses.

Public-chain data has a different privacy profile from off-chain platform data:

| Data surface                             | Visibility boundary                                                       | Operator guidance                                                                           |
| ---------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Wallet addresses                         | Visible on the chain and linkable through transactions                    | Treat addresses as persistent public identifiers once used on a public network.             |
| Token and compliance contract state      | Visible according to the network and contract interfaces                  | Configure only the data required for issuance, transfers, and enforcement.                  |
| Transaction metadata                     | Visible through transaction hashes, logs, and event history               | Assume mint, transfer, burn, and administrative actions can be correlated on-chain.         |
| KYC/KYB documents and verification files | Processed off-chain through platform and verification workflows           | Keep personal documents and detailed evidence off-chain.                                    |
| Platform account data                    | Stored and processed by the platform according to the legal privacy terms | Manage retention and access through platform controls and your data-processing obligations. |

## Identity and compliance boundary [#identity-and-compliance-boundary]

DALP's identity and compliance model separates verification evidence from the on-chain enforcement records that tokens need for ERC-3643 style controls. The public [API Reference](/docs/developer-guides/api-integration/api-reference), [CLI Command Reference](/docs/developer-guides/cli/command-reference), and [Identity & Compliance](/docs/architecture/security/identity-compliance) pages show the user-facing identity, claim, trusted-issuer, and compliance operations behind this boundary.

* Identity documents and detailed KYC/KYB evidence are processed off-chain.
* Wallets are connected to on-chain identities so token contracts can evaluate eligibility.
* Identity records can be read by wallet address or by identity address, and can be checked with or without token context.
* Trusted issuers and claim topics define which authorities and claim types can support transfer eligibility.
* Claims can be issued to an identity, revoked from an identity, and reviewed through claim-history views.
* Compliance modules evaluate configured rules during token operations such as minting, transfers, and burns.

This means DALP can enforce eligibility on-chain without requiring operators to publish identity documents on-chain. It does not make public-chain activity private. Wallets, token operations, identity addresses, trusted-issuer relationships, claim topics, issued or revoked claim references, and claim event history remain visible according to the network and registry surfaces used in the flow.

## Current identity and claim surfaces [#current-identity-and-claim-surfaces]

Use these surfaces when reviewing what a public-chain identity flow exposes. Use the public API reference to verify request and response fields, and use the CLI command reference to find the matching commands and flags before launch:

| Surface                  | What operators configure or review                                                                                             | Privacy boundary                                                                                                            |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| Identity registry        | Creates, registers, reads, lists, searches, updates, and removes wallet-linked identity records.                               | Wallet and identity addresses are identifiers. Treat them as public once they are registered or used in public-chain flows. |
| Identity lookups         | Reads an identity by wallet address, identity address, or current user, with optional token-specific claim validation.         | Token-specific validation can reveal which token context is being checked against the identity.                             |
| Claim issuance           | Issues a signed claim to a target identity for topics such as KYC, AML, accreditation, investor type, or asset classification. | Claim topics and on-chain claim references support enforcement; detailed evidence should remain off-chain.                  |
| Claim revocation/history | Revokes an existing claim and exposes chronological claim history for audit and operations.                                    | Revocation and history help operate compliance, but they do not hide prior public-chain activity.                           |
| Claim topics             | Lists, creates, updates, reads, and deletes the topic schemes that describe supported identity claims.                         | Topic names and signatures should describe eligibility states, not personal documents or raw verification evidence.         |
| Trusted issuers          | Lists, reads, creates, updates, upserts, and deletes issuers and the topics each issuer is trusted to attest.                  | Issuer identities and topic assignments can link an issuer to eligibility decisions.                                        |

## What not to put on-chain [#what-not-to-put-on-chain]

Do not place personal data, identity documents, raw KYC evidence, confidential commercial terms, or sensitive investor files into blockchain fields, contract metadata, claim payloads, claim references, token metadata, transaction notes, or uploaded documents that are intended to be publicly referenced.

Use neutral identifiers and off-chain records where possible. For example, a compliance workflow can record that a wallet is eligible for a claim topic without publishing the underlying passport, proof of address, sanctions report, or beneficial-ownership file on-chain.

## Current controls and limits [#current-controls-and-limits]

DALP provides controls that help separate public enforcement from private evidence:

| Control                          | What it helps with                                                             | Limit                                                                                                |
| -------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------- |
| Off-chain verification workflows | Keeps supporting KYC/KYB evidence out of token contracts                       | Operators still control what they submit to on-chain fields and public metadata.                     |
| Trusted issuers and claim topics | Lets approved authorities support eligibility without publishing full evidence | The existence of an identity, wallet, claim topic, or claim reference can still be visible on-chain. |
| Compliance modules               | Enforces transfer, mint, and burn rules through contract checks                | Enforcement does not hide transaction history or wallet activity on public chains.                   |
| Platform access controls         | Limits who can view and manage off-chain operational records in DALP           | Access control cannot remove data already written to a public blockchain.                            |

The legal privacy pages state the key operational boundary: data written to a public blockchain can be immutable and publicly accessible, and SettleMint cannot delete or modify on-chain data. Operators are responsible for ensuring personal data is not recorded on-chain in violation of applicable law.

## Design checklist [#design-checklist]

Before launching on a public EVM network:

1. Identify every field that will be written on-chain or referenced from on-chain records.
2. Remove personal data and confidential files from token metadata, claim data, claim references, and transaction inputs.
3. Keep detailed verification evidence in approved off-chain systems.
4. Use claim topics and eligibility flags for enforcement instead of raw identity evidence.
5. Confirm that issuer, custodian, registry, and operator addresses can be publicly associated with their actions.
6. Review the [Privacy Policy](/docs/legal/privacy-policy) and [Terms of Service](/docs/legal/terms-of-service) for the legal treatment of blockchain data.