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
| 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
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.
Rendering diagram...
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
| 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 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.