# Public EVM visibility model Source: https://docs.settlemint.com/docs/compliance-security/public-evm-visibility-model What public EVM networks can expose when DALP assets use on-chain eligibility, claims, token events, and transaction history. Public EVM deployments expose more than final balances. A security reviewer should treat addresses, calldata, events, registry links, claim relationships, transaction timing, and contract state as discoverable unless the selected network or provider proves a stronger control. DALP limits disclosure by keeping private evidence off-chain and publishing only the enforcement state the contracts need. ## What becomes visible [#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 historical action sequence | Assume regulated actions 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 [#enforcement-and-evidence-split] DALP uses EVM contracts for token issuance, ownership, transfer enforcement, identity registry lookups, trusted issuer checks, and compliance module execution. Detailed verification evidence stays off-chain in the operator's approved verification and document workflows. The chain records the enforcement facts. The source documents, screening reports, internal notes, and legal evidence stay in controlled off-chain systems. ## Threat-model questions [#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 [#metadata-review] | 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 [#where-to-go-next] * [Public chain privacy](/docs/compliance-security/public-chain-privacy) for the decision summary. * [Transaction ordering privacy](/docs/compliance-security/transaction-ordering-privacy) for pending transaction and routing exposure. * [Identity and compliance](/docs/compliance-security/security/identity-compliance) for claim-based enforcement.