Withdrawal-path self-assessment checklist

Forty-six yes / no / unknown questions about the route a withdrawal takes from a customer request or back-end command to a signed, broadcast transaction. Answer them with the engineers who run the system, not from the architecture diagram. Anything you answer "no" or "unknown" is a place to look, not a verdict.

Download the PDF Email for an editable copy

—

How to use it

  1. Put an engineer who runs the path, a risk or compliance owner and someone from the team that operates the signing infrastructure in one room for 90 minutes.
  2. Answer each question from evidence you can show (a config, a log, a test), not from memory. If you cannot show it, answer "unknown".
  3. For each "no" or "unknown", write an owner and a date.
  4. Repeat after any change to the signing set-up, a wallet or custody vendor, or the approval workflow.
  5. Questions 3.6 to 3.13 apply only if you use what they ask about: pre-signed transactions, multisig, an HSM or MPC. If you do not, write “not applicable”.
—

What this is not

It is not an audit, a certification, a regulatory submission or legal advice. Answering "yes" to every item does not mean the path is secure; it means these questions did not find a gap. It is a way to find work before someone else does.

01

Origin: who can start a withdrawal

  1. 1.1Can you list every system, role and API key that can create a withdrawal request, including admin tools and back-office scripts, and is every one logged with who, from where and under which approval?
  2. 1.2Can an internal user create a withdrawal for a customer account without that customer's authenticated action and a second internal approver?
  3. 1.3Is a change to a customer's withdrawal address, or the creation of a new one, subject to a delay or a second factor before it can be used?
  4. 1.4Can a withdrawal be created while the customer's session, device or login anomaly checks are failing?
02

Approval: who can approve or alter

  1. 2.1Is the number of independent approvers for each withdrawal size band written down and enforced by the system, not by procedure alone?
  2. 2.2Can one person, one workstation or one set of credentials satisfy more than one approval step?
  3. 2.3After approval, can the amount, asset, destination or fee still be changed? By whom, and does a change reset the approval?
  4. 2.4Can an approver see the real destination, amount and asset, or only a reference or an internal ID?
  5. 2.5Are approvals tied to the exact request content (for example a hash), so approving one request cannot be reused on another?
  6. 2.6Is the approver list reviewed on a schedule, and are leavers and role changes removed within a stated time?
03

Signing: does the signer see what executes

  1. 3.1Does each signer see the destination, amount and asset on a screen or device that the instruction server and the operator's laptop cannot alter?
  2. 3.2Is the signed transaction compared, byte for byte or by field, with the approved request before it is broadcast? By which component, and is that component independent of the one that built the transaction?
  3. 3.3If the instruction server or the vendor's interface were compromised, what could the attacker add to, change in or replay on a request? Has anyone tested it?
  4. 3.4Where are keys or key shares held, and which people and systems can reach each one? Can one person reach enough to sign alone?
  5. 3.5Is there a documented key ceremony, with evidence kept, for generation, rotation and recovery?
  6. 3.6Are pre-signed transactions, durable nonces or standing approvals in use? If yes, who can use them and how are they revoked?
  7. 3.7For multisig or MPC, are owners, thresholds, modules, delegates and policies exported and reviewed regularly, and is a change to any of them an alert?
  8. 3.8If you use an HSM or similar device, are signing keys generated inside it and non-exportable, and is that enforced by the device configuration rather than by procedure?
  9. 3.9Do HSM administration actions (policy changes, backup and restore, firmware or partition changes) need a quorum of separate people, and are they logged to storage that the HSM administrators cannot edit?
  10. 3.10Is the signing policy (limits, destination allow-lists, approvals) enforced inside the HSM or its signing application, so that a compromised caller cannot bypass it?
  11. 3.11If you use MPC, do the parties that hold shares run in independent administrative domains (different operators, cloud accounts or vendors), so that compromising one domain cannot reach the signing threshold?
  12. 3.12Does each MPC node verify the content of the transaction it signs, independently of the coordinator that built the request?
  13. 3.13Are share refresh, node replacement, threshold changes and recovery of a lost share governed by a quorum, tested, and alerted on?
04

Limits and detection: what stops a very large outflow

  1. 4.1Are there per-withdrawal, per-hour and per-day limits on hot-wallet outflow, enforced outside the application that creates the withdrawal?
  2. 4.2Is there an automatic hold or circuit-breaker when outflow exceeds a threshold or deviates from the normal pattern, and who can release it?
  3. 4.3Is a withdrawal to a new or unusual destination treated differently from a repeat one?
  4. 4.4Would you detect an altered request before broadcast, and how quickly after broadcast would a human be paged?
  5. 4.5Is there a tested, written procedure to freeze withdrawals, and can it be executed by someone who is not the person who raised the incident?
  6. 4.6Is the balance of the hot wallet capped, and what moves funds to it from warm or cold storage and under whose approval?
05

Ledger consistency: does what leaves match what is owed

  1. 5.1Is the user balance debited and the withdrawal locked in one atomic step, so a withdrawal and a concurrent order cannot both spend the same funds?
  2. 5.2If a withdrawal fails, is cancelled or is retried, is the lock released exactly once?
  3. 5.3Is every withdrawal request idempotent under retries, timeouts and duplicate submissions, and what is the scope and lifetime of the idempotency key?
  4. 5.4Is there a regular reconciliation between the internal ledger, the on-chain wallet balances and any custodian's records, with a named person who reads the exceptions?
  5. 5.5Are fees and rounding applied in a defined direction, with the unit and precision per asset written down?
  6. 5.6Can deposits that arrive on-chain be credited twice, or credited and then reorganised away?
06

Third parties: who else can touch the path

  1. 6.1Do you have an inventory of every vendor, contractor and service that can read, queue, alter or sign a withdrawal?
  2. 6.2What does each vendor's staff access reach: the request queue, the signing environment, both? How is it granted, logged and reviewed?
  3. 6.3Is a vendor's production environment a path into yours? If it were compromised, what is the worst a request could be changed into?
  4. 6.4Does each vendor contract state security incident notice times and your right to evidence of their controls, and is it exercised?
  5. 6.5Have you tested a recovery from a vendor outage or exit without moving funds in a hurry?
  6. 6.6Who in your organisation owns each vendor relationship for security, not only for the contract?
07

Change and recovery

  1. 7.1Is a change to the withdrawal path (code, config, signing policy, vendor) reviewed by someone other than its author before release, with the approval recorded?
  2. 7.2Can one engineer deploy a change to the withdrawal path, or to the systems that construct transactions, without a second person?
  3. 7.3Is there a tested way to roll back such a change quickly?
  4. 7.4Are logs for the path kept long enough, and kept where an attacker with admin access to the application cannot edit them? Is the retention period decided, not default?
  5. 7.5Do you rehearse a withdrawal-path incident, including who decides to stop withdrawals and who talks to the regulator?
—

Reading your answers

  • A "no" in sections 2 and 3 deserves attention first. Those are where the content of a request can be changed on its way to the chain.
  • An "unknown" counts as a "no" until evidence exists. Finding out is itself the work.
  • There is no score on purpose. A number invites a pass mark, and there is none.

Want a second pair of eyes?

An independent review answers these from evidence in your systems, and reports what it confirms and what it cannot. For third parties, use the vendor access checklist. See withdrawal-path review: scope and method.

Request a scoping call Email for an editable copy