Which review do you need?
A withdrawal-path review, a penetration test and a smart-contract audit answer different questions. This page sets out what each covers, what each misses, what you receive and when to choose which. For the sequence of an engagement, see how we work.
The short version
These are different jobs. A withdrawal-path and ledger-invariant review asks whether money can leave when it should not. A penetration test asks whether a system can be broken into. A smart-contract audit asks whether contract code behaves as written. Many exchanges and custodians need more than one.
We do the first. We do not do the other two ourselves, and we say so. Where you need them, we can introduce a partner.
The comparison
| Aspect | Withdrawal-path and ledger-invariant review (deebug) | General web or network penetration test | Smart-contract audit |
|---|---|---|---|
| The question it answers | Can a withdrawal be originated, approved, changed or signed in a way the business did not intend? Does the ledger keep its rules? | Can assessors, mimicking real-world attacks, find ways around the security features of an application, system or network in scope? (NIST SP 800-115) | Typically, whether the contract code does what it is meant to do, and whether it can be abused. |
| What it covers | The route from customer request or back-end command to a signed, broadcast transaction: who can start, approve and alter a withdrawal; what the signer sees; how the signed transaction is checked before broadcast; hot-wallet limits, holds and circuit-breakers; pre-signed transactions, durable nonces, admin and multisig configuration; vendor and contractor access; consistency between the ledger and what leaves. In the invariant version: written rules for balance conservation, lock and unlock symmetry, fees and rounding, deposit idempotence and matching-to-ledger races, with a test harness the client keeps. | The systems named in the scope, tested for weaknesses that can actually be exploited. NIST describes penetration testing as often launching real attacks on real systems, and as sometimes including non-technical methods of attack. For web applications and services, the OWASP testing guide covers areas such as business logic, identity and authorization, input validation, client-side security and API security, and treats penetration testing as a technique to validate that vulnerabilities can be exploited. | Typically, the source code of the contracts in scope. |
| What it misses | By default: smart-contract code, general web-application testing, red-team and threat-led exercises, round-the-clock incident response, certification audits, legal or regulatory opinions, and anything outside the written scope list. | Whatever is outside the agreed scope. A web test can include business-logic checks inside the application in scope. Rules that span systems, such as that what the signer displays equals what was approved, or that two services never spend the same balance, fall outside it unless they are named in scope. OWASP says its guide does not replace threat modelling, remediation guidance or comprehensive source-code review. | Typically, everything outside the contracts: the instruction server, the approval workflow, the signer's display, key and policy management, vendor access and the exchange's internal ledger. Ethereum.org notes that audits “won't catch every bug and are mostly designed to provide an additional round of reviews”. |
| Typical output | A report. Each finding has a severity with a one-line reason, the business rule it breaks, reproduction steps, a proof of concept that fails before the fix and passes after, the recommended fix and how to verify it. Confirmed findings are separated from suspicions. A list of what was not reviewed. In the invariant version, an executable harness. | Typically, a report of findings with severity and remediation advice. The format varies by provider. | Typically, a report of issues found in the contracts with severity and recommendations. The format varies by provider. |
| Who it suits | Exchanges, custodians, and the vendors that run their systems. | Organisations with systems that an attacker could reach, once the scope is agreed. | Teams that deploy or depend on smart contracts. |
| Calendar (planned, confirmed at scoping) | Planned at three to five weeks for a single withdrawal flow, and four to eight weeks for the ledger and matching-engine invariant review with harness. Both are confirmed at scoping. | Varies with scope; set by the provider. | Varies with scope; set by the provider. |
| Does deebug do it? | Yes. | No. We refer it to partners. | No. We refer standalone contract audits to specialist firms. |
On a narrow screen, scroll the table sideways.
When to choose which
- Choose a withdrawal-path review when the question is how funds could leave without authorisation, whether the signer sees what executes, or whether vendors can reach the path. Also when a regulator or a board is asking about key management, transaction controls and third-party access. See scope and method.
- Choose a ledger and matching-engine invariant review when the worry is balances, locks, fees, rounding, deposits and races between the matching engine and the ledger, and you want tests that run on every release.
- Choose a penetration test when the question is exposure of particular applications, APIs or networks. A withdrawal-path review is not a substitute. We refer general web and network testing to partners.
- Choose a smart-contract audit when contracts hold or move value. A withdrawal-path review is not a substitute. We refer standalone contract audits to specialist firms. Where a contract’s admin or multisig configuration is part of the withdrawal path, we review that configuration, not the contract code.
- Choose threat-led or red-team testing when you want a realistic attack exercise against live operations. We refer it to partners.
Most exchanges and custodians will need more than one of these over time. The order depends on where the risk is. A scoping call is the place to decide. Price is set on a scoping call.
A note on regulators
A deebug report is evidence for your own compliance work. It is not an audit opinion, a certification, a regulatory approval or legal advice. deebug holds no certifications and does not claim any. Where a regulator requires a certified or accredited tester, we say so up front and propose a partner.
In the EU, the authorisation standard for crypto-asset service providers asks, “if available”, for a description of a third-party cybersecurity audit that includes penetration tests and, where smart contracts are used, a source-code review. That is a different thing from a withdrawal-path review, and a review does not replace it. (Delegated Regulation (EU) 2025/305, Art. 9(b); as published, not consolidated.) For the wider EU picture, see EU MiCA and DORA.
Sources
- NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment (September 2008): csrc.nist.gov/pubs/sp/800/115/final. Accessed 13 November 2026.
- OWASP Web Security Testing Guide, section 2, Introduction: wstg.owasp.org/latest/2-Introduction/. Accessed 13 November 2026.
- Ethereum.org, Smart contract security: ethereum.org/en/developers/docs/smart-contracts/security/. Accessed 13 November 2026.
Not sure which review fits?
Tell us what you run and what is prompting the question. We reply with questions, not a sales pitch.