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.
An auditor who receives only a deployed address cannot verify what was deployed, which inputs the deployer ran, or which approvals authorised the change. DALP closes that gap by making each step reviewable. The deployer account is validated before the run starts, the address manifest records what was installed, and the change-control artifacts give auditors a traceable chain from governance approval to on-chain bytecode.
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: the system factory, directory, and supporting infrastructure contracts. Keep the manifest with your environment release evidence; it anchors the address checks, the explorer verification, and the post-migration review that follow.
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 workflow requires the target contract to exist before it continues. When your 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 each step reviewable before and after the transaction is submitted. Your environment evidence pack should show the approved deployer, the deployment inputs, the release or source package, and the compiled artifact evidence. The pack should also show 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 flags to select which contract modules to include. Prior to deploying, DALP removes stale module futures from the Ignition deployment journal so disabled or previously toggled features do not stay in the plan by accident. That cleanup has three guardrails: it only removes module futures, applies a safety cap to the number of entries removed, and writes rotating backups before replacing the deployment journal.
Reviewers confirm deployment parameters through the deployment record and post-deployment checks. Record 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, your 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 your environment's accepted address and version set. DALP records deployed addresses in the manifest, uses registry and directory pointers for active system, factory, add-on, token-type, and compliance-module implementations, and verifies those pointers through post-deployment or post-migration queries.
Feature modules converge through on-chain calls that register add-on, token-type, and compliance-module addresses. Keep both the deployed addresses and the registry or directory query results that made those contracts trusted for your environment.
Controls to preserve
The eight controls split responsibility between DALP and your environment team. Each row names the evidence to collect and the review question it answers.
| 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 for your auditors. 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.
Source verification
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.
Source vs runtime verification and contract source access
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.