# Smart contract source verification and deployment auditability
Source: https://docs.settlemint.com/docs/architecture/security/source-verification-auditability
How DALP makes deployed EVM contract systems reviewable through recorded deployment addresses, bytecode checks, migration verification, timelock boundaries, formal-assurance boundaries, upgrade evidence, and operational audit trails.
DALP contract auditability connects the addresses running on an EVM network to the expected DALP contract system and to the state transitions operators see in the platform. DALP supports that review through deployment records, bytecode presence checks, post-migration verification, upgrade evidence, indexed events, and off-chain workflow records.
## Who this is for [#who-this-is-for]
| Reader | Decision this page supports |
| -------------------- | ---------------------------------------------------------------------------------------- |
| Technology architect | Decide which deployment evidence to collect before accepting a DALP environment |
| Security auditor | Check whether deployed contracts, addresses, roles, and migration state can be inspected |
| Operator | Understand which evidence belongs in an environment evidence pack |
| Integration lead | Know where on-chain evidence ends and where platform workflow evidence begins |
The evidence model has a clear limit: block explorers, address manifests, bytecode checks, migration reads, and indexed events support technical review, but they do not replace a formal smart contract audit, customer approval record, or contractual assurance process. Treat the page as an explanation of what evidence exists and who controls each artifact, not as a substitute for the environment's security review.
Use this page with the [security overview](/docs/architecture/security), [transaction signing flow](/docs/architecture/flows/signing-flow), and [operability model](/docs/architecture/operability) when you assemble an environment review pack.
## Auditability schematic [#auditability-schematic]
The schematic separates the review surfaces that can otherwise get blended together in an evidence pack. Deployment records tell auditors what to expect, RPC reads show what exists on the selected chain, verification reads test DALP wiring, indexed events connect accepted work back to submitted transactions, and the environment evidence pack preserves the result.
## Evidence model [#evidence-model]
A DALP deployment has four evidence layers.
| Evidence layer | What it proves | Where it is checked or read |
| -------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Deployment record | Which DALP modules were deployed for the environment and which addresses exist | The deployment address manifest created by the deployment process |
| Deployed bytecode | The recorded addresses contain EVM bytecode on the selected network | RPC bytecode reads against the configured network |
| System wiring | Core system, directory, registry, compliance, and token links are coherent | Post-deployment or post-migration verification reads from the contracts |
| Operational state evidence | The platform view matches accepted, queued, signed, submitted, and indexed work | Execution records, transaction status, chain events, indexer reads, logs |
These layers answer different questions. A recorded address is not enough on its own. A non-empty bytecode response proves that code exists at an address, but it does not prove the whole system is wired correctly. Wiring checks prove the expected DALP relationships are present. Operational evidence shows how a business action moved through the platform and onto the chain.
## Review flow [#review-flow]
The review flow turns the schematic into a practical checklist. Review the evidence in this order so each check narrows the next one:
1. Start with the deployment record. Confirm the network, chain identifier, directory, system factory, and supporting addresses expected for the environment.
2. Read bytecode at the recorded core addresses. An `eth_getCode` response of `0x` means no code is deployed at that address on the selected network, so the address record cannot be trusted until the environment is repaired or redeployed.
3. Run post-deployment or post-migration verification. These checks read contract state, migration version, registry links, interface support, and token readability instead of trusting the manifest alone.
4. Compare upgrade and administrator authority. Review owner, administrator, system-manager, and custody-policy records for accounts that can administer or upgrade contracts.
5. Reconcile a sample business action. Match the platform request, workflow status, transaction hash, indexed event, and final platform read for the same action.
This flow keeps source verification, runtime checks, and operator approval evidence separate. It also gives auditors a stable way to explain a failure: wrong address record, missing bytecode, failed wiring check, unclear authority, or an operational action that cannot be reconciled end to end.
### Review checklist and next links [#review-checklist-and-next-links]
| Step | Pass signal | Failure signal | Next page to read |
| --------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Deployment record | The manifest names the expected network, chain identifier, modules, and addresses | The manifest is missing, names the wrong network, or cannot be tied to the accepted release | [Architecture overview](/docs/architecture/overview) |
| Bytecode presence | Required addresses return non-empty EVM bytecode | A required address returns `0x` or the RPC read targets the wrong network | [Security overview](/docs/architecture/security) |
| Post-migration verification | Version, registry, interface, and token-readability checks pass | The directory, registry, interface support, or migration version does not match the environment | [Operability model](/docs/architecture/operability) |
| Authority review | Owner, administrator, system-manager, and custody-policy records are archived | An upgrade path exists without a matching approval or key-owner record | [Transaction signing flow](/docs/architecture/flows/signing-flow) |
| Action reconciliation | Request, workflow status, transaction hash, event, and platform read agree | The platform state cannot be traced to the submitted transaction or indexed event | [High availability](/docs/architecture/self-hosting/high-availability) |
## Deployment address trace [#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 [#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.
Preserve these controls with the deployment evidence pack:
| 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 boundary. 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. For evaluator responses, link to `https://docs.settlemint.com/docs/architecture/security/source-verification-auditability`, then provide the customer-specific approval and evidence pack through the agreed review channel.
## Source verification versus runtime verification [#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-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 [#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:
1. 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.
2. 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.
3. Deployment and evidence boundary: 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.
4. Documentation link: point reviewers to `https://docs.settlemint.com/docs/architecture/security/source-verification-auditability`, 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.
## Smart contract provenance and upgrade auditability [#smart-contract-provenance-and-upgrade-auditability]
An auditor should be able to trace both the deployed contract and the authority that can change it.
| Topic | Evidence to collect | Review question it answers |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Audit report availability | Current smart contract audit report, remediation summary, or contractual security evidence channel | Has the relevant contract set been reviewed, and where can the report be requested? |
| Version pinning | Release identifier, deployment manifest, explorer links, and migration verification output | Which contract version is accepted for this environment? |
| Upgrade authorization | Upgrade transaction, governance or approval record, and role state for the account that executed it | Who approved the upgrade, and did the authorized account execute it? |
| Owner and administrator keys | Current owner address, access-control administrator roles, system-manager role holders, and custody policy | Which keys can administer or upgrade contracts, and how are they controlled? |
| Post-upgrade verification | Storage-layout review where applicable, post-migration checks, version reads, and sample transaction reconciliation | Did the upgraded system keep the expected state and runtime behavior? |
DALP uses upgradeable EVM patterns in parts of the contract system. Upgrade evidence should therefore include the authorization path, not only the new implementation address. If the operator changes owner or administrator keys, archive the before-and-after role state with the same care as the deployment manifest.
## Timelock and governance-attack controls [#timelock-and-governance-attack-controls]
DALP does not apply a platform-wide on-chain timelock or minimum delay duration to high-consequence governance actions by default. The default minimum delay for the operation types in this section is therefore `0 seconds` unless the deployed environment adds a delay through an external governance contract, custody workflow, smart-wallet policy, or operating procedure. DALP also does not grant the bank a universal independent cancellation right after a privileged transaction is signed or broadcast. Cancellation authority exists only where the selected approval, custody, smart-wallet, or external governance route enforces it before execution.
High-consequence actions are controlled first by role-gated EVM functions and the custody, proxy-administration, or smart-wallet approval policy configured for the environment. DALP API paths that submit privileged role and asset operations also use wallet selection and transaction-queue execution. If a customer requires a mandatory delay window or bank cancellation right, the evidence pack must identify the environment-specific control that enforces it.
Use this order when an evaluator asks about timelocks and governance attack prevention:
1. Direct answer: state the minimum delay for the reviewed environment for each operation type. If the environment uses DALP defaults, the delay is `0 seconds` and there is no DALP-enforced timelock. Do not answer "yes" unless the evidence pack names the delay, authority, and enforcement point.
2. DALP mechanism: map the operation to its privileged path. System role grants and revocations require an administrator path. Asset role grants and revocations require the token administrator path. Supply-cap changes require the asset Governance role. System migrations and upgrades require the authorised system-management or proxy-administration path for the deployed environment. These actions then follow the selected signing, custody, or smart-wallet approval route before a transaction can be broadcast.
3. Deployment and evidence boundary: attach the deployed role-holder reads, approval-policy configuration, queue or signing evidence, transaction hash, before-and-after role or implementation reads, and any customer-specific approval record. If the bank has an independent cancellation right, show where that right is enforced before execution, for example in the smart-wallet approval threshold, custody approval workflow, or external governance process.
4. Documentation link: point reviewers to `https://docs.settlemint.com/docs/architecture/security/source-verification-auditability`, then provide the actual environment evidence pack through the agreed evidence channel.
A complete timelock answer should separate DALP's built-in authorization controls from customer-specific delay controls:
| Operation type | Built-in DALP control | Default minimum delay and enforcement | Cancellation authority and bank right |
| ----------------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Smart contract upgrade or migration | Authorised upgrade or migration caller, deployment record, implementation reads | `0 seconds`; no DALP platform-wide timelock. Any mandatory delay must come from the deployed approval, custody, smart-wallet, or governance route. | No universal DALP cancellation right after signature or broadcast. A bank cancellation right exists only if the environment's approval route can stop the action before execution. |
| Supply-cap change | Asset Governance role, wallet verification, transaction queue, and capped-token checks | `0 seconds`; the EVM cap change is role-gated, not timelock-gated by DALP. Any delay is environment-specific. | The Governance role holder or configured approver can withhold or cancel only where the selected queue, custody, or smart-wallet policy supports that step before signing or submission. |
| System role reassignment | Administrator role path, wallet verification, transaction queue, and role events | `0 seconds`; administrator actions are role-gated unless an external delay control is configured. | The configured administrator, custody approver, smart-wallet signer, or external governance process defines who can stop the pending action before execution. |
| Asset role reassignment | Token administrator path, wallet verification, transaction queue, and role events | `0 seconds`; token-administrator actions are role-gated unless an external delay control is configured. | The token administrator path and configured approval route define cancellation before execution; DALP does not add a separate bank-wide cancellation power. |
The attack-prevention boundary is important. DALP can enforce role separation, reject callers without the required role, preserve queued execution and signing evidence, and expose the resulting transaction and role state for audit. DALP's public contract layer should not be described as providing a universal minimum timelock or bank cancellation right unless the deployed environment actually routes those operations through a control that enforces that delay or cancellation authority. If a privileged credential is compromised and can satisfy the configured approval route immediately, the mitigation is the environment's key custody, approval threshold, monitoring, and emergency-revocation process, not an implicit DALP timelock.
## 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, 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:
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 boundary: 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.
4. Documentation link: point reviewers to `https://docs.settlemint.com/docs/architecture/security/source-verification-auditability` 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 [#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 boundary 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:
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 boundary: 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.
4. Documentation link: point reviewers to `https://docs.settlemint.com/docs/architecture/security/source-verification-auditability`, 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 |
The boundary 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 [#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:
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 boundary: share full audit reports, remediation work papers, retest evidence, restricted source packages, customer-specific 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 customer-specific audit packs.
4. Documentation link: point reviewers to `https://docs.settlemint.com/docs/architecture/security/source-verification-auditability` 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.
### Upgradeability governance answer [#upgradeability-governance-answer]
For governance review, answer the upgradeability question in this order:
| Question | DALP answer | Evidence to preserve |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Are token and system contracts immutable or upgradeable? | DALP uses upgradeable EVM contracts for system upgrades and for asset infrastructure that is deployed through upgradeable factories. Asset token addresses remain stable when their factory and token implementations are reconciled. Immutable contracts, when present, are remediated by replacement and governed migration rather than by changing the old implementation. | Contract address list, token samples, implementation pointers, and immutable-contract transition record |
| Which proxy pattern is used? | The system upgrade path uses an ERC-1967 implementation slot with a UUPS implementation and calls `upgradeToAndCall` when the implementation differs from the active directory. Asset tokens use factory-directed proxies that delegate to the token implementation selected by their asset factory. The system upgrade workflow does not use Transparent Proxy, Beacon, or Diamond EIP-2535. | ERC-1967 implementation slot read, proxy upgrade transaction, selected implementation address, factory token implementation read, and token address sample |
| Who can authorise an upgrade? | The exact authority address is environment-specific. For the system proxy, preserve the address that holds `SYSTEM_MANAGER_ROLE`. For directory implementation changes, preserve the directory administrator role holder. For access manager upgrades, preserve the `DEFAULT_ADMIN_ROLE` or `SYSTEM_MANAGER_ROLE` holder that executed the change. | Role reads before and after the upgrade, custody approval, signer record, and transaction sender |
| Is there a mandatory timelock? | DALP does not add a mandatory on-chain timelock to the system upgrade workflow. Environments that require a delay must enforce it in their governance or custody control before the authorised role holder submits the transaction. | Governance approval record, custody-policy evidence, or timelocked-account record when the environment uses one |
| How is storage layout compatibility validated? | The compatibility review compares ABI and storage layout for upgradeable contracts and treats removed functions, selector changes, storage reordering, removed storage, unsafe type changes, and unsafe appended storage as breaking findings before implementation acceptance. | Storage-layout and ABI compatibility report, release approval, and post-migration verification output |
| What is the rollback procedure? | Completed on-chain upgrade steps are not automatically rolled back. Stop the run, preserve failed-step evidence, compare pre-upgrade and post-upgrade investor state, restore by governed corrective action when safe, or move to replacement contracts and a governed investor-state migration when the old contract cannot be safely used. DALP does not automatically rewind chain state after a submitted upgrade transaction completes. | Failed transaction, workflow state, investor-state comparison, corrective transaction, or replacement-contract migration pack |
### Proxy upgrade and directory review [#proxy-upgrade-and-directory-review]
DALP uses upgradeable proxy patterns for system and asset-token components where the deployed environment supports upgrades. System upgrades use UUPS-compatible implementations through the ERC-1967 implementation slot. Asset tokens keep the same token address because the token proxy continues to route through the factory-selected implementation.
The upgrade authority is not a single DALP-wide public address. It is the exact wallet or contract address that holds the required role in the deployed environment. A system proxy upgrade must be executed by a system manager. A directory implementation update must be executed by a directory administrator. The evidence pack should name the executing address, the role that authorised it, and the approval or custody record for that action.
DALP does not add a protocol-level mandatory timelock to system or token implementation changes. If the environment's governance model requires a waiting period, the operator enforces that delay before the authorised transaction is submitted and preserves the delay evidence with the authorization record.
Review storage compatibility before a new implementation address becomes active. For upgradeable implementations, preserve OpenZeppelin upgrade validation output or an equivalent compiler storage-layout comparison. For immutable or frozen contracts, preserve the ABI and storage-layout baseline review that shows whether replacement deployment is required instead of in-place patching.
For system upgrades, review the proxy, directory, and migration evidence together. The upgrade workflow reads the expected `SYSTEM` implementation from the active directory. The workflow submits the proxy upgrade when the ERC-1967 slot differs, then runs the system migration with the active directory address. When the migration call reaches a contract that is already at the expected version, the contract reverts with its reinitializer guard and the workflow treats that already-migrated response as complete.
The directory is the source of implementation pointers for the active network. Directory upgrade evidence should show which implementations were registered before the system upgrade used them. The evidence includes registry implementations, identity factory implementation, token factories, add-ons, compliance modules, and chain-of-trust registries. A system upgrade audit pack is incomplete if the pack records only the final system address and omits the directory pointers that selected the implementation set.
Review migration sequencing as part of storage and state continuity. The compliance module registry migrates before system compliance because system compliance migration reads the registry's type-based module records. Asset token addresses remain stable during factory and token implementation reconciliation, so the audit pack should preserve the same token addresses before and after the upgrade, then attach the post-migration wiring checks.
| Review item | Evidence to preserve | Failure signal |
| --------------------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| System proxy pattern | UUPS-compatible implementation, ERC-1967 slot reads, and selected implementation address | The proxy pattern or implementation slot cannot be verified |
| Upgrade authority | Executing wallet, system-manager or directory-admin role, and approval or custody record | The transaction sender has no matching role evidence |
| Timelock boundary | Required external waiting-period evidence, or an explicit record that the environment has none | A required waiting period is claimed but not evidenced |
| Storage-layout validation | OpenZeppelin validation or equivalent storage-layout comparison before the implementation is used | A new implementation is registered without compatibility evidence |
| Directory pointer selection | Directory `SYSTEM` implementation and related registry or factory implementation pointers | The proxy changed to an address that cannot be tied to the active directory |
| Migration version | Pre-upgrade and post-upgrade migration version reads | Version remains behind after the migration step completes |
| Sequencing | Completed registry and compliance migration evidence | System compliance migration runs without the registry records it depends on |
| Token continuity | Token address, identity, role, balance, and compliance attachment samples before and after the run | A token address changes when the intended path was a factory or implementation reconciliation |
| Rollback or remediation | Previous approved implementation, failed step, incident record, replacement-contract plan, if used | Investor state changes are handled without a governed remediation record |
Rollback depends on the failure mode. If the new implementation is wrong but state remains readable, the operator can register the previously approved implementation, run the guided upgrade workflow again, and repeat post-migration checks. If investor state is corrupted or cannot be read safely, preserve the affected state, stop further operations through the environment's incident process, and move to replacement contracts and governed balance movement where required. The old token address and event history remain part of the audit record.
## What to include in an audit pack [#what-to-include-in-an-audit-pack]
For a production environment, collect the evidence in the order an auditor needs it:
1. Network and chain identifier for the environment.
2. Deployment address manifest for the DALP system and supporting contracts.
3. Explorer source verification links where the selected network and explorer support them.
4. Bytecode presence check for required contract addresses, including the chain ID and time the check was recorded.
5. Version pinning evidence for the deployed release or customer-controlled source package.
6. Complete independent security audit report for every token contract in scope, or the approved evidence channel that provides those reports for the environment.
7. Audit scope statement covering contracts, source package, compiler settings, proxy or implementation addresses, and deployment inputs.
8. Finding counts by severity, including Critical, High, Medium, Low, Informational, and accepted-risk findings.
9. Remediation notes and retest confirmation for every Critical and High finding.
10. Post-deployment or post-migration verification output for system wiring and migration version.
11. Upgrade authorization records for any post-deployment contract changes.
12. Owner, administrator, and system-manager role state for contracts that can be administered or upgraded.
13. Transaction samples showing request acceptance, durable execution status, chain transaction hash, indexed events, and final platform reads.
14. Operator ownership notes for custody policy, RPC provider or node operation, backup retention, and incident response.
Keep customer-specific keys, credentials, tenant identifiers, and private operational logs out of public documentation and shared screenshots. Keep proprietary source packages, full audit reports, and remediation work papers in the agreed review channel when they are not public or customer-controlled. Share sensitive evidence only through the approved channel for that environment.
## Related architecture pages [#related-architecture-pages]
Contract source and deployment evidence sit between architecture review and operations review. Use these pages as the next reading path:
* [Architecture overview](/docs/architecture/overview) explains the DALP layers and ownership split.
* [Security overview](/docs/architecture/security) explains the identity, access, compliance, and custody control model.
* [Transaction signing flow](/docs/architecture/flows/signing-flow) shows how transactions move from a platform request to an EVM submission.
* [Operability model](/docs/architecture/operability) explains telemetry, persistence, and failure recovery.
* [High availability](/docs/architecture/self-hosting/high-availability) explains resilience patterns without turning them into SLA commitments.
## Responsibility split [#responsibility-split]
| Area | DALP provides | Operator provides |
| ---------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Contract deployment process | Deployment modules, address records, and verification scripts | Environment approval, selected network, and release evidence retention |
| Runtime bytecode checks | RPC checks that required contract addresses contain bytecode | Network access, check evidence capture, and remediation when addresses are stale or unreachable |
| Migration verification | Contract reads that check version, registry, implementation, and token state | Decision to run and archive verification output for the environment |
| Explorer source verification | Source and compiler configuration needed for verification when available | Explorer publishing workflow where the network supports it |
| Proprietary source access | Public ABI, deployed address, version, audit availability, and agreed review material | Approval process for receiving restricted source or audit material |
| Upgrade governance | Upgradeable contract controls and role-readable authorization state | Approval records, custody controls, and key-owner records |
| Operational audit trail | Workflow state, transaction status, indexed events, and API-visible reads | External audit-pack assembly, legal sign-off, and policy documentation |
The practical rule is straightforward: use DALP evidence to prove what the platform deployed and executed, then attach the operator-owned approvals and policies that explain why those actions were allowed.