Smart contract certification: what an audit demonstrates

Smart contracts execute the rules of a blockchain application, from transfers to permissions over an asset. Before those rules are used in a product, the team needs to check that the code behaves as intended. Audits and other technical reviews provide evidence for that work.

Certification can refer to services and documents with different scopes. Understanding what a review establishes requires knowing which version was examined, which tests were performed and which fixes were verified. Those details make it possible to interpret the report without treating it as a general security guarantee.

Does certification mean the same as an audit?

Blockchain projects sometimes use “certification” to describe an audit report. Ask what the term covers: a code review is not, by itself, regulatory approval or a guarantee that a system has no vulnerabilities. Where a certification scheme applies, identify the issuing organisation, standard, assessed version and conditions.

An audit examines a particular software version and records findings and limitations. Its value lies in that evidence and in how identified problems are addressed. A badge without a report, date or code reference gives readers little to verify.

What should a smart contract audit cover?

Start with the product rules: who can issue, transfer, withdraw or freeze assets; which properties must hold after each operation; and what happens when a dependency stops responding. Review the implementation against that specification.

• Access control: roles, administrators and upgrade permissions.
• External interactions: reentrancy, oracles, third-party tokens and failing calls.
• Accounting: rounding, limits, balances and settlement conditions.
• Operations: deployment configuration, key custody and incident response.

The Solidity security considerations describe risks including reentrancy and gas limits. They inform testing, but a checklist of known flaws cannot replace analysis of the product's business logic.

Immutability and upgradeable contracts

Code deployed at an address cannot be edited like a server file. An application can nevertheless use a proxy that delegates to another implementation, or expose pause and administration functions. Ethereum's upgrading guide describes these patterns and their trade-offs.

Two questions therefore matter: whether the examined code has defects and whether someone can later change the system's behaviour. Reviewing only an implementation while excluding the proxy, permissions or governance process leaves a significant part of the risk unexamined.

What to request from an auditor

Ask for a report tied to a repository commit and reproducible compiler configuration. It should identify scope, exclusions, methods, finding severity and remediation status. Then check that the deployment matches the reviewed version.

Unit tests, fuzzing and invariant checks provide complementary evidence. Independent review can challenge assumptions that the implementation team has not questioned. No single technique covers every economic, operational or integration error.

Reading a finding and its remediation

For a hypothetical example, a report may identify that an operational account can also replace the administrator. The finding should explain the enabling condition, impact and affected code. Severity depends on context: a test-network function is not equivalent to an active permission in a contract holding funds.

After remediation, review the change and verify that deployment configuration assigns the intended roles. Removing permission from one function may leave the risk intact if another account can grant it again. Closure evidence needs to cover the identified scenario.

“Accepted” does not mean “resolved” either. It may mean the team acknowledges a risk and chooses to retain it. Readers need to understand that decision, its mitigations and who takes responsibility. Comparing providers by finding counts or the absence of critical issues without considering scope and version can be misleading.

A useful deliverable connects findings to responses, subsequent review and deployed code. This makes it possible to decide which changes need reassessment and prevents an old report from being used to endorse a different version.

What code cannot establish

A contract can record a payment or a right stated by an issuer; it does not automatically transfer legal ownership of a car or property. Documentation, applicable registries and the parties' obligations remain part of the product. An oracle also does not automatically establish that an incoming fact is true.

Before launch, resolve findings, rehearse recovery and incident handling, and assign monitoring responsibilities. Material later changes require another review of the affected scope. At Metlabs, smart contract development includes permissions, integrations and operations, so the assessment covers the system that will actually reach production.