Vyper
Vyper security review
Vyper is a contract language for Ethereum, often used for automated market makers (AMMs) and vaults. Hackerbane audits those contracts, the pinned compiler version (the exact release they build and ship), and the factory that deploys them.
scope
What we review
We audit Vyper pools and vaults: the math that prices a swap, the share accounting, and the factory that deploys the pool. @nonreentrant does not stop every kind of reentrancy, and a few compiler versions shipped a guard that did not work. unsafe_mul and unsafe_div skip overflow checks. Factory admin can still kill a pool, change a fee, or point an oracle at a new feed.
Read-only and cross-function reentrancy, including view getters that report mid-swap balances.
The exact compiler version you pin, and whether @nonreentrant actually holds on that release.
unsafe_mul, unsafe_div, and other unsafe_* helpers that skip overflow and bounds checks.
Invariant math, LP share pricing, and first-deposit inflation in vaults and pools.
Pool factory and admin: who can deploy a pool, kill it, change a fee, or swap the oracle after launch.
Advanced Threat Detection
We built our own advanced threat detection stack that is more performant and cheaper than our competitors. We use a state-of-the-art AI harness coupled with world-class senior security engineers with proven experience finding vulnerabilities in well-tested software.
How we review this language
A Vyper review follows the same five-stage engagement as every Hackerbane audit. We lock the commit and the compiler version first, then read the pool math, the reentrancy paths, and the factory admin against that pin.
Two senior engineers read the contracts in parallel. We reproduce the build on your pinned compiler, run detectors across the whole graph, and drive fuzz and invariant suites through the swap, deposit, and withdraw paths your unit tests never reach.
Scope and threat model
We lock the contracts, the commit, the target chains, the pinned compiler release, and who can call what, including deploy keys and any admin that can retarget a pool, before the review starts.
Architecture and design review
We read the vault, AMM, and pool math against that model, including share pricing and reentrancy paths.
Hybrid code and infrastructure review
Two senior engineers read the Vyper in parallel, backed by static analysis, custom detectors, fuzzing, and invariant tests, all built against the compiler release you actually ship.
Exploitability and root-cause analysis
High and Critical findings ship with a proof of concept on the EVM and the root cause, so the class of bug gets fixed rather than one instance, whether it lives in the contract or the deploy script.
Reporting and remediation
A prioritized report, a live walkthrough, and verification of every in scope fix within the remediation window.
Tools and practices
We work in the repository you already use. Foundry and Hardhat projects keep their tests. We add fuzz harnesses and invariant suites, then hand those artifacts back with the report. We compile with the Vyper release you pin, not whatever happens to be installed.
What you get
Prioritized findings your engineers can ship against, each with root cause and a recommended fix.
Verifiable proofs of concept for High and Critical issues, reproduced on the EVM.
A report you can share with partners, exchanges, investors, and regulators.
Remediation verification and a final report that reflects the fixed state of the contracts.
The fuzz and invariant harnesses used during the review, runnable against your pinned compiler.
How to prepare
| # | Before review starts |
|---|---|
| 01 | Builds and tests run cleanly from a fresh checkout, against the compiler version you pin. |
| 02 | The codebase is stable, with no major refactors planned mid-audit. |
| 03 | Pool and vault math, trust assumptions, and factory admin permissions are documented. |
| 04 | Core swap and fund flows are covered by tests, and known limitations are written down. |
| 05 | Scope is defined: which contracts, which commit, and which deployments. |
Other pages
Questions
- Does @nonreentrant make a lock unnecessary?
- No. The decorator only covers the functions it sits on. Read-only getters can still report mid-update balances, and a call into another function can still reach state the lock never saw. Some compiler versions also shipped a guard that did not work. We check every callback, not only the decorated ones.
- Why do you care which compiler version we pin?
- The bytecode and the builtins change between Vyper releases. A known issue in one version is fixed or introduced in the next, including the broken @nonreentrant on 0.2.15, 0.2.16, and 0.3.0. We build against the exact release you ship and review the assumptions that come with it.
- Can you review Vyper next to the Solidity it ships with?
- Yes. When both live in one protocol we read them together, including the interfaces they share, so a call from one into the other is covered.
Next step
Request an audit
Share the Vyper sources, the compiler version you pin, and your timeline. We will propose an audit plan and estimate. Foundry and Hardhat projects are ready as they are.