A penetration test of a cryptocurrency exchange is not a web application test with extra steps. The asset is transferable and the transfer is final, the platform runs continuously with no settlement window in which to catch an error, and a substantial part of the attack surface is internal tooling that never faces a customer. The methodology has to reflect that or the engagement produces a competent report about the wrong system.
This is how we structure the work.
Scoping
Scoping decisions on an exchange engagement carry more weight than elsewhere, because the highest-value targets are also the ones a client is most reluctant to expose. Three questions settle most of it.
Where does testing happen? Production testing on a live exchange is constrained: you cannot safely test concurrency on withdrawal logic against real balances. A staging environment with production-equivalent configuration and synthetic assets is the right home for the destructive parts. The critical requirement is configuration equivalence, verified rather than asserted — a staging environment with the policy engine in permissive mode tests nothing useful.
What is in scope beyond the application? Internal administrative tooling, the withdrawal orchestration and policy services, treasury automation, node infrastructure and the deployment pipeline. If the engagement stops at the customer-facing application, the report will be thin where it should be thickest.
What are the escalation rules? Agree in advance what happens if testing indicates an active compromise rather than a latent weakness, and who is called. On an exchange this is not a hypothetical clause.
Key and wallet boundaries
The first technical objective is establishing where key material actually is and what can cause it to be used. Documentation describes the intent; the assessment establishes the implementation.
- Which service can request a signature, and what does the signing service verify before producing one?
- Is the policy engine consulted on every path, or only on the customer withdrawal path?
- Where do HSM or MPC credentials live, and what reaches them?
- Does the cold tier require physical or procedural steps that cannot be triggered remotely, and is that enforced technically or by convention?
The single most productive question is whether the signing service independently verifies authority or trusts its caller. A signing service that signs whatever the orchestrator sends collapses every upstream control into one: compromise the orchestrator, own the wallet.
The withdrawal chain
Test the withdrawal path as a sequence — creation, validation, risk scoring, approval, signing, broadcast, confirmation — and at each link ask whether the chain can be entered further along. Construct the step-four request directly and see whether steps one to three are re-verified.
Then test the properties that only appear under load or timing:
- Concurrency. Parallel withdrawal requests that each pass a balance or limit check before either commits. Test with genuine parallelism, not sequential requests.
- Limit windows. Whether daily limits reset on a fixed boundary that can be straddled, and whether limits are enforced per account, per credential or per destination.
- Allowlist bypass. Whether a newly added address is subject to the delay it should be, and whether an administrative function, a support action or an account recovery flow removes the delay.
- Quorum integrity. Whether two approvals can originate from one session, one person or one credential set.
Deposits and chain handling
Deposit crediting is assessed per chain rather than globally. Confirmation depth should reflect the reorganisation characteristics of each network. Test reorganisation handling explicitly where the environment permits, along with replay across forked networks and the treatment of non-standard token behaviour: transfer fees, rebasing supply, blocklist functions and callback hooks that re-enter crediting logic.
Also test the listing process itself. If a new asset can be enabled without a contract review, the platform's exposure is defined by whoever last requested a listing.
Trading engine and market integrity
Matching engine testing covers authorisation on internal interfaces, integrity of market data, and behaviour under order types and sequences the engine was not designed for. Self-trade prevention, order cancellation races, partial fill accounting and fee calculation rounding all belong here. Rounding in particular deserves attention: a consistent half-satoshi advantage, executed at volume, is a real extraction path and rarely appears in a threat model.
Internal tooling
The administrative console typically has the greatest capability and the least testing. It can adjust balances, cancel orders, unlock accounts, override risk decisions and, in some implementations, initiate transfers. Test it as a first-class target: authentication and session handling, authorisation between operator roles, whether every action produces an immutable log entry, and whether any function can complete without a second party.
Internal tooling is also where the assessment most often finds credentials with excessive reach — a support console with direct database write access, or a runbook script executing with the deployment pipeline's identity.
Detection as an output
Record timestamps for all significant testing activity and compare them against the client's alerting afterwards. Where testing generated no detection, that absence is a finding, and for an exchange it is frequently more consequential than the vulnerability that produced it. A platform that cannot see a failed exploitation attempt cannot see a successful one either.
Reporting
Order findings by loss potential first. The executive summary should state plainly which findings could result in asset loss, which could result in service disruption and which are hygiene. Include asset-flow diagrams so a reader unfamiliar with the platform can follow how a weakness becomes a withdrawal that should not have happened, and publish full CVSS 4.0 vectors so the client can rescore against their own environment.
