Smart contract source verification and deployment auditability

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.

Who this is for

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.

Evidence model

A DALP deployment has four evidence layers.

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:

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. Match the platform request, workflow status, transaction hash, indexed event, and final platform read for the same action.

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

Deployment address trace

The deployment process writes a manifest of deployed contract addresses for the environment. DALP uses that record to resolve core addresses such as the system factory, directory, and supporting infrastructure contracts. Operators should preserve the manifest with the environment release evidence because it is the starting point for later address, explorer, and migration review.

When the platform validates an address that must already contain a contract, it reads bytecode from the configured EVM network. A missing bytecode response is terminal because the target contract is expected to exist before the workflow continues. When a review needs dated bytecode proof, record the chain ID, address, redacted RPC provider or network details, block tag, check time, and eth_getCode result in the environment evidence pack.

Deployment change controls

DALP supports secure EVM contract deployment by making the technical deployment step reviewable before and after the transaction is submitted. The environment evidence pack should show the approved deployer, the deployment inputs, the release or source package, the compiled artifact evidence, the registered trusted addresses, and the approval record that allowed the change to move from development to test to production.

The deployment runner validates the connected deployer account against the configured expected deployer for networks that declare one. If the first available account does not match, the run stops before deploying contracts. Feature-controlled deployments use the network's configured feature flags to decide which contract modules are included. Before deploying, DALP removes stale feature-module futures from the Ignition journal so disabled or previously toggled features do not stay in the deployment plan by accident. That journal cleanup has three guardrails: it only removes feature futures, applies a safety cap to the number of entries removed, and writes rotating backups before replacing the journal.

Deployment parameters are reviewed through the deployment record and post-deployment checks. Preserve the network, chain identifier, feature configuration, deployment identifier, constructor or initializer inputs, compiler settings, release or source package, deployed address manifest, and explorer source-verification links where the selected network supports them. For reproducible-build review, the evidence pack should let the reviewer rebuild the scoped artifact from the accepted source package and compare compiler settings, constructor or initializer arguments, deployed bytecode, proxy address, and implementation address with the deployed environment.

Trusted contract registration is the environment's accepted address and version set. DALP records deployed addresses in the manifest, uses directory and registry pointers for active system, factory, add-on, token-type, and compliance-module implementations, and verifies those pointers through post-deployment or post-migration reads. Feature modules converge through directory registration calls such as add-on, token-type, and compliance-module registration, so the evidence pack should preserve both the deployed addresses and the directory or registry reads that made those contracts trusted for the environment.

Preserve these controls with the deployment evidence pack:

These controls have a clear boundary. DALP makes the deployer, parameters, address set, role state, bytecode presence, source-verification evidence, and runtime wiring reviewable. Governance approval, custody approval, promotion sign-off, immutable configuration baselines, full reproducible-build work papers, and independent audit reports belong in the environment evidence channel. For evaluator responses, link to https://docs.settlemint.com/docs/architecture/security/source-verification-auditability, then provide the customer-specific approval and evidence pack through the agreed review channel.

Source verification versus runtime verification

Source verification and runtime verification are related, but they are not the same control.

If a deployment uses a public block explorer, the operator should publish or verify contract sources there as part of the environment evidence pack. DALP runtime checks still remain useful because explorer source verification does not check system wiring, role state, migration version, upgrade authority, or indexed operational state.

Contract source access

Contract source evidence depends on who controls the source and the environment.

When proprietary source is not shared directly, the evidence pack should still let an auditor answer four practical questions: which address is running, which ABI or public interface is expected, which version or release is pinned for the environment, and which party can authorize an upgrade.

Open-source and proprietary source answer

DALP is a licensed, source-available platform, not an open-source platform. Its core product source is shared only under the customer's agreed commercial source-access terms. A platform-wide open-source percentage is therefore not a stable public assurance claim. The meaningful review artifact is the deployment evidence pack for the exact delivered environment.

Use this order when an evaluator asks what percentage of the tokenization platform is open source versus proprietary closed source:

1. Direct answer: state that DALP core product code is proprietary and source-available under the agreed commercial terms, while third-party dependencies and infrastructure components retain their own licenses.
2. DALP mechanism: provide the scoped component list for the environment, including smart contracts, APIs, workflow services, web application, indexer, deployment charts, container images, and any customer or partner extensions.
3. Deployment and evidence boundary: attach the release-specific source package, dependency manifest or software bill of materials, container provenance where available, explorer source-verification links where the selected network supports them, and third-party audit or license evidence through the approved evidence channel.
4. Documentation link: point reviewers to https://docs.settlemint.com/docs/architecture/security/source-verification-auditability, then provide the environment evidence pack through the agreed evidence channel.

A complete answer should separate product source, third-party dependency source, deployed bytecode, and audit evidence:

Do not use a single percentage to answer a production review unless the percentage comes from a release-specific dependency or software-composition report for the exact delivered environment. A generic percentage can mislead reviewers because an environment may include different optional modules, deployment charts, images, customer extensions, public network explorers, and third-party services.

Smart contract provenance and upgrade auditability

An auditor should be able to trace both the deployed contract and the authority that can change it.

DALP uses upgradeable EVM patterns in parts of the contract system. Upgrade evidence should therefore include the authorization path, not only the new implementation address. If the operator changes owner or administrator keys, archive the before-and-after role state with the same care as the deployment manifest.

Timelock and governance-attack controls

DALP does not apply a platform-wide on-chain timelock or minimum delay duration to high-consequence governance actions by default. The default minimum delay for the operation types in this section is therefore 0 seconds unless the deployed environment adds a delay through an external governance contract, custody workflow, smart-wallet policy, or operating procedure. DALP also does not grant the bank a universal independent cancellation right after a privileged transaction is signed or broadcast. Cancellation authority exists only where the selected approval, custody, smart-wallet, or external governance route enforces it before execution.

High-consequence actions are controlled first by role-gated EVM functions and the custody, proxy-administration, or smart-wallet approval policy configured for the environment. DALP API paths that submit privileged role and asset operations also use wallet selection and transaction-queue execution. If a customer requires a mandatory delay window or bank cancellation right, the evidence pack must identify the environment-specific control that enforces it.

Use this order when an evaluator asks about timelocks and governance attack prevention:

1. Direct answer: state the minimum delay for the reviewed environment for each operation type. If the environment uses DALP defaults, the delay is 0 seconds and there is no DALP-enforced timelock. Do not answer "yes" unless the evidence pack names the delay, authority, and enforcement point.
2. DALP mechanism: map the operation to its privileged path. System role grants and revocations require an administrator path. Asset role grants and revocations require the token administrator path. Supply-cap changes require the asset Governance role. System migrations and upgrades require the authorised system-management or proxy-administration path for the deployed environment. These actions then follow the selected signing, custody, or smart-wallet approval route before a transaction can be broadcast.
3. Deployment and evidence boundary: attach the deployed role-holder reads, approval-policy configuration, queue or signing evidence, transaction hash, before-and-after role or implementation reads, and any customer-specific approval record. If the bank has an independent cancellation right, show where that right is enforced before execution, for example in the smart-wallet approval threshold, custody approval workflow, or external governance process.
4. Documentation link: point reviewers to https://docs.settlemint.com/docs/architecture/security/source-verification-auditability, then provide the actual environment evidence pack through the agreed evidence channel.

A complete timelock answer should separate DALP's built-in authorization controls from customer-specific delay controls:

The attack-prevention boundary is important. DALP can enforce role separation, reject callers without the required role, preserve queued execution and signing evidence, and expose the resulting transaction and role state for audit. DALP's public contract layer should not be described as providing a universal minimum timelock or bank cancellation right unless the deployed environment actually routes those operations through a control that enforces that delay or cancellation authority. If a privileged credential is compromised and can satisfy the configured approval route immediately, the mitigation is the environment's key custody, approval threshold, monitoring, and emergency-revocation process, not an implicit DALP timelock.

How to answer a vulnerability-control request

For reentrancy, overflow and underflow, access-control, and formal-assurance questions, answer with the deployed-scope evidence pack. DALP uses EVM contracts compiled with Solidity 0.8.x arithmetic checks, OpenZeppelin ReentrancyGuard on external-call paths that need an explicit guard, checks-effects-interactions ordering where that pattern is the safer fit, and role-gated entry points for privileged token and system actions. An evaluator still needs evidence tied to the exact deployed contracts, not a generic platform statement.

Use this order when an evaluator asks how common smart contract vulnerability classes are controlled:

1. Direct answer: identify the deployed contract set, compiler version, privileged entry points, and external-call functions in scope for the environment under review.
2. DALP mechanism: show the control used for each class. For access control, list the privileged mint, burn, pause, freeze, recovery, compliance-configuration, metadata, feature-configuration, custody, and upgrade functions, then map each one to the required asset or system role. For reentrancy, show whether each external-call path uses nonReentrant, checks-effects-interactions ordering, or a bounded-call reason. For arithmetic, show the compiler version and any approved unchecked arithmetic blocks.
3. Deployment and evidence boundary: attach independent audit results, Slither and Aderyn static-analysis results from the contract review pipeline, remediation evidence, retest evidence, role-holder reads, rejected-call tests, and regression evidence for the deployed scope through the approved evidence channel.
4. Documentation link: point reviewers to https://docs.settlemint.com/docs/architecture/security/source-verification-auditability for the public verification model, then provide the actual environment evidence pack through the agreed evidence channel.

A complete vulnerability-control answer should let the reviewer trace each claim to the deployed code path:

This answer is intentionally evidence-based. Public docs can explain the control model, but the production assurance comes from the current environment's contract addresses, role reads, audit reports, static-analysis output, rejected-call tests, and regression evidence.

How to answer a formal-assurance request

DALP does not claim formal verification of tokenization supply or transfer invariants as a default platform assurance. Treat the formal-verification answer as "not formally verified" unless the environment evidence pack includes a formal-verification report for the exact deployed token contract version and invariant set under review.

That boundary is deliberate. DALP's public assurance model for asset-backed tokens is based on role-gated supply functions, SMART token compliance checks, deployment verification, independent audit evidence, static analysis, regression tests, and transaction reconciliation. These controls provide implementation assurance for review, but they are not a mathematical proof of the token invariants.

Use this order when an evaluator asks about formal verification and supply invariants:

1. Direct answer: state whether the deployed token contracts were formally verified for the requested invariants. If the evidence pack has no matching proof, say that the deployed token scope is not formally verified.
2. DALP mechanism: identify the token entry points and controls that protect the requested invariants. Supply changes go through role-gated mint and burn functions. Ordinary token transfers go through the SMART token transfer path and compliance checks before token-state changes complete. Failed compliance checks or rejected execution revert the token-state change.
3. Deployment and evidence boundary: attach the environment-specific assurance pack. The pack should include the deployed contract list, compiler version, source or release package, independent audit report, static-analysis results, unit and regression tests for mint, burn, batch mint, batch burn, transfer rejection, and role rejection, plus any manual invariant review performed for the release.
4. Documentation link: point reviewers to https://docs.settlemint.com/docs/architecture/security/source-verification-auditability, then provide the actual environment evidence pack through the agreed evidence channel.

A complete non-formal assurance answer should cover the evaluator's three requested invariants without overstating the proof level:

The boundary matters. Static analysis, audits, role tests, regression tests, deployment verification, and transaction reconciliation can give strong implementation assurance, but they are not the same artifact as a formal verification proof. If a customer requires formal proof for a production asset, include that proof in the customer evidence pack or state that the deployed scope is not formally verified.

How to answer a smart contract audit evidence request

Answer the request with the environment evidence pack, not with this public page alone. The pack must include the complete independent security audit report for every token contract in scope. This page gives the repeatable verification model that ties those reports to the deployed EVM contracts.

Use this order when an evaluator asks for smart contract audit, findings, and remediation evidence:

1. Direct answer: provide the independent security audit report for every token contract in the production environment, including the auditor name, audit date, and evidence that the auditor was independent from the implementation team.
2. DALP mechanism: tie each report to the deployed DALP contract set with the deployment manifest, explorer source verification where available, RPC bytecode checks, proxy or implementation address evidence, migration verification output, and upgrade records.
3. Deployment and evidence boundary: share full audit reports, remediation work papers, retest evidence, restricted source packages, customer-specific keys, tenant identifiers, and private logs only through the approved evidence channel for the reviewed environment. Public docs describe the evidence model; they do not publish customer-specific audit packs.
4. Documentation link: point reviewers to https://docs.settlemint.com/docs/architecture/security/source-verification-auditability for the verification model, then provide the actual audit reports and environment pack through the agreed evidence channel.

The audit report set is complete only when its scope matches the token contracts that are deployed for the environment under review. A report against an unrelated source snapshot is not enough. The pack must show the contract list, compiler settings, constructor or initializer inputs, network, deployment addresses, proxy and implementation addresses where applicable, and the release or source package that the auditor reviewed.

A complete audit pack should let the reviewer answer five questions:

The deployed-bytecode check is the final guardrail. Include explorer source verification links where the selected network supports them, plus an RPC bytecode check against the recorded deployment addresses. If the deployed bytecode, compiler settings, constructor or initializer arguments, proxy address, or implementation address differs from the audited scope, treat that as a scope mismatch until the difference is explained and approved.

For upgradeable contracts, collect both sides of the evidence: the proxy or directory address that users interact with, and the implementation address that contains the audited logic. After an upgrade, archive the upgrade authorization record, implementation address, storage-layout review where applicable, post-migration verification output, and a fresh sample transaction reconciliation.

Upgradeability governance answer

For governance review, answer the upgradeability question in this order:

Proxy upgrade and directory review

DALP uses upgradeable proxy patterns for system and asset-token components where the deployed environment supports upgrades. System upgrades use UUPS-compatible implementations through the ERC-1967 implementation slot. Asset tokens keep the same token address because the token proxy continues to route through the factory-selected implementation.

The upgrade authority is not a single DALP-wide public address. It is the exact wallet or contract address that holds the required role in the deployed environment. A system proxy upgrade must be executed by a system manager. A directory implementation update must be executed by a directory administrator. The evidence pack should name the executing address, the role that authorised it, and the approval or custody record for that action.

DALP does not add a protocol-level mandatory timelock to system or token implementation changes. If the environment's governance model requires a waiting period, the operator enforces that delay before the authorised transaction is submitted and preserves the delay evidence with the authorization record.

Review storage compatibility before a new implementation address becomes active. For upgradeable implementations, preserve OpenZeppelin upgrade validation output or an equivalent compiler storage-layout comparison. For immutable or frozen contracts, preserve the ABI and storage-layout baseline review that shows whether replacement deployment is required instead of in-place patching.

For system upgrades, review the proxy, directory, and migration evidence together. The upgrade workflow reads the expected SYSTEM implementation from the active directory. The workflow submits the proxy upgrade when the ERC-1967 slot differs, then runs the system migration with the active directory address. When the migration call reaches a contract that is already at the expected version, the contract reverts with its reinitializer guard and the workflow treats that already-migrated response as complete.

The directory is the source of implementation pointers for the active network. Directory upgrade evidence should show which implementations were registered before the system upgrade used them. The evidence includes registry implementations, identity factory implementation, token factories, add-ons, compliance modules, and chain-of-trust registries. A system upgrade audit pack is incomplete if the pack records only the final system address and omits the directory pointers that selected the implementation set.

Review migration sequencing as part of storage and state continuity. The compliance module registry migrates before system compliance because system compliance migration reads the registry's type-based module records. Asset token addresses remain stable during factory and token implementation reconciliation, so the audit pack should preserve the same token addresses before and after the upgrade, then attach the post-migration wiring checks.

Rollback depends on the failure mode. If the new implementation is wrong but state remains readable, the operator can register the previously approved implementation, run the guided upgrade workflow again, and repeat post-migration checks. If investor state is corrupted or cannot be read safely, preserve the affected state, stop further operations through the environment's incident process, and move to replacement contracts and governed balance movement where required. The old token address and event history remain part of the audit record.

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. Operator ownership notes for custody policy, RPC provider or node operation, backup retention, and incident response.

Keep customer-specific 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.

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

Responsibility split

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