Withdrawal-path review: scope and method

• Who can originate a withdrawal, who can approve it, and who can alter it between the two.
• Whether the signer sees the real destination, amount and asset on a device the instruction server cannot change.
• How the signed transaction is checked against the approved request before it is broadcast.
• Hot-wallet limits, velocity checks, holds and circuit-breakers on large outflows.
• Pre-signed transactions, durable nonces, and admin and multisig configuration. Where you use an HSM or MPC: how keys and shares are held and administered, where signing policy is enforced, and whether each node verifies what it signs.
• Vendor and contractor access into the request queue and the signing environment, and how that access is granted, logged and reviewed.
• Consistency between the internal ledger and what actually leaves.

• Scoping call. You tell us what you run, the custody model, the signing set-up and what is prompting the review.
• Conflict check and written authorisation. Before any testing we agree a written scope list. Nothing outside it is touched.
• Review. Architecture and document review, walkthroughs with your engineers, and tests on the systems named in the scope.
• Reporting as we go. A critical finding is reported 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. We review; you fix. We do not change your live systems or move funds.

Every finding states: a title; severity with a one-line justification; the affected component; the business rule or invariant 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, and say what evidence would settle a suspicion.

The report also lists what was not reviewed. You can see an example of the format in the sample report, which is a demonstration on a synthetic system and not client work.

For a single withdrawal flow we plan three to five weeks, confirmed at scoping. Price is fixed per scoped deliverable and agreed in writing before work starts, never per day. Scope, assumptions, acceptance criteria and change control are written down in the proposal.

• 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.
• The cryptographic design of an MPC or signature scheme. We review how it is configured, integrated and operated.
• Anything outside the written scope list.

We can bring in a partner for these, and say so plainly in the proposal.

• 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.

On request we map findings to the framework your regulator uses, for example Japan's FSA guidelines for crypto-asset exchange service providers, EU MiCA and DORA, or the UAE's VARA, DFSA and CMA rules. The report is evidence for your own compliance work. It is not an audit opinion, a certification, a regulatory approval or legal advice. Where a regulator requires a certified or accredited tester, we say so up front and propose a partner.