Audit evidence
How to answer vulnerability-control, formal-verification, and smart-contract audit evidence requests with DALP's deployed-scope evidence pack.
This page covers the three evaluator request shapes that surface around DALP smart contracts: vulnerability-control questions, formal-verification claims, and full audit-report attestation. Each section gives the answer order and the evidence operators preserve for the environment's audit pack.
For the deployment evidence that anchors these answers, see Deployment evidence. For the overall review flow, see Source verification and auditability overview.
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:
- Direct answer: identify the deployed contract set, compiler version, privileged entry points, and external-call functions in scope for the environment under review.
- 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. - Deployment and evidence responsibilities: 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.
- Documentation link: point reviewers to the source-verification overview 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:
| Vulnerability class | DALP evidence to provide | Acceptance check |
|---|---|---|
| Reentrancy | External-interaction inventory, state-update ordering, nonReentrant or ordering evidence, and asset-flow tests | Mutable functions that can re-enter have a documented guard, checks-effects-interactions pattern, or bounded reason |
| Overflow and underflow | Solidity compiler version, arithmetic-sensitive code review, unchecked-block review, and tests | Arithmetic relies on Solidity 0.8.x checks unless a reviewed unchecked block is explicitly scoped |
| Access control | Role map, role-holder evidence, privileged function list, and sample rejected-call evidence | Mint, burn, pause, freeze, recovery, compliance, metadata, feature, custody, and upgrade actions require the expected role |
| Static analysis | Slither and Aderyn results, accepted findings, suppression rationale, remediation evidence, and retest evidence | Access-control, reentrancy, arithmetic, and upgrade findings have a current disposition for the deployed scope |
| Finding remediation | Independent findings, severity, disposition, fix evidence, and retest confirmation | Critical and High findings are fixed, mitigated, accepted, or out of scope with approval |
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 split 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:
- 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.
- 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.
- Deployment and evidence responsibilities: 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.
- Documentation link: point reviewers to the source-verification overview, 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:
| Invariant requested by the evaluator | DALP control and evidence to provide | Acceptance check |
|---|---|---|
totalSupply() equals the sum of valid holder balances after token operations | ERC-20 token accounting, mint, burn, batch mint, batch burn, transfer, recovery, and regression-test evidence for the deployed token implementation | The evidence pack shows supply and holder balances after representative mint, burn, batch, transfer, and recovery paths |
| Mint and burn operations never create or destroy tokens outside authorised parameters | Supply-management role mapping, approved instruction evidence, mint and burn function inventory, rejected-call tests, and post-transaction reconciliation | Only the authorised supply-management role can execute mint or burn, and each accepted operation matches an approved amount |
| Every token-transfer path executes the restriction check before token-state completion | Compliance-engine wiring, transfer-path inventory, rejected compliance tests, configured module list, and failed-execution behavior | Each user transfer, forced transfer, mint-like issuance path, or burn-like redemption path is either checked, explicitly exempted, or separately governed |
That distinction 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:
- 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.
- 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.
- Deployment and evidence responsibilities: share full audit reports, remediation work papers, retest evidence, restricted source packages, environment 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 environment audit packs.
- Documentation link: point reviewers to the source-verification overview 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:
| Review question | Evidence to collect | Acceptance check |
|---|---|---|
| Who performed the review? | Independent audit report or contractual security evidence that names the reviewer, review date, and independence basis | The reviewer can see that the audit was not performed by the implementation team |
| What was in scope? | Contract list, compiler settings, network, release identifier, deployment manifest, and source package or repository tag | The audited scope matches the deployed contracts, not only an unrelated source snapshot |
| Which findings were raised? | Severity counts for Critical, High, Medium, Low, Informational, and accepted-risk findings | The pack shows both open findings and accepted residual risks |
| What was remediated? | Remediation notes for each Critical and High finding, linked to the affected contract or control | Every Critical and High finding has a fixed, mitigated, accepted, or out-of-scope disposition |
| Was the fix retested? | Retest confirmation, follow-up report, or regression evidence after the remediation | The reviewer can distinguish an asserted fix from a verified fix |
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.
Read next
- Deployment evidence for the deployment record that anchors audit-scope claims.
- Bytecode verification for the source-vs-runtime check.
- Upgrade history for proxy and post-upgrade evidence.
- Source verification overview
Upgrade history
How auditors trace DALP contract provenance, upgrade authorisation, proxy patterns, directory pointers, and timelock or cancellation controls for the deployed environment.
Security overview
DALP security separates identity, access, wallet verification, on-chain compliance, and custody controls so reviewers can see which gate owns each asset-operation decision.