Find flaws in contract logic, permissions, and accounting.

We review how contracts move funds, enforce permissions, and handle upgrades and integrations.

Technology coverage

Languages and ecosystems we review.

Language support depends on the target chain and contract SDK.

Languages & contract stacks

  • Solidity
  • Rust
  • Move
  • DAML
  • Cairo
  • Stylus
  • CosmWasm
  • Tact
  • FunC
  • Tolk
  • Vyper
  • Sway
  • ink!
  • Go
  • C
  • C++
  • TypeScript
  • JavaScript
  • Java
  • Kotlin
  • C#
  • Python

Ecosystems

  • EVM chains
  • Starknet
  • NEAR
  • Solana
  • Sui
  • Aptos
  • Canton
  • Polkadot
  • Cosmos
  • Casper
  • Stellar
  • TON

This list is not exhaustive.

Discuss your smart contracts.

Share the target chain, contract language, and the assets or permissions at stake.

Discuss your contracts

What we review

A contract is only as secure as the assumptions around it.

01

Logic & state

Expected behavior, state transitions, edge cases, invariants, and failure conditions.

02

Assets & accounting

Balances, rounding, precision, settlement, fees, rewards, and value conservation.

03

Roles & upgrades

Authorization, governance, admin paths, initialization, proxies, and upgrade controls.

04

Integrations & oracles

Cross-contract calls, tokens, callbacks, price feeds, and dependency failures.

05

Economics

Incentive failures, front-running, MEV, manipulation, griefing, and insolvency.

06

Deployment & operations

Configuration, privileged actions, recovery paths, monitoring, and release controls.

Timing

When to schedule a review

Before launch

When code, tests, and expected behavior are stable enough for focused review.

Before an upgrade

When changed state, permissions, accounting, or integrations could invalidate earlier assurance.

Ahead of a major integration

Review how a new bridge, oracle, or counterparty changes the system’s trust assumptions.

After an incident

When the system needs independent review of the failure path and remediation.

Our approach

How we review your contracts.

01

Build the threat model

Agree the scope and target commit. Map assets, roles, trust boundaries, and the ways an attacker could reach them.

02

Trace flows and define invariants

Follow how funds and permissions move through the contracts. Document the security properties each flow must preserve.

03

Review the code and write tests

Examine attack paths through manual review and targeted testing. Add security tests to your repo so your team can rerun them.

04

Verify fixes and document conclusions

We always verify fixes through retesting, record unresolved findings, and tie the principal’s signed opinion to the reviewed commit and supporting evidence.

What you receive

What your team receives.

Findings report

Findings ranked by impact and likelihood, with affected code, evidence, and remediation guidance.

Threat model

Actors, trust boundaries, and attack scenarios, including those blocked by existing controls.

Record of flows and security properties tested

Contract flows showing how funds and permissions move, with the security properties each flow must preserve.

Invariant register

Each security property, its test result, and the evidence your team can use to check future changes.

Security tests in your repo

Regression tests alongside the code, so your engineers can verify fixes and check future changes.

Signed opinion on a reviewed commit

The principal’s conclusions, tied to the reviewed commit, scope, and evidence.

Your review team

Meet the specialists

A principal leads each engagement. Your proposal names the specialists assigned to the scope.

Timur Güvenkaya portrait

Timur Güvenkaya

Founder & Partner

Led a security engineering practice for Rust and non-EVM systems across Substrate and NEAR. Earlier, built vulnerability-detection engines at Invicti used by Fortune 50 and public-sector organizations.

Timur Güvenkaya portrait

Timur Güvenkaya

Founder & Partner

Timur founded Guvenkaya after seeing teams reduce security to code review while their real risk spans architecture, infrastructure, operations, custody, and launch decisions. Before Guvenkaya, he established and led a security engineering practice for complex blockchain systems, specializing in Rust-based and non-EVM ecosystems including Substrate and NEAR. Earlier at Invicti, he helped build enterprise vulnerability-scanning and security detection engines used by Fortune 50 companies and public-sector organizations.
LinkedIn
Łukasz Mikuła portrait

Łukasz Mikuła

Specialist Advisor

Offensive security specialist with 10+ years of experience, 100+ public audits across 8+ ecosystems, and OSCP, OSCE, eWPT, and eWPTX certifications. At ING and Binance, worked across red teaming, exploit development, infrastructure, and high-scale digital asset systems.

Łukasz Mikuła portrait

Łukasz Mikuła

Specialist Advisor

Łukasz is a security researcher with 10+ years in offensive security and a public portfolio of 100+ audits across 8+ ecosystems. His smart-contract work spans EVM/Solidity, Move, Rust-based ecosystems, CosmWasm, Solana, Substrate, and TON, including assessments for Coinbase, MegaETH, Kyber, Jupiter, Zilliqa, IOTA, and Initia Move. At ING, he worked across web application and infrastructure penetration testing, red-team work, exploit development, reverse engineering, mobile security, adversary simulation, and smart-device testing. At Binance, he worked on security concerns for high-scale digital asset systems. He holds the OSCP, OSCE, eWPT, and eWPTX certifications and has CVE disclosures affecting IBM, Oracle, F5, Dell, and Red Hat.
LinkedIn
José C. Ramírez portrait

José C. Ramírez

Specialist Advisor

Security engineer and trainer with around 10 years of experience across application and protocol security. At ZKsync, reviewed Solidity and Rust code, including account abstraction, then built AI-assisted vulnerability-analysis workflows.

José C. Ramírez portrait

José C. Ramírez

Specialist Advisor

José is a security engineer and technical trainer specializing in smart contract and blockchain security, with around 10 years of experience across offensive security, application security, and security review. At ZKsync, he reviewed code, architecture, and design across Solidity/EVM, account abstraction, protocol-level security, and Rust-based components, later building AI-assisted workflows for vulnerability discovery and protocol security analysis. He has participated in smart contract audits across CosmWasm, EVM, and NEAR and holds OSCP, CREST CRT, AWS Certified Security, and AWS Certified Solutions Architect certifications. José has also delivered university courses, guest lectures, and workshops on blockchain and smart contract security, including at the University of Málaga and with the University of Porto.
LinkedIn
Meet the full team

Published reports

Reports from related reviews

Each report includes the full findings and severity ratings.

Sweat Economy

SWEAT NEP-141 Token Security Review

High LookupMap adapter can undercharge storage for selected accounts

  • NEAR
  • Smart contract
  • Rust
View report

Spin Finance

Onchain Orderbook and Perpetual Trading Security Review

Critical Order Placement with Negative/Zero Margin Ratio Is Possible

  • NEAR
  • Smart contract
  • Rust
View report

NEAR / Defuse Labs

NEAR Intents Security Review

Medium Potential Funds Stealing From Users Via Repeating Failed Intents

  • NEAR
  • Intents
  • Rust
View report
View all public reports

FAQ

Frequently asked questions

What do you need to scope the review?

To scope the review, we need access to the contract code alongside its purpose, target commit, planned launch date, and your main concerns. Documentation, tests, and details of integrations help us define the scope and estimate the effort.

Which languages and ecosystems do you cover?

We review Solidity, Rust, Move, DAML, Cairo, Stylus, CosmWasm, Tact, FunC, Tolk, Vyper, Sway, ink!, and other smart-contract stacks across EVM chains, NEAR, Solana, Sui, Aptos, Canton, Polkadot, Cosmos, and TON.

Does the code need to be final?

The review is most efficient when critical behavior, documentation, tests, and the target commit are stable. Design questions can be reviewed earlier.

Can you review only a change set or upgrade?

Yes, when the surrounding system and inherited assumptions can be understood.

Do you verify fixes?

Yes. We always provide remediation guidance and verify fixes through retesting. The final report distinguishes fixed, partially fixed, accepted, and unresolved findings.

What determines the price and duration?

Code size is one factor. Contract complexity, integrations, documentation, and the testing needed to check the system’s behavior also affect the effort. Fix verification and retesting are always included. The proposal defines the review scope and retesting schedule.

Discuss your contract review.

Describe your contracts, planned changes, and launch date. We will propose a review scope.

Discuss your scope