How long does a smart contract audit take?

Engagement duration depends on codebase complexity, integration surface, and risk profile. Scoping calls happen before any work starts so we can give you a clear delivery plan.

What languages do you cover?

Solidity is the most common. We also audit Vyper, Rust (Solana, Substrate, Stylus), Move, Cairo, and Huff. If your contracts compile to EVM bytecode or run on a major Layer 1, we have audited it.

Do you provide a public report?

We deliver a private report first, then publish an unredacted public version to github.com/sigp/public-audits if the client agrees. Many clients agree. Public reports are part of how we hold ourselves accountable.

What is your severity classification?

Critical, High, Medium, Low, Informational. Critical findings fundamentally break security or value. High findings break a stated property under realistic conditions. Medium findings degrade security under specific conditions. Low and Informational findings cover hardening, gas, and code quality.

Will you re-audit after we fix issues?

Yes. Remediation review is included in the engagement. We verify each fix against the original finding and confirm it does not introduce a new issue.

Can you work under NDA before we sign a SOW?

Yes. NDA-first engagement is standard for us. We sign a mutual NDA before scoping calls if you need to share architecture documents, threat models, or non-public code.

Smart Contract Audit

A Sigma Prime smart contract audit is a manual line-by-line review of your Solidity, Vyper, or Rust contracts by an engineer who has audited the protocol class your code belongs to. We model the threat surface, attack the invariants you care about, and deliver a written report with reproducible findings, severity classifications, and remediation guidance.

Request a scoping call

What we cover.

Every smart contract audit is scoped to your specific contracts, but a typical engagement reviews:

01

Access control and authorization. Who can call what, when, and what happens if they should not.
02

Asset accounting. Mints, burns, transfers, and balance reconciliation across upgrades and forks.
03

Reentrancy and external call safety. Cross-function reentrancy, read-only reentrancy, callback re-entry through ERC-777, ERC-1155, and arbitrary receivers.
04

Numerical safety. Integer overflow under unchecked blocks, rounding bias, share-price manipulation, oracle dependencies.
05

Upgrade safety. Proxy storage layout, initialization, slot collisions, role transfer, and emergency pause behaviour.
06

Cross-contract composability. How your contracts interact with widely used standards (ERC-4626, Uniswap V3 pools, Compound markets, Chainlink feeds) and what assumptions break under hostile composability.
07

MEV and sequencing exposure. Sandwich, frontrun, and back-run vectors that affect your users, including L2-specific sequencer behaviour.

Our approach.

A Sigma Prime smart contract audit is principally a manual review. Automated tools sit alongside the manual work but they are aids, not the deliverable. The deliverable is engineer judgment.

We work in pairs on most engagements. One engineer leads, a second engineer reviews the findings independently before they reach you. This catches false positives early and surfaces issues a single reviewer would miss.

Static analysis (Slither, Mythril, custom Semgrep rules), invariant fuzzing (Foundry, Echidna, Halmos), and symbolic execution run alongside manual review. Tool output is triaged by an engineer; we do not paste raw output into reports.

We write proof-of-concept exploits where the impact is non-obvious. If a finding is in the report, you should be able to reproduce it from the report — the call sequence is in there.

What makes a smart contract audit useful.

Start with the exact commit

The audit should review the code you expect to deploy, not a moving branch that is still changing every day. We ask for a commit hash, release branch, or diff against a known upstream before review starts. If the scope changes materially during the engagement, the security claim changes with it.

This matters more than process tidiness. Most serious contract bugs depend on an interaction between modules, roles, deployment order, and assumptions about existing contracts. Reviewers need the same system that production users will rely on.

Name the properties that must hold

Review depth improves when the team can state what must never break: balances reconcile, shares cannot be inflated, roles cannot be bypassed, exits remain available, upgrades cannot corrupt state. Without those properties, an audit becomes code archaeology.

We still read the code line by line, but the most useful findings usually come from testing intent against implementation. A clear invariant gives the reviewer something to attack and gives the engineering team a cleaner remediation target.

Bring deployment reality into scope

Deployment scripts, constructor arguments, initialization order, and migration plans.
Existing contracts, oracle feeds, keepers, relayers, bridges, and governance systems that the new code trusts.
Privileged roles, emergency powers, multisig ownership, timelocks, and upgrade authority.
Known design tradeoffs or areas where the engineering team is least confident.

Leave time to fix

A report is only useful if the team can act on it. Findings should explain the exploit path, the impact, the affected code, and the property a fix needs to preserve. Remediation review then checks the fix against the original threat model instead of treating the patch as a formality.

Related research and guidance.

Frequently asked questions.

How long does a smart contract audit take?

Engagement duration depends on codebase complexity, integration surface, and risk profile. Scoping calls happen before any work starts so we can give you a clear delivery plan.
What languages do you cover?

Solidity is the most common. We also audit Vyper, Rust (Solana, Substrate, Stylus), Move, Cairo, and Huff. If your contracts compile to EVM bytecode or run on a major Layer 1, we have audited it.
Do you provide a public report?

We deliver a private report first, then publish an unredacted public version to github.com/sigp/public-audits if the client agrees. Many clients agree. Public reports are part of how we hold ourselves accountable.
What is your severity classification?

Critical, High, Medium, Low, Informational. Critical findings fundamentally break security or value. High findings break a stated property under realistic conditions. Medium findings degrade security under specific conditions. Low and Informational findings cover hardening, gas, and code quality.
Will you re-audit after we fix issues?

Yes. Remediation review is included in the engagement. We verify each fix against the original finding and confirm it does not introduce a new issue.
Can you work under NDA before we sign a SOW?

Yes. NDA-first engagement is standard for us. We sign a mutual NDA before scoping calls if you need to share architecture documents, threat models, or non-public code.

Other engagements you might be considering.

Scope a smart contract audit.

Tell us what you are building. We respond within two business days with a scoping call and a written engagement proposal.

Request a scoping call

Services

Products

Resources

Company

Social

contact@sigmaprime.io