Skip to content
Quantix Security Labs

Smart Contract Auditing

A source-level security review of smart contracts and the protocol logic they implement. Reviewers reconstruct the intended behaviour from specifications and code, then test it against adversarial conditions: privileged roles, external calls, price inputs, upgrade paths and economic incentives. Every reported issue is reproduced or reasoned to a concrete exploit path before it is classified.

Line-by-line review of on-chain code and the logic it encodes.

Request an AssessmentHow it works
Isometric illustration of a protocol’s contract modules joined by call paths, with a brass lens over the vault’s code highlighting one critical line and the finding card raised from it.

Service overview

Line-by-line review of the code that holds value.

A smart contract audit tests what the code does against what the protocol intends it to do, under adversarial conditions, before the code is trusted with funds.

Reviewers first reconstruct the intended behaviour of the system from specifications, tests and conversations with your engineers. Every in-scope line is then read by people, not sampled, and every privileged role, external call, price input and upgrade path is examined for the ways it could be abused.

Tooling widens coverage: static analysers, invariant fuzzers and symbolic tests run alongside manual reasoning, and every tool result is triaged by hand. Nothing becomes a finding until it has been reproduced with a proof-of-concept test or rigorously argued, rated on the severity rubric and peer reviewed.

Findings are shared privately as they are validated. When your team has fixed them, the remediation commit is reviewed against each original issue and the surrounding code is checked for regressions before the final report records its status.

Languages
Solidity, Vyper, Rust (Anchor), Move
Review model
Two reviewers per critical component
Evidence
Proof-of-concept tests for material findings
Output
Quantix Technical Security Assessment

Applies to

  • EVM contracts in Solidity and Vyper
  • Solana programs in Rust and Anchor
  • Move-based modules
  • Upgradeable proxy systems
  • DeFi protocols: lending, AMMs, vaults, staking, bridges
  • Token, governance and treasury contracts
Manual line-by-line reviewInvariant fuzzingEconomic attack modellingFix verification

Threats addressed

Twelve classes of failure, examined on every engagement.

Each area has its own checklist, but checklists are where the review starts. The findings that matter most are usually specific to the protocol in front of us.
  • Business logic

    Specification drift

    Code that compiles and passes tests but does something the protocol never intended, often in an edge case the specification never mentions.

  • Access control

    Unprotected privileged functions

    Missing modifiers, over-broad roles, unprotected initializers and privilege that outlives its purpose.

  • Reentrancy

    Reentrancy and read-only reentrancy

    Classic, cross-function and cross-contract reentrancy through hooks and callbacks, and views read while state is inconsistent.

  • Oracle manipulation

    Manipulable price inputs

    Spot-price dependencies, stale or unchecked feeds, missing sequencer checks, and the cost of moving a price within one block.

  • Precision and rounding

    Arithmetic errors

    Rounding direction, precision loss, unsafe casts, unchecked blocks and share-accounting edge cases.

  • First-depositor attack

    Share inflation

    Empty-vault and low-liquidity states where a donation inflates the share price and later deposits round to zero.

  • Unsafe proxy upgrade

    Upgradeability risks

    Storage-layout collisions, initializer handling, proxy admin control and upgrade authorisation paths.

  • Flash-loan attack

    Economic attack surfaces

    Flash-loan amplified strategies, incentive misalignment, MEV exposure and griefing that costs less than it destroys.

  • Signature replay

    Signature misuse

    Missing nonces, deadlines or domain separation in EIP-712 and EIP-2612 flows, and signatures valid on more than one chain.

  • Unchecked external call

    Cross-contract interactions

    Unchecked return values, call ordering, callback assumptions and state shared between contracts in the system.

  • Governance manipulation

    Governance and timelocks

    Proposals that bypass delays, borrowed voting power, and parameters that can be changed faster than users can react.

  • Business logic

    Integration risks

    Assumptions about tokens, oracles, AMMs and lending markets your contracts depend on, including non-standard tokens.

Technical capabilities

Manual reasoning first, tooling to widen coverage.

Every capability below is applied by reviewers who read the code. Tools are there to find what people would take longer to find, not to replace them.

  • Manual line-by-line review

    Every in-scope line read by a reviewer, with critical components covered independently by two.

    • Intent reconstruction
    • Privileged-path mapping
    • External-call analysis

  • Invariant fuzzing

    Protocol invariants written as properties and fuzzed across long call sequences, including adversarial actors.

    • Stateful invariant tests
    • Handler-based actors
    • Coverage-guided campaigns

  • Economic attack modelling

    Flash-loan amplified scenarios, price manipulation cost, liquidation and incentive analysis.

    • Manipulation cost estimates
    • Liquidity stress scenarios
    • MEV exposure review

  • Upgrade and storage analysis

    Storage-layout diffs between versions, initializer and upgrade-authorisation review, namespaced storage checks.

    • Layout diffing
    • Initializer review
    • Admin-path review

  • Proof-of-concept development

    Material findings ship with a failing test that passes after the fix, so your team can verify both independently.

    • Fork-based PoCs
    • Regression tests
    • Reproduction notes

  • Fix verification

    Remediation commits reviewed against each finding and the code around it, with residual risk recorded.

    • Per-finding status
    • Regression checks
    • Residual-risk notes

Assessment methodology

Three manual passes, one tooling lane, a single gate.

Manual reasoning and automated analysis run in parallel. Nothing becomes a finding until it has been reproduced or rigorously argued, rated against the severity rubric and peer reviewed.
The seven-stage Quantix workflow
Review structure of a smart contract auditThree manual review passes and an automated tooling lane run in parallel across the review window. Every candidate issue from every lane converges on validation before it becomes a finding.Scope fixedReview windowValidationArchitecture and invariantsManualLine-by-line reviewManualAdversarial and economic analysisManualStatic analysis, fuzzing, property testsToolingValidatedfindings
  1. 01

    Scope and threat model

    Commit, files and deployment targets fixed in writing; assets, actors and priority threats agreed.

  2. 02

    Architecture and invariants

    Intended behaviour reconstructed; trust boundaries and invariants written down before line review starts.

  3. 03

    Line-by-line review

    Every in-scope line read, with questions logged for your engineers rather than assumed.

  4. 04

    Adversarial and economic analysis

    Attack scenarios built from the threat model, including multi-step and flash-loan amplified paths.

  5. 05

    Validation and proof of concept

    Each candidate issue reproduced or argued, rated for impact and likelihood, and peer reviewed.

  6. 06

    Reporting and fix review

    Findings delivered as validated; fixes reviewed against the original issue; final report issued.

Severity means the same thing in every report.

Each finding is rated on impact and likelihood separately, then placed on the matrix. The rationale for both ratings is written into the finding.

Critical
Direct loss of funds or permanent loss of control is achievable with little or no precondition.
High
Material loss or protocol disruption is achievable under realistic conditions.
Medium
Limited loss, degraded functionality, or impact that depends on specific conditions.
Low
Minor impact, defence-in-depth gaps, or issues with unlikely preconditions.
Informational
Code quality, documentation or best-practice observations without direct security impact.
Severity is determined by combining impact and likelihood
Low likelihoodMedium likelihoodHigh likelihood
High impact
Medium
High
Critical
Medium impact
Low
Medium
High
Low impact
Low
Low
Medium
Impact measures what an attacker gains or what users lose. Likelihood measures the preconditions, cost and privileges required. Findings without security impact are reported as Informational.

Tools & techniques

Open, reproducible tooling.

Results are reported with the tool and version that produced them, so your team can rerun every check. Tool choice follows the language and the property being tested.
Tools and techniques used for Smart Contract Auditing
Tool or techniqueCategoryWhat it is used for
Foundry (forge)Testing and fuzzingUnit tests, stateful invariant fuzzing, mainnet-fork proofs of concept, storage-layout inspection.
Echidna / MedusaProperty fuzzingLong-sequence property testing with coverage guidance against protocol invariants.
SlitherStatic analysisDetector sweep, inheritance and data-flow graphs; every result triaged manually.
HalmosSymbolic testingSymbolic execution of existing tests to check properties for all inputs within bounds.
OpenZeppelin Upgrades validationsUpgrade safetyStorage-layout compatibility and unsafe-pattern checks between implementation versions.
Anchor / TridentSolana programsAccount-constraint review and fuzzing of instruction sequences for Anchor programs.
Move ProverMove modulesSpecification checks for capability handling and arithmetic in Aptos and Sui modules.
Manual review checklistsMethodClass-by-class checklists maintained from public vulnerability research and past assessments.

Ecosystem coverage

Technical depth per execution environment.

Language, standards and the vulnerability classes we see most often differ by execution environment. Select an ecosystem to see what the review focuses on.

Ethereum

Layer 1, proof of stake EVM

Programming languages
SolidityVyperYul
Typical vulnerabilities
  • Reentrancy, including read-only reentrancy
  • Oracle and spot-price manipulation
  • Access control on privileged functions
  • Proxy storage collisions and initializer misuse
  • Signature replay across chains and contracts
  • Front-running and MEV exposure
Assessment methodologies
  • Line-by-line manual review
  • Invariant fuzzing (Foundry, Echidna)
  • Symbolic execution and formal verification
  • Economic attack modelling
Monitoring capabilities
  • Proxy admin and implementation changes
  • Governance proposals and timelock queues
  • Large transfers and treasury outflows
  • Oracle deviation against reference feeds
Supported standards
ERC-20ERC-721ERC-1155ERC-4626EIP-2612EIP-712ERC-1967ERC-4337

Ecosystems indicate technical specialisation only, not partnerships or endorsements.

Deliverables

Evidence you can act on, and publish.

Before work starts you receive a written scope with commit references. At the end you receive a report written to be verified.

  • Scope definition

    Commit hashes, files, nSLOC and deployment targets agreed in writing, with what is out of scope.

  • Validated findings

    Each finding with location, impact and likelihood rationale, exploit sequence and severity.

  • Proof-of-concept tests

    Failing tests for material findings that pass once the fix is applied.

  • Remediation guidance

    Fixes that fit the codebase as written, with alternatives where a design change is better.

  • Fix review

    Per-finding resolution status against the remediation commit, with residual risk noted.

  • Technical report

    A Quantix Technical Security Assessment suitable for publication, with limitations stated.

What a finding looks like

One finding from the Quantix research assessment of Quillon Vaults, exactly as it appears in the technical report.

QV-02HighResolvedOracle manipulationCWE-807

Strategy valuation uses manipulable AMM spot price

Quillon Vaults · src/strategies/AmmLpStrategy.sol:L97–L131

estimatedTotalAssets() values the LP position by reading the pool’s current reserves and computing the position’s share of each side at the spot ratio. The vault includes this estimate in totalAssets(), which drives both minting and redemption.

Reserves can be moved arbitrarily within one transaction using borrowed capital. Because the valuation reads reserves at the moment of the call, an attacker can skew the ratio, interact with the vault at the distorted price, and restore the pool before the transaction ends.

Exploit sequence

  1. Attacker flash-borrows a large amount of token B.
  2. Attacker swaps B for A in the pool, skewing reserves so that the strategy’s LP position is valued above its fair value.
  3. Attacker redeems shares from the vault at the inflated totalAssets(), receiving more underlying than their shares are worth.
  4. Attacker swaps back to restore the pool and repays the flash loan.
  5. The loss is borne by remaining depositors through a lower share price.

Recommendation

Value positions with a manipulation-resistant reference price: a time-weighted average price over a window long enough that sustaining a distortion is uneconomic, or an external oracle with deviation checks. Additionally compare spot to the reference and revert deposits and withdrawals when the deviation exceeds a bound.

src/strategies/AmmLpStrategy.soldiff
   function estimatedTotalAssets() public view returns (uint256) {-      (uint112 r0, uint112 r1, ) = pool.getReserves();-      return _lpValue(uint256(r1) * 1e18 / r0) + idle();+      uint256 twap = oracle.consult(address(asset), TWAP_WINDOW); // 30 minutes+      uint256 spot = _spotPrice();+      if (_deviationBps(spot, twap) > MAX_DEVIATION_BPS) revert PriceDeviation(spot, twap);+      return _lpValue(twap) + idle();   }

Relevant research

Read the work behind the service.

Publications, case studies and research assessments that show how this service finds and explains issues.
Research hub

Publications

Case studies

All case studies

Research assessments

Security assessments library
Compare all services

FAQ

Questions teams ask before an engagement

It depends on the size and complexity of the code, the quality of documentation and how many external integrations are involved. After an initial scoping call we provide a written estimate of reviewer-days and a calendar window before any commitment.

We review a fixed commit. If development continues during the review, changes are assessed in a separate pass against a new commit reference so the report always states exactly what was reviewed.

Critical and high-severity findings are shared privately as soon as they are validated, without waiting for the report. If the affected code is already deployed, we help you decide on containment first.

Yes, publication is your decision. The final report is written to be publishable and states the scope and commit it covers.

No. An audit reduces risk within a defined scope and time; it cannot prove the absence of vulnerabilities. The report states its limitations explicitly, and we recommend combining audits with testing, monitoring and, for critical logic, formal verification.

Solidity and Vyper on EVM chains, Rust programs on Solana, and Move modules on Aptos and Sui. The ecosystem section above lists the standards and vulnerability classes we focus on for each.

Book a review before your code ships.

Share the repository, the commit you plan to deploy and your target date. We will reply with scoping questions and an estimate.

Request an AuditSee the methodology