# Smart contract source verification and deployment auditability Source: https://docs.settlemint.com/docs/compliance-security/source-verification/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](/docs/compliance-security/source-verification/deployment-evidence) — the address manifest, the bytecode-presence check, and the change controls operators preserve. * [Bytecode verification](/docs/compliance-security/source-verification/bytecode-verification) — source-verification vs runtime-verification, and the open-source vs proprietary contract source answer. * [Upgrade history](/docs/compliance-security/source-verification/upgrade-history) — provenance, upgrade authority, proxy patterns, directory pointers, and timelock or cancellation controls. * [Audit evidence](/docs/compliance-security/source-verification/audit-evidence) — vulnerability-control, formal-assurance, and full audit-report answer shapes. ## Who this is for [#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](/docs/compliance-security/security), [transaction signing flow](/docs/architects/flows/signing-flow), and [operability model](/docs/architects/operability) when you assemble an environment review pack. ## Auditability schematic [#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. ## Evidence model [#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 [#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: 1. Start with the deployment record. Confirm the network, chain identifier, directory, system factory, and supporting addresses expected for the environment. 2. 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. 3. 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. 4. Compare upgrade and administrator authority. Review owner, administrator, system-manager, and custody-policy records for accounts that can administer or upgrade contracts. 5. 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](/docs/developers/operations/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 [#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](/docs/compliance-security/source-verification/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](/docs/compliance-security/source-verification/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](/docs/architects/operability) | | 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](/docs/compliance-security/source-verification/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](/docs/compliance-security/source-verification/audit-evidence) | ## What to include in an audit pack [#what-to-include-in-an-audit-pack] For a production environment, collect the evidence in the order an auditor needs it: 1. Network and chain identifier for the environment. 2. Deployment address manifest for the DALP system and supporting contracts. 3. Explorer source verification links where the selected network and explorer support them. 4. Bytecode presence check for required contract addresses, including the chain ID and time the check was recorded. 5. Version pinning evidence for the deployed release or customer-controlled source package. 6. Complete independent security audit report for every token contract in scope, or the approved evidence channel that provides those reports for the environment. 7. Audit scope statement covering contracts, source package, compiler settings, proxy or implementation addresses, and deployment inputs. 8. Finding counts by severity, including Critical, High, Medium, Low, Informational, and accepted-risk findings. 9. Remediation notes and retest confirmation for every Critical and High finding. 10. Post-deployment or post-migration verification output for system wiring and migration version. 11. Upgrade authorization records for any post-deployment contract changes. 12. Owner, administrator, and system-manager role state for contracts that can be administered or upgraded. 13. Transaction samples showing request acceptance, durable execution status, chain transaction hash, indexed events, and final platform reads. 14. Token document records for asset files that need file-hash reconciliation, using the [token document upload flow](/docs/api-reference/tokens/token-documents) when the evidence belongs to the asset rather than a user's KYC profile. 15. Backup and recovery evidence for the operated environment, using the [backup and recovery guide](/docs/architects/self-hosting/high-availability/backup-recovery) to keep RTO, RPO, restore drills, and incident-response evidence tied to the deployment instead of treating them as generic product guarantees. 16. 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-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](/docs/api-reference/tokens/token-documents) for the asset file workflow. Use [Precious metals](/docs/business/use-cases/precious-metals) when the reserve evidence is assay, storage, custody-chain, or insurance material for a metal programme. ## Responsibility split [#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. ## Related architecture pages [#related-architecture-pages] Contract source and deployment evidence sit between architecture review and operations review. Use these pages as the next reading path: * [Architecture overview](/docs/architects/overview) explains the DALP layers and ownership split. * [Security overview](/docs/compliance-security/security) explains the identity, access, compliance, and custody control model. * [Transaction signing flow](/docs/architects/flows/signing-flow) shows how transactions move from a platform request to an EVM submission. * [Operability model](/docs/architects/operability) explains telemetry, persistence, and failure recovery. * [High availability](/docs/architects/self-hosting/high-availability) explains resilience patterns without turning them into SLA commitments.