Public EVM visibility model
How to identify which DALP asset data becomes discoverable on public EVM networks and which evidence must stay in controlled off-chain systems.
Public EVM deployments expose more than final balances. Treat wallet addresses, calldata, events, registry links, claim relationships, settlement timing, and contract state as discoverable unless your selected network or provider proves a stronger control.
DALP limits disclosure by keeping sensitive source material off-chain and publishing only the contract state your on-chain contracts need to enforce rules. Your programme's off-chain systems hold the source evidence; the chain holds only what contract enforcement requires.
What becomes visible
| Area | Public-chain visibility | Safer operating rule |
|---|---|---|
| Token contracts | Contract addresses, token operations, role changes, mints, transfers, burns, pauses, and configuration | Keep personal data and confidential terms out of token names, symbols, metadata, and config values. |
| Identity registry | Wallet-to-identity relationships and token-specific identity checks, depending on registry use | Treat identity addresses and wallet links as public-chain information. |
| OnchainID claims | Claim topics, issuers, signatures, references, and claim lifecycle events | Use claim topics for eligibility states. Keep raw verification evidence off-chain. |
| Trusted issuer registry | Which issuers are trusted for which claim topics | Expect issuer relationships to be observable and explainable to auditors and counterparties. |
| Compliance modules | Module addresses, token-specific parameters, and transfer pass or fail outcomes through transaction behaviour | Configure the minimum data needed for enforcement. |
| Transaction logs and history | Transaction hashes, event logs, block timestamps, and the historical operation sequence | Assume regulated operations can be correlated over time. |
| Off-chain platform records | Platform accounts, verification files, workflow notes, and documents | Govern through platform permissions, retention rules, verifier controls, and contractual terms. |
Enforcement and evidence split
DALP uses EVM contracts for token issuance, ownership, transfer rules, identity registry lookups, trusted issuer checks, and compliance module execution. Detailed source material stays off-chain in the operator's approved review and document workflows.
The chain records only the facts the contracts enforce. Source documents, screening reports, and legal files stay in controlled off-chain systems alongside internal notes.
Threat-model questions
| Question | What DALP can enforce | What the operator must decide |
|---|---|---|
| Can regulated transfers be limited to eligible holders? | Yes. Configured EVM contracts enforce rules through identity registries, trusted issuer claims, compliance modules, token roles, and signing workflows. | Which claim topics, issuers, asset rules, signer controls, and evidence prove the programme's policy. |
| Can KYC, KYB, AML, or investor documents stay off-chain? | Yes. DALP can publish claim and registry state for enforcement while source evidence remains in approved off-chain systems. | Which evidence system, verifier workflow, retention policy, and access controls hold the underlying files and review notes. |
| Can wallet activity and token events be hidden by default? | No. Public EVM wallets, calls, events, contract state, and timing remain visible once submitted, written, or emitted. | Whether address reuse, metadata, RPC routing, public mempool exposure, and chain analytics risk are acceptable. |
| Who can correlate activity? | DALP can minimise regulated evidence on-chain, but it cannot stop correlation from public addresses, events, calldata, timing, registry links, or provider logs. | Which block explorers, RPC providers, validators, custodians, verifiers, issuers, counterparties, and internal operators can observe each step. |
| What is the trust anchor? | Contract enforcement depends on configured EVM contracts, identity registries, trusted issuers, claim topics, compliance modules, and role assignments. | Which issuers, verifiers, custodians, network operators, and legal evidence make that trust model acceptable. |
Metadata review
Choose metadata carefully. Public chains permanently record every value you write to them. Each row identifies safer public-chain use alongside values to avoid, organized by metadata type.
| Metadata type | Safer public-chain use | Avoid |
|---|---|---|
| Token name and symbol | Public product label approved for investor and regulator visibility | Customer names, account references, confidential asset labels, or private programme codenames |
| Token URI or document references | Neutral public document references or approved public URLs | Private document links, file names, personal data, internal IDs, or confidential commercial terms |
| Claim topics | Abstract eligibility state, such as KYC passed or investor category | Raw screening outcome, personal identifier, exact source document, or sensitive reason code |
| Event parameters | Values required for on-chain enforcement and reconciliation | Notes, explanations, reviewer names, private evidence IDs, or confidential tranche terms |
| Transaction inputs | Contract parameters required for the operation | Any data that should not be permanently discoverable |
Where to go next
- Public chain privacy for the decision summary.
- Transaction ordering privacy for pending transaction and routing exposure.
- Identity and compliance for claim-based enforcement.