# Audit evidence

Source: https://docs.settlemint.com/docs/compliance-security/source-verification/audit-evidence
How to answer vulnerability-control, formal-verification, and smart-contract audit evidence requests with DALP's deployed-scope evidence pack.



Auditors and security evaluators ask DALP operators three distinct questions: how the platform controls vulnerabilities, whether smart contracts are formally verified, and which audit reports cover the deployed scope. Each section gives the response order and the records your operators preserve for the environment's audit pack.

For the deployment evidence that anchors these answers, see [Deployment evidence](/docs/compliance-security/source-verification/deployment-evidence). For the overall review flow, see [Source verification and auditability overview](/docs/compliance-security/source-verification/overview).

## How to answer a vulnerability-control request [#how-to-answer-a-vulnerability-control-request]

For reentrancy, overflow-and-underflow, access-control, and formal-assurance questions, respond 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 operations. An evaluator still needs evidence tied to the exact deployed contracts, not a generic platform description.

Use this order when an evaluator asks you how the platform controls common smart contract vulnerability classes:

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 responsibilities: attach independent audit results, Slither-and-Aderyn static-analysis output from the contract review pipeline, remediation evidence, post-fix confirmation, role-holder reads, access-control rejection samples, and regression evidence for the deployed scope through the approved evidence channel.
4. Documentation link: point reviewers to the [source-verification overview](/docs/compliance-security/source-verification/overview) for the public verification model, then provide the actual environment evidence pack through the agreed evidence channel.

A complete vulnerability-control response lets the reviewer trace each claim to the deployed code path. The table matches each vulnerability class to the evidence your pack should contain.

| 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 test coverage           | 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 functions require the expected role |
| Static analysis        | Slither and Aderyn results, accepted issues, suppression rationale, remediation evidence, and retest evidence    | Access-control, reentrancy, arithmetic, and upgrade issues 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 response is evidence-based by design. Public docs explain the control model, but reviewers build their production confidence 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 [#how-to-answer-a-formal-assurance-request]

DALP does not claim formal verification of tokenization supply or transfer invariants as a default platform guarantee. Treat the formal-verification position as "not formally verified" unless your 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 rests on role-gated supply functions, SMART token compliance checks, deployment verification, independent audit evidence, static analysis, regression tests, and transaction reconciliation. These controls give strong implementation confidence for your review, but they are not a mathematical proof of the token invariants.

Use this order when an evaluator asks you 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 responsibilities: attach the environment-specific assurance pack. The pack should include the deployed contract list, compiler version, source or release package, independent audit report, and static-analysis results. Also include unit and regression coverage for mint, burn, batch operations, transfer rejection, and role rejection, plus any manual invariant review performed for the release.
4. Documentation link: point reviewers to the [source-verification overview](/docs/compliance-security/source-verification/overview), then provide the actual environment evidence pack through the agreed evidence channel.

A complete non-formal assurance response covers the evaluator's three requested invariants without overstating the proof level. The table confirms which invariants your pack must address and the acceptance check for each.

| 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 functions 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 call 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, independent audits, role tests, regression tests, deployment verification, and transaction reconciliation can give strong implementation confidence, but none of them equals a formal verification proof. If a customer requires that level of rigor for a production asset, include it in the customer evidence pack or state explicitly that the deployed scope is not formally verified.

## How to answer a smart contract audit evidence request [#how-to-answer-a-smart-contract-audit-evidence-request]

Respond with the environment evidence pack, not 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 you for smart contract audit reports, findings, and remediation records:

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 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.
4. Documentation link: point reviewers to the [source-verification overview](/docs/compliance-security/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 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 lets an auditor answer five questions. Verify that your pack covers each one:

| 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 your recorded deployment addresses. If the deployed bytecode, compiler settings, constructor or initializer arguments, proxy address, or the logic 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: the proxy or directory address that users interact with, and the logic address that contains the audited code. After each upgrade, archive the authorization record, the new logic address, storage-layout review where applicable, post-migration verification output, and a fresh sample transaction reconciliation.

## Read next [#read-next]

* [Deployment evidence](/docs/compliance-security/source-verification/deployment-evidence) for the deployment record that anchors audit-scope claims.
* [Bytecode verification](/docs/compliance-security/source-verification/bytecode-verification) for the source-vs-runtime check.
* [Upgrade history](/docs/compliance-security/source-verification/upgrade-history) for proxy and post-upgrade evidence.
* [Source verification overview](/docs/compliance-security/source-verification/overview)