For exchanges

Your ledger says the balance is real. Does the withdrawal path agree?

Money leaves an exchange between its internal records and its signed transactions. That is where we look. Between your ledger and a signed withdrawal there are several systems, several people and often a vendor. Each one trusts the one before it. We review that path, and the ledger and matching engine behind it, against what your system says it guarantees. We report what we confirm, with proof, and what we could not see. To test yourself first, use the self-assessment checklist. Not sure which review fits? Read which review.

Request a scoping call Custodian or wallet provider?

What goes wrong

Four failure classes from our pattern library. Each is a broken guarantee in code that can review cleanly.

Cancel gives back too muchA partly filled order is cancelled. The system releases the amount locked at placement, not what is left. The difference becomes spendable balance, and it can be withdrawn.

Two requests, one balanceAn order and a withdrawal both check the same available balance. Neither sees the other. Both pass.

Rounding that favours the customerThe fee rounds down and the maker rebate rounds up. One owner trading with themselves earns the difference, on every trade.

Credit before the chain is finalA deposit is credited after a fixed number of confirmations. The chain can reorganise deeper than that, or nothing handles a reorganisation at all.

None of these is a smart-contract bug. All of them end in the same place: the ledger shows a balance that was never funded, and the withdrawal path acts on it. The rules we test against are in the public invariant catalogue.

What we review

Withdrawal path

Withdrawal-path and signing-workflow review

We trace a withdrawal from the customer request, or the back-end command, to broadcast. We ask who can start one, who can approve one and who can change one on the way. We check that the signer sees what will execute, and that the signed transaction is checked against the approved request before it is broadcast.

We look at hot-wallet limits, velocity checks, holds and circuit-breakers. Where relevant, we check pre-signed transactions, durable nonces, and admin, multisig, HSM and MPC configuration. We map every point where a vendor has access into the path. Scope and method.

Planned: three to five weeks, confirmed at scoping

Ledger and engine

Ledger and matching-engine invariant review, with a harness you keep

We write down what your ledger and matching engine must always hold. Balances are conserved. Locks and unlocks mirror each other. Fees and rounding cannot be farmed. Deposits are credited once. Matching and ledger agree under concurrency.

Then we turn that specification into an executable invariant and fuzz harness. It stays with you, and your engineers can run it on every release. AI tools are used in a limited way, to help search for violations of the written invariants. Client material never goes to a third-party model service, and a named person reproduces every finding and signs off every report (how we use AI).

Planned: four to eight weeks, confirmed at scoping

What you receive

A map of your withdrawal path. Every system, role and vendor between the ledger and the broadcast, with the trust each one places in the last.
Findings you can act on. Each states a title; a severity with a one-line justification; the affected component; the business rule it breaks; the impact in money terms where we can size it; reproduction steps; a proof of concept that fails before the fix and passes after; the recommended fix; and how to verify it. We separate confirmed findings from suspicions.
With the invariant review, a written specification and a harness. The guarantees your system should hold, and code that tests them. Yours to keep.
A list of what was not reviewed, and a fix review in which we re-check the fixes you make.

An example of the format is in the sample report. It is a demonstration on a synthetic system, not client work.

Questions that matter most

Two parts of the withdrawal-path checklist deserve attention first, because they are where the content of a request can be changed on its way to the chain. Answer from evidence: a config, a log, a test. If you cannot show it, the answer is “unknown”, and unknown counts as no.

After approval, can the amount, asset, destination or fee still be changed? By whom, and does a change reset the approval? (2.3)
Can an approver see the real destination, amount and asset, or only a reference? (2.4)
Does each signer see them on a screen or device that the instruction server and the operator's laptop cannot alter? (3.1)
Is the signed transaction compared with the approved request before broadcast, by a component independent of the one that built it? (3.2)
Are outflow limits enforced outside the application that creates the withdrawal? (4.1)
Is the user balance debited and the withdrawal locked in one atomic step? (5.1)
If a vendor's production environment were compromised, what is the worst a request could be changed into? (6.3)

The full lists: withdrawal-path checklist and vendor access checklist. Neither is an audit, a certification or legal advice. Answering yes to everything does not mean the path is secure. Public records of four withdrawal-path incidents leave the same five questions open; see what the record does not say.

What a finding looks like

Sample, from a synthetic exchange

Critical CDX-01 matching engine

Cancelling a partly filled order releases the original locked amount

What happens

The cancel handler releases order.quantity × order.price. Fills have already used part of that lock. The difference is credited as spendable balance.

Reproduction

1. BUY 1.0 BTC-USDC @ 50,000      50,000 USDC locked
2. 0.4 BTC filled                 20,000 USDC consumed from the lock
3. Cancel the order               50,000 USDC released
4. Balance: 50,000 USDC + 0.4 BTC net gain 20,000 USDC

Invariant violatedThe sum of all locks equals the sum of all unfilled order remainders, at every point in the order lifecycle.

Fix

Track the lock as one stored amount that falls on each fill. Release exactly that amount. Assert the invariant after every state change, in CI and in a production reconciliation job.

This finding is from the sample report. “Contoso Digital Exchange” does not exist. No real client, system or finding is shown here.

Not reviewed by default

Smart-contract code. We refer standalone contract audits to specialist firms.
General web-application penetration testing.
Red-team and threat-led penetration testing (TLPT) exercises.
Round-the-clock incident response.
Certification audits, and legal or regulatory opinions.
Anything outside the written scope list.

We review; you fix. We do not change your live systems or move funds. We can bring in a partner for the items above, and say so plainly in the proposal. Every statement of work lists its own exclusions. A review of one part of your system says nothing about the parts we did not look at.

How it runs

Scoping call. You tell us what you run, the custody model, the signing set-up and what is prompting the review.
Conflict check, mutual NDA and written scope. Before any testing we run a conflict check, sign a mutual non-disclosure agreement and agree a written scope list. Nothing outside it is touched.
Review, with early warning. A critical finding goes to your named contact as soon as it is confirmed, not at the end.
Report and readout. A written report and a session with your engineers and risk owner.
Fix review. We re-check the fixes you make.

Price is set on a scoping call, fixed per scoped deliverable and agreed in writing before work starts. Scope, assumptions, acceptance criteria and change control go in the proposal.

What we need from you

A named contact who can authorise scope and receive critical findings.
Architecture documents and read access to the code or design of the withdrawal path.
Engineer time for walkthroughs, usually a few hours per person across the engagement.
An agreed test environment, and the vendor contacts we may speak to, with your consent.
Written authorisation for each system in scope.

Regulators: Japan and the EU

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. Ask counsel to review anything you rely on.

Japan

FSA cybersecurity policy (final, 3 April 2026). The FSA says that from the 2026 supervisory year it will ask all crypto-asset exchange operators to run the cybersecurity self-assessment (CSSA). The policy states no deadline, and we found no CSSA form or deadline. Whether this is a legal obligation or an administrative request is not established.
Same policy. External verification of system-risk and signing-key management, and cybersecurity requirements for outsourced parties, are items the FSA says it will consider when it raises its Supervisory Guidelines. They are not yet requirements. We found no revised guideline.
FSA cybersecurity guidelines (4 October 2024). Crypto-asset exchange operators are in scope. Clause 2.6 covers third-party risk, including vendors.
JVCEA rules (in force 1 July 2026). The system-governance and system-risk rules cover outsourcee management, periodic vulnerability assessment and penetration testing, and system audit by internal or external audit. Whether a deebug report could count as an external audit, or as an audit of an important outsourcee, is a question for counsel. We do not claim it does.
FIEA amendment. Japan's 2026 amendment to the Financial Instruments and Exchange Act (Act No. 64, promulgated 23 July 2026) creates a notification regime for providers of customer-asset management systems. Whether a given provider is covered is a question for counsel.

Japan: checked against primary documents on 11 November 2026, and the enacted text of Act No. 64 on 13 November 2026. It is our reading, not legal advice.

Neither MiCA nor DORA asks for a withdrawal-path review by name. They ask for secure ICT systems, controlled outsourcing, safe custody and independent testing. A review can supply evidence. See EU MiCA and DORA for the full table.

Text	What it says	What a review can evidence
MiCA Art. 68(7)	Resilient and secure ICT systems as required by DORA.	Transaction controls and key management.
MiCA Art. 73	The provider remains fully responsible for outsourced services and needs contingency and exit plans.	Vendor access into the path.
MiCA Art. 76(7)	Trading-platform systems must be resilient and “fully tested”.	Ledger and matching-engine invariants tested against written rules.
Authorisation RTS (2025/305), Art. 9(b)	An application includes, “if available”, a description of a cybersecurity audit by a third-party auditor.	An independent report. It is not a stated condition of authorisation.
DORA Art. 24(4)	Resilience tests are undertaken by independent parties, internal or external.	An independent party doing the testing.
ESMA common supervisory action (8 July 2026)	Focus on key and storage management, transaction controls, incident detection and response, and third-party dependencies, applied to a risk-based sample from the second half of 2026 to the first half of 2027.	The same areas.

This is not threat-led penetration testing. Under DORA, TLPT applies only to entities the competent authority identifies, and we found no published list of crypto-asset service providers identified. Which national authority supervises you is a question for counsel.

EU: read from the Official Journal texts and ESMA pages on 11 and 12 November 2026, as published, not consolidated. We have not checked later amendments. Not legal advice.

Want this scoped for your exchange?

Tell us what you run and what is prompting the review. We reply with questions, not a sales pitch. See also how we work.

Request a scoping call Or email us Custodian or wallet provider?

Please do not send credentials, findings or other sensitive material in the clear. We arrange an encrypted channel first.