Trace the authority behind an upgrade delay
Suppose a protocol is described as delaying administrative changes. Its ordinary configuration function enforces that delay, but a separate upgrade role can immediately replace the implementation. Tests of the configuration function pass because the delay works there. They do not establish the broader claim, since the upgrade route can change the behavior without using that function.
Trace every route that can change the relevant behavior, including role changes and implementation upgrades. The response might constrain the upgrade route, narrow the stated promise or explicitly accept the authority it provides. Calling one component a timelock cannot establish what the unexamined administrative paths do.
State the invariant and the assumptions it requires
Write the expected invariant in a form that can be checked across the states under test. Record the assumptions it requires, including deployment, custody and external conditions. This lets another reviewer determine whether a result still applies when one of those conditions changes.
| Boundary | Example question | Evidence |
|---|---|---|
| Deployed code | Does the reviewed build correspond to the intended deployed implementation? | Identify the chain and address, retain compiler settings and compare bytecode. |
| Asset movement | Under the specified conditions, are assets moved only through authorized paths? | Check the defined invariants across the relevant state transitions. |
| Administrative authority | Which identities can change roles, pause operation or replace the implementation? | Record the complete role graph and effective permissions. |
| Custody | How is signing authority created, recovered and revoked? | Compare the key-management procedure with a scoped exercise. |
| External dependencies | What behavior follows when an oracle, bridge or service is stale or unavailable? | Retain the dependency assumptions and the observed failure-case results. |
Test sequences against the deployed configuration
For the delay example, reproduce the deployed configuration in an appropriate isolated environment. Enumerate privileged accounts and contracts, then check the delay through each authorized change path. Include role transfer, emergency operations and changes to the delay itself. Those operations can affect whether the stated constraint continues to apply.
A single function call exercises only part of the behavior. Controlled tests can vary boundary values, reorder or repeat operations and supply unexpected external responses. State-based testing can examine how operations interact over time. Keep the generated cases, properties checked and reproductions of failures, so reviewers can assess the actual coverage without assuming every reachable state was tested.
Tie the results to source and dependency revisions, deployment parameters and the test environment. A later deployment may change the assumptions behind them. Retest the affected properties after consequential upgrades or authority changes instead of treating the old results as permanent.
Separate the conclusions supported by each kind of evidence
OWASP's Smart Contract Top 10 organizes common risks. Completing its categories does not establish economic soundness or complete protocol security. Keep the findings about contract logic, custody, governance and external dependencies identifiable. A successful result in one area leaves the others to be examined.
Cryptographic protocols, bridges, consensus assumptions and economic mechanisms may require specialist review. State any exclusions and explain how they limit the conclusion. A scoped technical review does not determine investment value or financial suitability, and it cannot establish resistance to every possible composition with other contracts.