Define assets and forbidden states
Document the data, tokens, rights or monetary limits controlled by the contract. For every function identify the caller, preconditions, state change, external calls and expected result. Write invariants explicitly: balances cannot become negative, issuance cannot exceed its cap, and a closed object cannot reopen outside an approved procedure.
The threat model must include an anonymous attacker, a compromised administrator key, a bad oracle, an unavailable dependency, an unsafe upgrade and a legitimate user invoking valid functions in an unexpected order.
Bound administrative authority
Review the roles that mint, pause, upgrade, change parameters and transfer assets. Critical operations should not depend on one personal key. Separate duties and use multi-party approval, time delays and limits where the risk justifies them.
Document the complete key lifecycle: generation, custody, backup, rotation, revocation and compromise recovery. A service key stored in an application environment variable is not an adequate control model for irreversible high-value actions.
Review logic and interactions
Validate addresses, ranges, repeated requests, zero values and boundary states. Treat every external call as potentially failing, consuming unexpected gas, changing behavior or calling back before your operation is complete. Check conditions first, update internal state second, and interact with external contracts last.
An oracle belongs to the trusted computing base. Define sources, maximum data age, aggregation, deviation limits, fallback channels and safe behavior when updates stop. Data is not true merely because it has been written onchain.
Use multiple assurance layers
The baseline includes unit and integration tests, negative cases, authorization tests and a reproducible build. Add property-based tests, fuzzing, static analysis and invariant checks for critical logic. Formal verification can protect a small, high-impact core, but it does not replace integration and operational testing.
An independent audit should examine a frozen revision. Fixes require a focused re-review and full regression run. Source code, compiler version, build settings and deployed bytecode must remain comparable and verifiable.
Prepare a controlled release
Rehearse deployment in a test environment with the same pipeline used for production. Verify dependency addresses, role holders, initial parameters, limits and the order in which control is transferred. Preserve the commit hash, build artifacts, contract address and approval record.
An upgrade mechanism is itself a privileged path. For proxies or state migrations, test storage compatibility, upgrade authorization and recovery. If the contract is immutable, design replacement and migration before launch rather than after an incident.
Monitoring and emergency operation are mandatory
Emit events for critical changes and monitor unusual amounts, frequency, failures, role changes and administrative calls. Every alert needs an action: who decides, how exposure is limited, whether operations can pause and how participants are informed.
Run tabletop exercises for key compromise, a corrupted oracle update and a vulnerability discovered after release. A pause function is not useful if its key is unavailable or the team has never defined when to use it.
Final release gate
- requirements and invariants are approved by the process owner;
- roles and keys follow least privilege;
- external calls and oracles fail safely;
- tests, analysis and independent audit match the release revision;
- source code and deployed bytecode are verifiable;
- monitoring, pause, upgrade and response procedures have been exercised;
- accountable owners have accepted the residual risk in writing.
If a critical item cannot be demonstrated with evidence, stop the release instead of promising to inspect it after deployment.