Layer 2 Security Audit — A Layer 2 security audit reviews a rollup or scaling network as a complete system — the sequencer and proposer, the proof or fraud-proof system, the canonical bridge, the escape hatch, the upgrade authority and the data availability path — because on an L2 the failure that costs users their funds is usually a liveness or authority failure rather than a contract bug.
An L2 makes a specific set of promises: that your transaction will be included, that state published to L1 is provable, that you can leave without permission from the operator, and that the rules cannot change out from under you overnight. Each promise has a mechanism behind it, and each mechanism has a failure mode that a contract-only audit will not surface.
We audit those mechanisms directly. On the proving side: circuit soundness and completeness for ZK systems, verifier contract correctness, trusted-setup handling, and whether a malformed proof or an unconstrained witness can finalise invalid state. On the optimistic side: whether the fraud-proof game is actually playable — who can challenge, with what bond, in what window, and whether a censoring sequencer can run the clock out.
Then the parts users feel first. Sequencer centralisation and censorship, forced-inclusion paths and whether they work end to end under load, escape hatches that have been tested rather than merely written, canonical bridge accounting, data availability assumptions and what happens when the DA layer is unavailable, and finally the upgrade key: the security council, the timelock, and whether the multisig that can replace your verifier tomorrow has a threshold that means anything.
We fix a commit hash, agree the in-scope contracts and read your architecture docs, then build a threat model: who the actors are, what the trust boundaries are, and which invariants must never break. Nothing is reviewed against assumptions we have not written down.
Line-by-line review by at least two auditors working independently, focused on authorisation, accounting, upgrade paths, external integrations and the gap between what the code does and what the documentation claims it does. Most critical findings come from this phase, not from tooling.
Static analysers appropriate to the language, plus property-based fuzzing and invariant testing to push the system into states no unit test covers. Tooling is used to widen coverage, never to replace the manual pass.
Candidate findings are proven on a forked network with a working proof of concept. We report what an attacker can actually do and what it costs them, not a theoretical severity label.
Every finding gets a severity rating, reproduction steps, the affected code, the impact in concrete terms and a specific remediation. You get a draft for discussion before anything is finalised.
We re-test every remediation against the original proof of concept and check that the fix has not opened a new path. The final report is yours to publish.
| Severity | What it means |
|---|---|
| Critical | Direct loss of funds or permanent freezing of assets, exploitable by any actor. |
| High | Loss of funds or protocol insolvency under realistic conditions, or requiring a privileged actor to misbehave. |
| Medium | Broken protocol behaviour, denial of service, or value leakage that does not directly drain the contract. |
| Low | Edge-case incorrectness with limited impact, or an issue requiring implausible preconditions. |
| Informational | Code quality, gas efficiency, documentation mismatch and defence-in-depth suggestions. |
Single token contract: starts from $999, report in 24–48 hours. dApp, GameFi or RWA project: starts from $2,999. DeFi protocol, L2 / rollup, Bridge, ZK circuit, AI agent / MCP: scoped per project after we have seen the code.
A review of a rollup or scaling network as a whole system: rollup contracts, proof or fraud-proof mechanism, sequencer and proposer operations, canonical bridge, escape hatch and upgrade authority — the mechanisms behind the promises an L2 makes to its users.
Both. ZK work centres on circuit soundness, verifier integration and setup handling; optimistic work centres on whether the fraud-proof game is genuinely playable by an unprivileged challenger inside the real challenge window.
It is often the largest one. A single sequencer can censor, reorder and extract, and if forced inclusion or the escape hatch does not work in practice, users depend entirely on the operator continuing to behave. We test those paths rather than reading about them.
Yes — see our bridge security audit. On an L2 engagement the bridge is in scope by default, because bridge accounting and mint authority are where L2 losses concentrate.
Yes. We check whether the upgrade authority, challenger permissioning and DA model match the stage you publicly claim, because the gap between the two is itself a disclosure risk.
A repository or contract address, a commit hash to freeze the scope, whatever architecture or spec documentation exists, and a point of contact who can answer design questions. If documentation is thin we will write our understanding of the system back to you and ask you to confirm it — that step alone catches design-level bugs.
A single token contract is 24–48 hours. A typical dApp or mid-sized protocol runs one to two weeks. Large DeFi systems, L2s, bridges and ZK circuits are scoped per project after we have seen the code. We will give you a fixed timeline with the quote, not an estimate that moves.
Yes. Fix review is part of the engagement, not an upsell. We re-run the original proof of concept against your patched code and confirm the fix has not introduced a new path.
Send the repository and a commit hash through the contact form, message @bugtester25 on Telegram, or book a 30-minute scoping call. 200+ protocols audited · $4B+ secured · 0 hacks post-audit. Prefer email? info@safeedges.in.