Deployment evidence
How DALP makes the contract-deployment step reviewable through the deployment record, address manifest, bytecode presence checks, and the change controls operators preserve for the environment evidence pack.
DALP makes the contract-deployment step reviewable before and after the transaction is submitted. The deployment record, the address manifest, the bytecode presence checks, and the change-control artifacts together prove which addresses were deployed for the environment, which inputs the deployer ran, and which approvals authorised the change.
For the auditor's review flow that consumes this evidence, see Source verification and auditability overview. For the broader review surface, see Security overview.
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.
Controls to preserve
| Control | Evidence to preserve | Review question it answers |
|---|---|---|
| Approved deployer validation | Network name, configured expected deployer, executing deployer, custody approval, and failed-run evidence when they differ | Did the deployment run from the approved account after the required approval? |
| Deployment parameter review | Chain identifier, deployment identifier, feature configuration, constructor or initializer inputs, compiler settings, and accepted release package | Were the deployment inputs reviewed before the transaction was submitted? |
| Controlled promotion | Development, test, and production manifests, approval records, accepted release identifiers, and any immutable configuration baseline for the stage | Did the same accepted contract set move through the environment promotion path? |
| Feature flag selection | Network feature configuration and deployed address manifest | Which optional modules were included for this environment? |
| Journal cleanup guardrail | Journal backup record, removed feature-future summary, and deployment log | Were stale feature deployment steps removed without deleting core deployment state? |
| Trusted address registration | Directory, registry, system, factory, add-on, token-type, compliance-module, proxy, and implementation address reads | Which contract addresses and versions are trusted for this environment? |
| Reproducible-build verification | Source package or release identifier, compiler settings, constructor or initializer arguments, explorer verification link, and bytecode comparison | Does the deployed bytecode match the accepted artifact and build inputs? |
| Post-deployment verification | Directory address, bytecode checks, migration or wiring verification output, role reads, implementation pointers, and sample token reads | Did the deployed contracts match the expected DALP system after the run? |
These controls have a clear responsibility split. 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.
Read next
- Bytecode verification for the source-versus-runtime check model and the open-source vs proprietary source answer.
- Upgrade history for the upgrade-authority and proxy-pattern evidence.
- Audit evidence for vulnerability controls and formal-assurance answers.
- Source verification overview for the entry-page schematic and review flow.
Smart contract source verification and deployment auditability
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.
Bytecode verification
How auditors check that deployed EVM bytecode matches the accepted source package, and what the operator shares about DALP-managed proprietary contract source versus customer-controlled source.