# Privacy architecture patterns Source: https://docs.settlemint.com/docs/compliance-security/privacy/architecture-patterns Compare public eligibility, private evidence, permissioned EVM networks, privacy layers, and metadata minimisation patterns for regulated DALP assets. DALP supports regulated asset controls on configured EVM networks. Privacy depends on the architecture built around those controls: what the asset writes on-chain, where evidence stays off-chain, which network carries the activity, and which providers operate the submission path. Use these patterns to classify your privacy requirements before committing to a public-chain answer. ## Pattern comparison [#pattern-comparison] | Pattern | Use when | DALP position | Boundary | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Public eligibility, private evidence | A token must prove transfers occur only between eligible holders, while the supporting files stay private. | DALP supports claims, trusted issuers, identity registries, and compliance modules that publish only enforcement state. | The public chain still reveals identity links, claim relationships, token activity, and timing that the selected contracts expose. | | Selective disclosure through claims | The chain needs to know an eligibility condition is satisfied, but not the evidence behind it. | DALP can use claim topics and issuer attestations for enforcement. | Claim topics, issuers, signatures, and registry links can still be visible. | | Minimal on-chain metadata | The asset has confidential commercial terms or private document references. | DALP supports token and document workflows, but public-chain fields must contain only approved public data. | The operator owns metadata review before submission. | | Public proof of a private process | The programme needs a public anchor for an off-chain review, reserve process, or operational event. | DALP can expose neutral references and chain events where the asset design requires them. | The underlying document, review note, file, and commercial detail stay off-chain. | | Private or permissioned EVM network | The asset requires restricted read, submit, validation, or inspection rights. | DALP can operate with configured EVM networks. | Network-level confidentiality comes from the selected network and its operators. | | Privacy framework or proof system | The requirement needs private smart-contract state, proofs, or shielded transfer semantics. | Treat as a deployment-specific integration. | Contracts, circuits, keys, monitoring, reconciliation, and legal approval sit outside the default DALP public-chain model. | | Public transaction controls | The asset can expose transaction activity, but needs controlled signing, tracking, and recovery. | DALP coordinates the configured transaction path and tracks state. | Private routing, ordering protection, and provider guarantees require explicit deployment choices. | | Wallet and address hygiene | The operating model separates issuer, verifier, custodian, administrator, participant, and operator roles. | DALP exposes role-governed control surfaces. | Address reuse can still link roles, assets, counterparties, and administrative operations. | ## Public eligibility, private evidence [#public-eligibility-private-evidence] Use this when your token must prove that transfers only occur between eligible holders, but the supporting documents should not be public. | Layer | Pattern | | ----------- | --------------------------------------------------------------------------------------------- | | Evidence | Store KYC, KYB, AML, accreditation, sanctions, and investor files off-chain. | | Attestation | Issue an OnchainID claim for a topic such as KYC, AML, accreditation, or investor type. | | Enforcement | Configure identity and compliance modules so transfers fail unless required claims are valid. | | Audit | Review off-chain evidence and on-chain claim or transaction history together. | ## Selective disclosure through claims [#selective-disclosure-through-claims] Use this when the chain must confirm that an eligibility condition is met, but your deployment must not expose the supporting evidence. | Disclosure need | Public-chain record | Keep off-chain | | ----------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------- | | Holder passed KYC | Claim topic and trusted issuer attestation | Passport, registry extract, screening report, reviewer notes | | Holder is accredited | Investor-category claim | Accreditation file, income evidence, source document | | Holder belongs to an allowed jurisdiction | Country or eligibility claim, if configured | Address proof, screening file, legal analysis | | Holder is blocked | Transfer rejection or status, depending on design | Sanctions match details, investigation notes, escalation record | ## Minimal on-chain metadata [#minimal-on-chain-metadata] Use this when your token programme has sensitive commercial terms, private counterparties, or document records. | Field | Safer public value | Avoid | | ------------ | -------------------------------------------------- | ------------------------------------------------------------------------ | | Token name | Approved product label | Client name, internal codename, private issuer account | | Symbol | Approved public ticker or neutral label | Account reference, private tranche label, confidential counterparty hint | | Token URI | Public factsheet or approved public metadata | Private data room link, signed document URL, personal data | | Claim URI | Neutral public reference only when required | Passport file, screening report, private document hash, review note | | Event fields | Values required for enforcement and reconciliation | Reviewer name, evidence ID, commercial term, private note | ## Private or permissioned EVM network [#private-or-permissioned-evm-network] Use this when public transaction and state visibility is not acceptable for your asset. | Decision | Owner | | ---------------------------------------------------------------------------------------------- | --------------------------------------------------- | | Validator set, RPC access, archive-node access, and participant onboarding | Network operator and institution | | Chain governance, finality assumptions, dispute model, and upgrade process | Network operator and institution | | Confidentiality guarantees, access logs, regulator access, and operational monitoring | Network operator and institution | | Asset controls, identity registry use, trusted issuer setup, roles, signing, and indexed state | DALP configuration plus institution operating model | A permissioned EVM network restricts who can read and submit data, who validates transactions, and who can inspect the network. It does not remove the need for token controls, custody rules, governance, monitoring, or reconciliation. ## Deployment-specific privacy layer [#deployment-specific-privacy-layer] Use this only when your deployment selects and approves a compatible privacy layer. | Option | What it can address | Required proof before claiming it | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Paladin or another EVM privacy framework | Selective disclosure, privacy groups, private smart-contract state, notary-based flows, or proof-backed token models | Selected provider, supported chain, contract model, key management, monitoring, and legal approval. | | Zero-knowledge proofs or shielded tokens | Proving transfer or eligibility rules without revealing underlying private state | Compatible contracts, circuits, prover operations, verification flow, audit evidence, and recovery model. | | Stealth-address patterns | Reducing recipient-address linkability for compatible transfers | Wallet support, registry compatibility, funding flow, reconciliation, and disclosure policy. | | Private order flow or encrypted mempool | Reducing pending transaction exposure before finality | Provider route, failure behaviour, monitoring, fallback path, and evidence trail. | ## Where to go next [#where-to-go-next] * [Public chain privacy](/docs/compliance-security/privacy/overview) for the decision summary. * [Public EVM visibility model](/docs/compliance-security/privacy/public-evm-visibility-model) for chain-visible data. * [Transaction ordering privacy](/docs/compliance-security/privacy/transaction-ordering-privacy) for pending transaction exposure. * [Supported networks](/docs/architects/integrations/supported-networks) for EVM network options.