Offensive Security

Smart Contract Audits

Line-by-line review of contract logic, accounting and upgrade paths against a frozen commit, with fuzzing and invariant tests, and the transaction sequence that triggers every finding.

A contract bug is not patched quietly after the fact. Once the code is deployed it is public, immutable and holding funds, so the review has to find the problem before the chain does. We read the code line by line against a frozen commit, then test the assumptions behind it: what the accounting does at the edges, who can change what, and what an external call can do on the way back in.

The audit is fixed to a commit hash before it starts, so we and you are reviewing the same code throughout. Manual review is the core of it. Static analysis, fuzzing and invariant tests run alongside to reach the states a person cannot enumerate by hand, but a person reasons about every finding, writes it up, and reviews the fix.

Usually, one of these is true

You are close to mainnet and need an independent review of the contracts before funds are deposited into them.
A protocol upgrade or a new module changes accounting or access control, and you want the change reviewed against the code already deployed.
An exchange, a launch partner or an investor is asking for a published audit report before they will list or fund the protocol.
The economic model has grown complex enough that you are no longer certain the accounting holds at the edges under adversarial use.

What we review

We agree the contracts in scope and a commit hash before the audit starts, and review that exact code. Anything outside it, including deployment configuration or off-chain components, is called out rather than assumed.

Logic and state. Every state transition traced by hand, including the ones only reachable through an unusual call order or a reentrant path back into the contract.
Accounting and economics. Token, reward, fee and interest maths checked at the edges: first depositor, last withdrawal, zero and dust balances, and maximum values.
Access and upgradeability. Ownership, role gates, pausing, proxy patterns, and what an upgrade can change about storage that is already written on-chain.
Oracles and external calls. Price manipulation, stale or spoofable data, reentrancy on the return path, and what happens when an external call reverts or fails silently.
Invariants and rounding. The properties that must always hold, expressed as invariants and fuzzed, and the precision loss that compounds across operations into something extractable.
Standards and integrations. Conformance to the token and interface standards other protocols will assume, and how the contracts behave against the ones they call and are called by.

How the audit runs

The audit is fixed to a commit hash. Findings reach your channel as they are confirmed, and a fix review against the same commit closes it out.

Freeze and scope. We agree the contracts in scope and a commit hash. The code is frozen at that commit for the duration; documentation, comments and tests may change, functional code does not.
Architecture and invariants. We read the specification and the code together, map the trust model and the accounting, and write down the invariants that must always hold.
Line-by-line review. We review every line by hand and build fuzzing and invariant harnesses to reach states a manual read cannot enumerate, developing exploit cases where a property breaks.
Findings. Each finding reaches your channel with the transaction sequence that triggers it, a CWE mapping and a severity reasoned from impact. Anything critical is reported within the hour.
Fix review. Once fixes land we review them against the original commit, confirm they close the issue without opening another, and issue a final report and attestation.

What you get

A reproducible proof for every finding. The transaction sequence or test that triggers each issue, runnable against the frozen commit, so the fix can be checked.
Severity reasoned from impact. Each finding rated on what it lets an attacker do and what it puts at risk, not slotted into a template, and mapped to CWE.
Remediation at the code level. Guidance written against the specific function and line, with the invariant it should preserve, for the engineers who wrote the contract.
Invariant and fuzzing harnesses. The properties we wrote and the harnesses that exercise them, handed over so your team can keep running them in CI.
A fix review and final report. A review of the fixes against the original commit and a final report you can publish, with each finding marked fixed, acknowledged or risk accepted.

What we need from you

The repository at a commit you are willing to freeze, with the contracts in scope named explicitly.
A specification or documentation of what the contracts are meant to do: the accounting, the roles, and the assumptions behind them.
The existing test suite and instructions to build, compile and run it, including any mainnet fork configuration.
A written list of known issues and areas you are already unsure about, so the time goes to new ground.
A developer who can answer questions about intended behaviour on the shared channel while the audit runs.

What we can show you

Research, not only testing. 70+ CVEs published by our researchers, and research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense, alongside engagements for security leads at DeFi protocols.
The auditor writes the report. The engineer who reads the contract writes the finding and reviews the fix. No account-manager layer, no junior bench, no hand-off to a report writer.
Findings as they are confirmed. Each finding reaches your channel with the transaction sequence that triggers it as soon as it is confirmed, and anything critical within the hour, not held for a PDF at the end.
Handled under NDA. Mutual NDA and PGP before you share code. Evidence stays encrypted, least-privilege and limited to the engineers on the engagement, and is destroyed after the retest on request.

Standards we work to

We structure the audit against the public smart contract security standards and weakness catalogues your reviewers and listing partners recognise.

OWASP Smart Contract Security Verification Standard (SCSVS)
OWASP Smart Contract Security Testing Guide (SCSTG)
EEA EthTrust Security Levels
SWC Registry
CWE
CVSS v4.0

Common questions

What do you need before the audit starts?

A repository at a commit you are willing to freeze, the contracts in scope named, a specification of what they are meant to do, and a working test suite we can build and run. A list of known issues helps too, so the time goes to new ground rather than what you have already found.

Why freeze the code at a commit?

So we and you are reviewing the same contracts from start to finish. If functional code changes mid-audit, findings drift out of date and coverage develops gaps. Documentation, comments and tests can change during the audit; the contract logic in scope does not, until the fix review.

Do you just run automated tools?

No. Manual review is the core of the work. Static analysis, fuzzing and invariant tests run alongside to reach states a person cannot enumerate by hand, but a person reasons about every finding, decides its severity from impact, and writes it up.

Does the audit cover the code we actually deploy?

The audit and the fix review are tied to specific commit hashes, and the report states them. If the deployed bytecode differs from the reviewed commit, the audit no longer applies to it, so we recommend deploying the reviewed commit and checking the on-chain bytecode against it.

Can an audit guarantee the contracts are safe?

No honest audit can. It is a point-in-time review of a specific commit that substantially reduces risk by finding issues before deployment, but it does not remove it. New code, changed assumptions, or a novel attack on a dependency can introduce problems a past audit did not cover.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.