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.
Bytecode verification proves that the code running at a recorded address on the configured network is the code that was reviewed. The check sits between deployment-record review (the recorded addresses themselves) and runtime-state checks (the DALP wiring those contracts implement). This page covers how DALP separates the two controls and what evidence operators share for different source-access categories.
For the deployment-record evidence the check runs against, see Deployment evidence. For the overall review flow, see Source verification and auditability overview.
Source verification versus runtime verification
Source verification and runtime verification are related, but they are not the same control.
| Control | What the auditor checks | What it does not prove |
|---|---|---|
| Published source on an explorer | The explorer can associate source, compiler settings, and bytecode for an address | That the contract is wired into the correct DALP system |
| Bytecode presence check | The expected address has bytecode on the configured EVM network | That the bytecode was compiled from a specific source package |
| Deployment manifest review | The environment has a recorded address set for deployed modules | That the chain currently contains code at every recorded address |
| Migration verification | System version, registry links, interfaces, and token readability pass checks | That external legal, custody, or operating procedures were approved |
| Indexed event reconciliation | Platform reads can be traced back to chain events and transaction status | That an off-chain instruction was legally sufficient |
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.
| Source category | What auditors can usually inspect | What is not shared by default |
|---|---|---|
| Public or customer-controlled contract source | Repository tag or release package, compiler settings, constructor or initializer arguments, explorer verification links, and deployment addresses | Customer keys, credentials, private tenant data, and operational logs |
| DALP-managed proprietary contract source | Deployed addresses, bytecode checks, public ABI surface, explorer verification links when available, audit report availability, version evidence, and role or owner state needed for the environment review | Restricted source materials that are outside the agreed review scope |
| Customer extensions or environment-specific add-ons | Customer repository or release package, explorer verification links, deployment addresses, and ownership records supplied by the customer | The platform does not attest to customer-controlled source unless it is part of the agreed review scope |
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:
- 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.
- 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.
- Deployment and evidence responsibilities: 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.
- Documentation link: point reviewers to the source-verification overview, 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:
| Review question | DALP answer | Evidence to provide |
|---|---|---|
| Is DALP open source? | No. DALP core product code is proprietary and source-available under the customer's agreed commercial terms. | Commercial source-access terms, release package, and customer review channel |
| Which parts use third-party open-source components? | Dependency and infrastructure components vary by release and deployment profile. Their licenses are reviewed from the release-specific manifest. | Dependency manifest, software bill of materials, container provenance, and license review |
| Can auditors verify deployed smart contract code? | Yes, when the evidence pack includes the deployed addresses, source or release package, compiler settings, constructor or initializer inputs, and bytecode checks. | Deployment manifest, explorer verification links where supported, RPC bytecode reads, and proxy or implementation reads |
| Can auditors inspect proprietary implementation code? | Yes within the agreed review scope. Restricted source, full audit reports, remediation work papers, private tenant data, and credentials stay outside public docs. | Approved evidence-channel access, audit reports, remediation records, and restricted source package when contracted |
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.
Read next
- Deployment evidence for the address-manifest and change-control evidence the bytecode check runs against.
- Upgrade history for proxy patterns and post-upgrade bytecode comparison.
- Audit evidence for the audit-report attestation that pairs with bytecode verification.
- Source verification overview
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.
Upgrade history
How auditors trace DALP contract provenance, upgrade authorisation, proxy patterns, directory pointers, and timelock or cancellation controls for the deployed environment.