Upgrade history
How auditors trace DALP contract provenance, upgrade authorisation, proxy patterns, directory pointers, and timelock or cancellation controls for the deployed environment.
DALP uses upgradeable EVM patterns in parts of the contract system. Upgrade evidence should include the authorisation path, not only the new implementation address. This page covers the provenance evidence an auditor reviews for upgrades, the proxy patterns DALP uses, the directory pointers that select implementations, and the timelock or cancellation controls.
For source-vs-runtime verification, see Bytecode verification. For the overall review flow, see Source verification and auditability overview.
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? |
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
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.
A complete timelock answer should separate DALP's built-in authorisation controls from environment-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. |
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.
Upgradeability governance answer
| 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
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.
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 evidence | 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.
Read next
- Deployment evidence for the deployment-record evidence that anchors upgrade history.
- Bytecode verification for the source-vs-runtime check and post-upgrade bytecode comparison.
- Audit evidence for the audit-report attestation tied to the deployed scope.
- Source verification overview
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.
Audit evidence
How to answer vulnerability-control, formal-verification, and smart-contract audit evidence requests with DALP's deployed-scope evidence pack.