Smart contract audits

Bugs Cost Millions.
I Catch Them Early.

Independent smart contract auditor and security researcher. Helping teams ship safer protocols through in-depth audits, threat modeling and practical security advice.

Trusted by

A security mindset across the stack

Understand the protocol. Challenge every assumption.
DeFi
AMMs
DEXs
Staking
Lending &
Borrowing
Stablecoins
Yield Strategies
Validator
Systems
Bridges &
Cross-Chain
Other DeFi
Primitives

01 Why teams bring me in

Smart contracts rarely fail in obvious ways.

The expensive bugs tend to live where assumptions, privileges, accounting and edge-case state transitions meet.

Business logic gaps

The code can compile, pass unit tests and still let an attacker take an unintended path through the protocol.

Can lead to direct loss of funds, unintended minting or draining.

Privilege mistakes

Roles, blacklists, upgrade paths and admin assumptions often fail at the edges rather than on the happy path.

Can result in unauthorized control or bypassed restrictions.

Accounting drift

Rounding, share math, stale state and cross-function sequencing can break value conservation without looking dramatic.

Can lead to value leakage, unfair asset distribution or insolvency.

False confidence

A large test suite can prove what was tested. It cannot prove the right adversarial questions were asked.

Can leave an untested attack path and costly exploits after launch.

02 Security services

Security support that fits
where your code is today.

Fast first step

First-Pass Security Review

A focused review for teams that want an early security read before committing to a full audit.

  • Scoped manual review
  • Business logic and edge-case analysis
  • Privilege and trust-boundary review
  • Key attack-surface notes
  • High-risk areas highlighted
  • Clear recommendation on whether deeper review is warranted
Get a first pass
Ongoing

Fractional Smart Contract Security

For teams shipping changes too often to treat security as a once-a-year event.

  • Security-focused code review
  • High-risk PR and feature review
  • Architecture and trust-boundary review
  • Remediation retesting
  • Release-risk discussions
  • Ongoing security input as the protocol evolves
Discuss ongoing support

A clear process.
A stronger protocol.

  1. 01

    Define the scope

    Code, context & assumptions

  2. 02

    Investigate deeply

    Logic, attack paths & impact

  3. 03

    Report & resolve

    Clear findings & fix review

03 Curated findings & wins

Public work that shows how I think.

I prefer verifiable security work over inflated vanity metrics. These are selected public results from competitive audits and security research.

Neutrl ProtocolSherlock

Blacklist bypass in deposit and mint flows

Identified a path allowing restricted stakers to bypass FULL_RESTRICTED_STAKER_ROLE blacklist enforcement.

Sole valid finding
View finding
Starknet Staking Part 2CodeHawks

Competitive security audit

Reviewed Starknet staking logic in a public CodeHawks competition.

#4 overall
View result
SEDA ProtocolSherlock

Validator-triggered chain-node crash

Identified a condition where a malicious validator could submit a vote extension shorter than 65 bytes and crash SEDA chain nodes.

#14 overall
View finding
AmmplifySherlock

JIT penalty bypass through timestamp manipulation

Identified a path that could bypass intended JIT penalties and cause protocol revenue loss.

Validated finding
View finding

04 Security notes

Think like an adversary.

Follow on X
Business logic

A passing test is the start of the question.

Read note

Tests describe expected behavior. Security review also asks how valid operations can be combined in unexpected ways. Trace sequences across deposit, withdrawal, liquidation and privileged actions, then ask which assumptions survive.

Accounting

Small rounding errors deserve a closer look.

Read note

Check who benefits from rounding and whether the same action can be repeated. Review conversions between assets and shares in both directions, especially for empty pools, small deposits and changing exchange rates.

Access control

Every trusted role is a design decision.

Read note

List what each privileged role can do, how it is granted and how it is removed. Include upgrade powers, emergency controls and external dependencies. The protocol’s security model should make those trust assumptions explicit.

05 Before we get started

Good questions.
Clear answers.

Have something else in mind?
Let’s talk about your protocol ↗

What should I share to get a review started?

Share the repository, the commit or branch you want reviewed, documentation, the intended scope and your preferred timeline. A short explanation of the protocol and its key trust assumptions helps define the engagement.

How are scope, pricing and timelines decided?

They depend on the codebase, complexity, documentation and depth of review needed. We’ll discuss those details and agree on the scope and schedule before work begins.

Can you review a protocol before launch?

Yes. A review before launch can help identify design and implementation issues while they are easier to address. A stable codebase and clear documentation make the review more effective.

Does an audit guarantee that a protocol is safe?

No review can guarantee the absence of vulnerabilities. An audit is one layer of security, alongside careful design, testing, monitoring and a considered incident response plan.

Can findings remain private?

Disclosure expectations and report sharing can be agreed before the review. Sensitive findings should be addressed through a coordinated process that gives the team time to investigate and remediate.

Get your code reviewed

Ship with
fewer unknowns.

Preparing for launch, an upgrade, or a meaningful smart-contract change? Send the scope and I’ll review the repository, timing and likely engagement fit.