Blockchain & smart contracts
On-chain is not the same as correct.
A transaction can execute exactly as encoded and still be unauthorized, economically unsafe, inconsistent with source, dependent on a compromised oracle, or governed by an authority path the user never understood. DDCAL treats blockchain evidence as technical evidence—not automatic proof of correctness or trustworthiness.
Core boundary: On-chain ≠ correct. Immutable ≠ trustworthy. Transaction executed ≠ transaction authorized. Contract passed a scanner ≠ contract is safe.
Assessment areas
What DDCAL can examine.
Blockchain work is scoped around the exact deployed state, source, authority topology, dependencies, and technical claim under review.
Smart-contract security
Static and bounded adversarial review of Solidity/EVM code, invariants, access control, unsafe external interaction, upgrade assumptions, accounting logic, and failure paths.
Deployed contract vs source
Bind the assessment to the actual chain, address, bytecode, implementation and verified source rather than assuming a repository represents what is deployed.
Upgradeable proxies & admin control
Map proxy/implementation topology, upgrade authority, privileged roles, timelocks, pause controls and other paths capable of changing effective system behaviour.
Protocol and economic invariants
Challenge accounting, collateral, liquidation, pricing, slippage, fee, settlement, state-transition and other protocol-level assumptions inside the agreed technical scope.
Bridges, oracles & multisigs
Evaluate trust boundaries created by external price feeds, bridge contracts, validator or signer sets, relayers, multisig thresholds and administrative dependencies.
Historical transaction investigation
Reconstruct bounded transaction sequences, contract states, call relationships and evidence for a defined technical question or incident.
Treasury & wallet controls
Review multisig design, role separation, approval paths, transaction policy, settlement controls and observable authority boundaries without taking custody of funds.
Proof-of-reserves mechanics
Evaluate the cryptographic and on-chain mechanics of a bounded proof-of-reserves claim. This does not become a financial-statement audit or proof of undisclosed liabilities.
Blockchain and node software
Assess consensus-adjacent configuration, node software, protocol implementation, release controls, signing/authority paths and supporting infrastructure within an explicit technical boundary.
Target binding
The exact chain state is part of the evidence.
A meaningful blockchain assessment has to identify what was actually inspected.
Chain + block identity
Network, chain ID, relevant block identity or bounded block range, and the observation time are recorded where material.
Address + bytecode
Contract address, deployed bytecode hash, verified source identity and exact implementation are bound to the result.
Proxy, admin & dependencies
Proxy/implementation relationships, admin addresses, privileged roles, oracle addresses, bridge dependencies and other material authorities are recorded when in scope.
State transition rule: a material contract upgrade or implementation change creates a new target state. A report for the predecessor deployment does not automatically apply to the successor.
Planned bounded profiles
Different claims require different authority.
DDCAL keeps blockchain assessment capability separated rather than treating every contract review as the same job.
Smart Contract Static
ddcal.smartcontract.static.v1
Public Solidity/EVM source or repository. Static/read-only analysis only. No signing, deployment, funds, private keys or privileged chain interaction.
On-Chain Contract Assurance
ddcal.smartcontract.onchain.v1
Read-only inspection of deployed identity, state, bytecode/source relationship, authority topology, proxy structure and material dependencies.
Full Bounded Contract Assurance
ddcal.smartcontract.full.v1
Deployed identity + source + authority topology + bounded static/dynamic/adversarial analysis with independent verification and explicit release acceptance.
Additional bounded profiles can cover transaction forensics, multisig/treasury controls, oracle/bridge systems and protocol/node software without merging their authority into the smart-contract profiles.
Safety boundary
Inspection begins read-only.
DDCAL does not require private keys, wallet seed phrases, custody of funds, signing authority or arbitrary RPC administrative credentials for normal blockchain assurance. Effectful testing, if ever required, must be separately authorized and isolated from production assets.
Claim boundary
Technical assurance is not a financial audit.
DDCAL can assess technical and cryptographic evidence within a defined scope. It does not turn an on-chain result into a financial-statement audit, legal opinion, regulatory approval, certification or guarantee of future economic performance.
Request a blockchain assessment
Bind the chain, contract and question first.
For an initial inquiry, identify the network, contract or protocol, relevant address or public repository, exact claim or concern, and whether the target is public or private. Do not send private keys, seed phrases, credentials or confidential evidence through ordinary email.