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 comes from the chosen architecture around those controls: what the asset writes on-chain, where evidence stays off-chain, which network carries the transactions, and which providers operate the transaction path.
Use these patterns to classify a privacy requirement before you commit to a public-chain answer.
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 actions. |
Pattern 1: Public eligibility, private evidence
Use this when a 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. |
Pattern 2: Selective disclosure through claims
Use this when the chain needs to know that an eligibility condition is satisfied, but not the evidence behind it.
| 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 |
Pattern 3: Minimal on-chain metadata
Use this when the 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 |
Pattern 4: Private or permissioned EVM network
Use this when public transaction and state visibility is not acceptable for the 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 can restrict who reads, submits, validates, and inspects network data. It does not remove the need for token controls, custody controls, role governance, monitoring, and reconciliation.
Pattern 5: Deployment-specific privacy layer
Use this only when the 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
- Public chain privacy for the decision summary.
- Public EVM visibility model for chain-visible data.
- Transaction ordering privacy for pending transaction exposure.
- Supported networks for EVM network options.
Transaction ordering privacy
How to review pending transaction, mempool, RPC, bundler, builder, and sequencing exposure for DALP public EVM deployments.
Pre-launch privacy review
Operator checklist for reviewing on-chain fields, evidence storage, transaction routing, and legal approval before a regulated asset uses a public EVM network.