DALP smart contract auditability overview

Overview of how DALP makes deployed EVM contracts reviewable through deployment records, bytecode checks, upgrade history, and audit evidence, with links to the detail pages for each evidence surface.

DALP contract auditability connects the addresses running on an EVM network to the expected DALP contract system and to the state transitions operators see in the platform. DALP supports that review through deployment records, bytecode presence checks, post-migration verification, upgrade evidence, indexed events, and off-chain workflow records.

This page is the entry to the auditability model. The detail pages cover each evidence surface in depth:

Deployment evidence — the address manifest, the bytecode-presence check, and the change controls operators preserve.
Bytecode verification — source-verification vs runtime-verification, and the open-source vs proprietary contract source answer.
Upgrade history — provenance, upgrade authority, proxy patterns, directory pointers, and timelock or cancellation controls.
Audit evidence — vulnerability-control, formal-assurance, and full audit-report answer shapes.

Who this is for

Reader	Decision this page supports
Technology architect	Decide which deployment evidence to collect before accepting a DALP environment
Security auditor	Check whether deployed contracts, addresses, roles, and migration state can be inspected
Operator	Understand which evidence belongs in an environment evidence pack
Integration lead	Know where on-chain evidence ends and where platform workflow evidence begins

The evidence model has a clear limit: block explorers, address manifests, bytecode checks, migration reads, and indexed events support technical review, but they do not replace a formal smart contract audit, customer approval record, or contractual assurance process. Treat the page as an explanation of what evidence exists and who controls each artifact, not as a substitute for the environment's security review.

Use this page with the security overview, transaction signing flow, and operability model when you assemble an environment review pack.

Auditability schematic

The schematic separates the review surfaces that can otherwise get blended together in an evidence pack. Deployment records tell auditors what to expect, RPC reads show what exists on the selected chain, verification reads test DALP wiring, indexed events connect accepted work back to submitted transactions, and the environment evidence pack preserves the result.

Rendering diagram...

Evidence model

A DALP deployment has four evidence layers.

Evidence layer	What it proves	Where it is checked or read
Deployment record	Which DALP modules were deployed for the environment and which addresses exist	The deployment address manifest created by the deployment process
Deployed bytecode	The recorded addresses contain EVM bytecode on the selected network	RPC bytecode reads against the configured network
System wiring	Core system, directory, registry, compliance, and token links are coherent	Post-deployment or post-migration verification reads from the contracts
Operational state evidence	The platform view matches accepted, queued, signed, submitted, and indexed work	Execution records, transaction status, chain events, indexer reads, logs

These layers answer different questions. A recorded address is not enough on its own. A non-empty bytecode response proves that code exists at an address, but it does not prove the whole system is wired correctly. Wiring checks prove the expected DALP relationships are present. Operational evidence shows how a business action moved through the platform and onto the chain.

Review flow

The review flow turns the schematic into a practical checklist. Review the evidence in this order so each check narrows the next one:

Start with the deployment record. Confirm the network, chain identifier, directory, system factory, and supporting addresses expected for the environment.
Read bytecode at the recorded core addresses. An eth_getCode response of 0x means no code is deployed at that address on the selected network, so the address record cannot be trusted until the environment is repaired or redeployed.
Run post-deployment or post-migration verification. These checks read contract state, migration version, registry links, interface support, and token readability instead of trusting the manifest alone.
Compare upgrade and administrator authority. Review owner, administrator, system-manager, and custody-policy records for accounts that can administer or upgrade contracts.
Reconcile a sample business action. Start with the platform request or transaction request ID for queued work, then match the terminal workflow status, transaction hash, indexed event, and final platform read for the same action.

For asynchronous writes, the transaction request ID is the first audit handle. Poll it until DALP exposes a terminal queue state and, for successful on-chain work, a transaction hash or receipt you can reconcile against indexed events. See Transaction tracking for the request-ID-to-hash lookup pattern.

This flow keeps source verification, runtime checks, and operator approval evidence separate. It also gives auditors a stable way to explain a failure: wrong address record, missing bytecode, failed wiring check, unclear authority, or an operational action that cannot be reconciled end to end.

Review checklist and next links

Step	Pass signal	Failure signal	Detail page
Deployment record	The manifest names the expected network, chain identifier, modules, and addresses	The manifest is missing, names the wrong network, or cannot be tied to the accepted release	Deployment evidence
Bytecode presence	Required addresses return non-empty EVM bytecode	A required address returns `0x` or the RPC read targets the wrong network	Bytecode verification
Post-migration verification	Version, registry, interface, and token-readability checks pass	The directory, registry, interface support, or migration version does not match the environment	Operability model
Authority review	Owner, administrator, system-manager, and custody-policy records are archived	An upgrade path exists without a matching approval or key-owner record	Upgrade history
Action reconciliation	Request ID, workflow status, transaction hash, event, and platform read agree	The platform state cannot be traced from the request ID to the submitted transaction or event	Audit evidence

What to include in an audit pack

For a production environment, collect the evidence in the order an auditor needs it:

Network and chain identifier for the environment.
Deployment address manifest for the DALP system and supporting contracts.
Explorer source verification links where the selected network and explorer support them.
Bytecode presence check for required contract addresses, including the chain ID and time the check was recorded.
Version pinning evidence for the deployed release or customer-controlled source package.
Complete independent security audit report for every token contract in scope, or the approved evidence channel that provides those reports for the environment.
Audit scope statement covering contracts, source package, compiler settings, proxy or implementation addresses, and deployment inputs.
Finding counts by severity, including Critical, High, Medium, Low, Informational, and accepted-risk findings.
Remediation notes and retest confirmation for every Critical and High finding.
Post-deployment or post-migration verification output for system wiring and migration version.
Upgrade authorization records for any post-deployment contract changes.
Owner, administrator, and system-manager role state for contracts that can be administered or upgraded.
Transaction samples showing request acceptance, durable execution status, chain transaction hash, indexed events, and final platform reads.
Token document records for asset files that need file-hash reconciliation, using the token document upload flow when the evidence belongs to the asset rather than a user's KYC profile.
Backup and recovery evidence for the operated environment, using the backup and recovery guide to keep RTO, RPO, restore drills, and incident-response evidence tied to the deployment instead of treating them as generic product guarantees.
Operator ownership notes for custody policy, RPC provider or node operation, backup retention, and incident response.

Keep environment keys, credentials, tenant identifiers, and private operational logs out of public documentation and shared screenshots. Keep proprietary source packages, full audit reports, and remediation work papers in the agreed review channel when they are not public or customer-controlled. Share sensitive evidence only through the approved channel for that environment.

Reserve and backing evidence

Reserve-backed, certificate-backed, and physical-asset-backed programmes need a second reconciliation path alongside contract source review. The contract evidence shows which token contracts and platform workflows executed. The reserve evidence shows whether the off-chain asset, custodian account, warehouse record, trustee report, or auditor attestation supports the token state.

Keep these two records connected but separate:

Review question	DALP evidence	External evidence owner
Which asset document was attached?	Token document metadata, `documentType`, version group, visibility, upload timestamp, uploader, and `fileHash`	Issuer, custodian, trustee, warehouse operator, verifier, or auditor
Does the document match the asset type?	Asset-profile document types such as `reserve_audit`, `attestation_report`, `assay_certificate`, `storage_receipt`, and `chain_of_custody`	Programme policy that decides which evidence type is acceptable for issuance, minting, redemption, or reconciliation
Did token state change after approval?	Request ID, transaction status, transaction hash, token event history, holder state, and final platform reads	Approval record that explains why the supply-changing action was allowed
Does the off-chain reserve still agree?	DALP supply, token documents, lifecycle events, and reconciliation checkpoints	Reserve report, custody statement, bank record, warehouse record, or external audit file

A token document record is evidence that DALP stored and classified an asset file. It is not automatic proof that a reserve exists, that a custodian still holds it, or that an auditor approved it. For reserve or physical-asset programmes, reconcile the token document fileHash and document type against the external evidence pack before approving a supply-changing action.

Use token document uploads for the asset file workflow. Use Precious metals when the reserve evidence is assay, storage, custody-chain, or insurance material for a metal programme.

Responsibility split

Area	DALP provides	Operator provides
Contract deployment process	Deployment modules, address records, and verification scripts	Environment approval, selected network, and release evidence retention
Runtime bytecode checks	RPC checks that required contract addresses contain bytecode	Network access, check evidence capture, and remediation when addresses are stale or unreachable
Migration verification	Contract reads that check version, registry, implementation, and token state	Decision to run and archive verification output for the environment
Explorer source verification	Source and compiler configuration needed for verification when available	Explorer publishing workflow where the network supports it
Proprietary source access	Public ABI, deployed address, version, audit availability, and agreed review material	Approval process for receiving restricted source or audit material
Upgrade governance	Upgradeable contract controls and role-readable authorization state	Approval records, custody controls, and key-owner records
Operational audit trail	Workflow state, transaction status, indexed events, and API-visible reads	External audit-pack assembly, legal sign-off, and policy documentation
Reserve and backing evidence	Token document metadata, file hash, asset-profile document type, token state, and lifecycle event history	Reserve reports, custody statements, warehouse records, trustee approvals, auditor attestations, and reconciliation policy

The practical rule is straightforward: use DALP evidence to prove what the platform deployed, recorded, and executed, then attach the operator-owned approvals and policies that explain why those actions were allowed.

Contract source and deployment evidence sit between architecture review and operations review. Use these pages as the next reading path:

Architecture overview explains the DALP layers and ownership split.
Security overview explains the identity, access, compliance, and custody control model.
Transaction signing flow shows how transactions move from a platform request to an EVM submission.
Operability model explains telemetry, persistence, and failure recovery.
High availability explains resilience patterns without turning them into SLA commitments.

Smart contract source verification and deployment auditability