Cryptocurrency and Digital Asset Security

Digital asset platforms fail at the seams: between the trading engine and the withdrawal path, between the signing service and the approval workflow, between what the key ceremony documented and what operations actually does on a Friday evening. Our assessments treat key material and withdrawal authorisation as the crown jewels and work outwards. We review hot, warm and cold wallet architecture, HSM and MPC configuration where present, deposit crediting and confirmation logic, withdrawal approval workflows and their limits, address allowlisting, and the internal transfer paths that often sit outside the main control set. Blockchain-specific issues such as chain reorganisation handling, replay exposure and token contract behaviour are assessed against the specific chains in scope.

What the engagement covers

Digital asset platforms concentrate irreversible risk. A payment platform that authorises a fraudulent transfer has a reconciliation problem; a custodian that authorises a fraudulent withdrawal has lost the asset. Our assessments therefore start from key material and the withdrawal authorisation path and work outwards, rather than treating custody as one component among many.

Scope typically covers wallet architecture across hot, warm and cold tiers; key generation, storage, backup and recovery; the withdrawal request, approval and signing workflow; deposit detection and crediting logic; the trading or transfer application and its APIs; and the internal operational paths — treasury movements, rebalancing, manual interventions — that frequently sit outside the documented control set.

Key management

We assess key management against what the organisation has documented and against what it does in practice, because the gap between the two is where incidents originate. For HSM deployments this covers key ceremony evidence, quorum configuration, role separation between key custodians and platform operators, and whether the HSM policy actually constrains what the signing service can request. For MPC deployments it covers share distribution across genuinely independent failure domains, the policy engine that authorises a signing round, share refresh procedures, and recovery in the event that a share holder is unavailable.

Recovery deserves specific attention. A backup scheme that no one has exercised is a hypothesis. We review whether recovery has been tested, who can perform it, whether the procedure requires the same quorum as normal operation, and whether a recovery event would be detected and alerted rather than appearing as routine activity.

Withdrawal authorisation

The withdrawal path is examined as a chain: request creation, validation, risk scoring, approval, signing, broadcast and confirmation. At each link we test whether the control can be bypassed by entering the chain further along, whether limits are enforced server-side and atomically, whether approval thresholds can be satisfied by a single compromised operator account, and whether address allowlisting can be circumvented through a change window or an administrative override.

Race conditions receive particular attention because they are common and expensive. Concurrent withdrawal requests that each pass a balance check before either debits, refunds processed in parallel with a withdrawal, and limit counters that reset on a boundary rather than a rolling window have all appeared in real platforms. These are tested actively, within the agreed rules of engagement, on a non-production environment where one is available.

Deposits and chain behaviour

Deposit crediting is assessed against the specific chains supported. Confirmation depth policies are reviewed against the reorganisation characteristics of each chain rather than a single global value. We test handling of chain reorganisations, replay across forked networks, transaction malleability where the chain permits it, and the treatment of non-standard transfers — token contracts with transfer fees, rebasing supply, blocklist functions, or callback hooks that re-enter the crediting logic.

For platforms supporting token listings, we review the process by which a new asset is onboarded: whether contract review is mandatory, what is checked, and whether the listing decision can be made without the security function.

Reporting

Reports are structured around loss potential. The executive summary states, in plain terms, which findings could result in asset loss, which could result in service disruption, and which are hygiene issues. Asset-flow diagrams accompany the technical findings so that a reader who is not familiar with the platform can follow how a weakness translates into a withdrawal that should not have happened. Each finding carries a CVSS 4.0 vector, with the business consequence stated separately where the score does not reflect it. Following remediation we retest and issue an attestation suitable for banking partners, auditors and supervisory authorities.