Straight answers to what founders ask before they sign.

Price depends on the size and complexity of the code, the integrations it touches, the solution you choose and how tight your deadline is. We quote after reading the repo so the number is accurate: send it and you get a fixed price within 24 hours. Fixed means fixed: no hourly meter, no surprise invoice. If you have a budget in mind, say so in the form and we will tell you which solution fits it.

It depends on how much value your code holds and how far along it is. Free AI scan credits suit early code and tight budgets. A hybrid AI + manual audit suits most launches. A pure manual audit, with formal verification for your core logic, suits high-value or novel code. Tell us your situation in the form and the quote will name the one we recommend. You can read about each one on the solutions page.

It depends mainly on the amount of code and how complex the logic is. Small, focused codebases take far less time than large multi-contract protocols. We give you a timeline in the quote, scheduled backward from your launch date, and if the review cannot fit we say so instead of rushing the work.

Not if we plan it together. Put your target date in the form and we schedule backward from it. If the review can't fit, we say so in the quote instead of rushing the work. The cheapest bug is the one found before deployment.

Four steps. Scope: we read the repo, agree what is in and out, and send a fixed quote within 24 hours. Adversarial review: an AI scan, manual line-by-line review, fuzzing, invariant tests and formal verification. Report: severity-ranked findings, each with a recommended fix, with critical issues reported the same day. Fix review: we re-check every patch before you ship, and it is included in the price.

A repo link or access, the commit hash you want reviewed, any docs or specs, the chain you're deploying to, and your target date. A 30-minute scoping call helps, but a repo alone is enough for us to quote.

Parapet Labs is a Web3 security firm that audits smart contracts for EVM (Solidity) and Solana (Rust) protocols. We combine an AI scan with manual line-by-line review, fuzzing, invariant testing and formal verification, and give you severity-ranked findings with a recommended fix for each. Read more about us.

Senior security researchers read your code and write every finding. There are no juniors on your project and no sales layer between you and the auditors: you get a direct line to the people reviewing your system, from scoping through fix review. You can meet the founders and check their track records.

We audit smart contracts on EVM chains (Solidity) and on Solana (Rust, including Anchor programs). If you are building on another chain, tell us in the form and we will say honestly whether we are the right team for it.

Yes. We sign an NDA before you share private code. Mention it in the form or raise it on the scoping call.

Yes, as a first pass, never as a replacement for a human reviewer. An AI scan flags suspect code quickly, then senior auditors read the code line by line, reason about the protocol's logic, and try to break it with fuzzing and invariant tests. The AI scan is also offered on its own for early code and tight budgets.

You hear about it the same day, privately. We don't hold it for the final report. We help you scope the fix, you patch, and we verify the patch. Fix verification is included.

Severity-ranked findings, each with a description of the issue, its impact, the affected code and a recommended fix. It is written to be acted on by engineers and understood by the people who sign off. You can look at a sample report to see the format.

Yes. Every patch is re-checked before you ship, and fix review is included in the price. You keep talking to the same auditors who know your code, and if you ship further changes, the same auditors can review the diff.

Findings are ranked by impact and likelihood. Issues that can directly cause loss or permanent lock-up of funds, and are easy to trigger, rank highest. Issues that need specific conditions, or that break functionality without losing funds, rank lower, and code quality notes rank lowest. Each finding in the report shows its rating so you know what to fix first.

No honest auditor can promise that. An audit greatly reduces risk by having senior reviewers examine your code and logic, but it is a review at a point in time. Code that changes after the report, new integrations and unexpected conditions can all introduce new risk. That is why we recommend reviewing significant changes, testing continuously and running a bug bounty after launch.

After the code is feature-complete and tested, and before it is deployed with real funds. Freeze the code you want reviewed, since changes during the audit make findings harder to track. If you want earlier input, a protocol design review before the code exists can catch architectural flaws while they are cheap to fix.

One audit is one set of eyes at one moment in time. Code changes after the report, and so do the assumptions around it. A second independent review tends to find different things, and any change since the last audit is unreviewed code. If we think you don't need another one, we'll tell you.

No. Many teams come to us after deployment. We review what is live, including upgrade paths and admin permissions, and rank findings by severity so you know what to fix first. Some fixes ship as upgrades. Others call for mitigations. We help you sort out which is which.

Any change to audited code is unreviewed code. Small, isolated changes can often be covered by reviewing just the diff, while changes to core logic, new integrations or a move to a new chain deserve a fuller review. Send us the diff and we will tell you which one it is.

A smart contract audit is a security review of a protocol's code and logic, done by specialist researchers who try to find vulnerabilities before attackers do. The result is a report listing issues by severity with recommended fixes, followed by a check that your fixes work.

Smart contracts usually hold real funds and, once deployed, are public and often hard or impossible to change. Attackers can read your code at any time, and a single flaw can drain a protocol. An audit finds those flaws while they are still cheap to fix, and it also builds trust with users, partners and investors.

Automated tools are good at catching known, mechanical patterns quickly, which makes them a useful first pass. They struggle with business logic, economic design and multi-step attacks that depend on how your protocol is meant to behave. For code holding meaningful value, you want a human reviewer on top of automation.

An AI scan is a fast automated pass that flags suspect code and obvious flaws. A manual audit has senior researchers read each function, understand the protocol's intent, and test it adversarially with fuzzing, invariant tests and formal verification. The scan is cheaper and quicker. The manual audit goes much deeper.

Fuzzing feeds a contract large numbers of random or adversarial inputs to see if anything breaks. Invariant testing defines properties that must always hold, such as total supply matching the sum of balances, and checks that no sequence of actions can violate them. Formal verification uses mathematical methods to prove a property holds for all inputs, and is best applied to your most critical logic.

An audit is a time-boxed, pre-agreed review of a defined codebase before you launch. A bug bounty is an open invitation for researchers to report issues in live code in exchange for a reward. They complement each other: audit first to remove as many flaws as possible, then run a bounty to catch what remains.

EVM contracts keep their own state and the main risks are in contract logic, external calls and token handling. Solana programs are stateless and operate on accounts passed in by the caller, so missing account, signer and ownership checks, and correct handling of program-derived addresses and cross-program invocations, become central. We audit both and use methods suited to each.

Freeze the code at a specific commit, make sure it compiles and its tests pass, and share documentation that explains what the protocol is meant to do, including roles, assumptions and any known risks. The clearer the intent, the more time auditors spend finding real bugs instead of reverse-engineering the design.

Frequent classes include reentrancy, broken access control, price oracle manipulation, flash loan attacks, arithmetic and rounding errors, front-running and MEV, unsafe upgradeability, signature replay, and flawed business or economic logic. Many of the largest losses come from logic flaws that are specific to a protocol's design rather than from textbook bugs.

Reentrancy happens when a contract makes an external call before it finishes updating its own state, letting the called contract call back in and repeat an action, such as withdrawing funds, while the old state is still in effect. It is prevented by updating state before external calls, using reentrancy guards and keeping external interactions to a minimum.

Many protocols rely on price feeds to value collateral, trigger liquidations or price swaps. If an attacker can move the price source, for example by trading heavily in a thin pool, the protocol acts on a false price and can be drained. Safer designs use robust, hard-to-manipulate feeds, check for stale or invalid data, and limit how far a price can move in one step.

A flash loan lets anyone borrow a very large amount with no collateral, as long as it is repaid in the same transaction. Attackers use that temporary capital to manipulate prices, voting power or balances inside a single transaction. It does not create new bugs, but it makes existing weaknesses, such as manipulable prices, much cheaper to exploit.

These are cases where a sensitive function, such as minting, upgrading or withdrawing, can be called by someone who should not be able to, or where a role holds more power than intended. They are among the costliest bugs and are found by mapping every privileged function and checking who can really call it.

If a single key or small group can upgrade contracts, pause the protocol, change parameters or move funds, then compromising that key compromises the protocol, and users must trust the key holders. An audit maps these powers so you can reduce them with multisigs, timelocks, role separation and clear documentation.

On public blockchains, pending transactions are visible before they are confirmed. Searchers and validators can reorder, insert or copy transactions to profit, for example by sandwiching a swap. Protocols reduce the damage with slippage limits, deadlines, commit-reveal schemes and designs that do not depend on transaction ordering.

Upgradeability lets you fix bugs after launch, but it also adds risk. Storage layout mistakes can corrupt state, an uninitialized implementation can be taken over, and whoever controls the upgrade can change the rules. If you use proxies, audit the upgrade path and permissions as carefully as the logic itself.

Keep contracts simple and small, follow the checks-effects-interactions pattern, validate inputs and permissions on every external function, and avoid unnecessary privileged roles. Reuse well-reviewed libraries instead of writing your own, document your assumptions and invariants, and treat any code that moves value as high-risk.

Write thorough unit tests, then add fuzz tests and invariant tests for the properties that must never break. Test edge cases such as zero values, maximum values, empty pools and the first and last user. Good tests speed up an audit and often catch simple bugs before you pay for review.

Generally yes. Widely used, heavily reviewed libraries for tokens, access control and upgradeability are safer than custom versions. You still need to use them correctly, so the way you integrate and configure them is part of what an audit covers.

Do not leave powerful roles on a single externally owned account. Use a multisig, add a timelock so users can see changes before they take effect, split duties across roles, give each role the least power it needs, and plan for key rotation and recovery.

Monitor your contracts for unusual activity, have an incident response plan and a way to pause or contain a problem if your design allows it, run a bug bounty, and review any new code or integrations before they go live. Security is ongoing, not a one-time event.

Common reasons include code that changed after the audit, new integrations that were never reviewed, compromised keys, economic or logic flaws that are hard to spot, and audits that were rushed or too shallow. This is why we recommend reviewing every significant change, using several layers of defence and working with auditors who understand your protocol rather than only running tools.