Custody and Key Management for Crypto Products

A custody design is an operational control system whose final act happens to be a cryptographic signature. Protecting a private key does not establish that the transaction presented for signing is authorised, correctly encoded or consistent with customer balances. Conversely, a strong withdrawal approval workflow is ineffective if key material can be exported or a signer accepts an ambiguous payload. Architecture must connect account entitlements, policy evaluation, transaction construction, independent approval, signing, broadcast, chain observation and ledger reconciliation. Each boundary needs evidence and a failure mode. Treating wallets as an isolated infrastructure component leaves the most consequential decisions in application code and informal operating procedures.

Separate liquidity from reserves

Hot wallets support routine deposits, consolidations and withdrawals while connected to production systems. Cold wallets reduce online exposure by keeping signing capability offline or under a deliberately isolated process. The separation is a policy boundary, not a pair of labels. Define which assets and transaction types each tier supports, how balances are replenished, who can initiate a transfer, and what happens when hot liquidity is insufficient. Warm tiers can moderate operational friction but add another policy and reconciliation surface. Limits should derive from expected obligations and risk appetite rather than a universal ratio. Every movement between tiers remains a custody transaction requiring intent, approval and accounting.

Choose a key architecture with a threat model

Single keys, multisignature scripts and threshold signing distribute trust differently. Native multisignature may produce visible on-chain policy and depend on asset-specific script support. Threshold schemes can present a conventional address while preventing any participant from assembling the complete key, but introduce protocol implementation, participant coordination and recovery complexity. A hardware security module can generate and use non-exportable keys within a controlled boundary, enforce authentication and produce audit events. It does not understand business intent unless the surrounding system supplies and verifies meaningful policy. The choice should account for supported chains, transaction throughput, governance, disaster recovery, insider threats and the ability to test the complete implementation.

Key generation is a controlled ceremony

Generation establishes the roots of custody and should be reproducible as a procedure without making secrets reproducible. Record approved software and device versions, entropy sources, participants, roles, environment checks, public identifiers and verification outcomes. Secret shares or backup material need tamper-evident handling, geographically and administratively separated storage, and an inventory that can be checked without exposing contents. No participant should be able to substitute an address unnoticed. Independently derive and verify public addresses through more than one trusted path before accepting deposits. A ceremony that produces keys safely but leaves no reliable recovery evidence creates a delayed failure rather than a secure system.

• Bind every signing request to an immutable transaction intent and a unique workflow identifier.
• Decode destination, asset, amount, network, fees and contract calls before policy evaluation.
• Separate initiation, approval, signing administration and reconciliation wherever authority permits.
• Keep key backups and recovery participants outside the same failure domain as active signers.
• Reconcile chain observations, wallet inventory and the internal customer ledger independently.

Signing starts with canonical intent

The signer should receive a canonical request derived from an approved withdrawal, not an arbitrary byte string supplied by an application server. Transaction construction must validate network identifiers, destination formats, token contracts, nonce or unspent-output selection, fee bounds and change addresses. Human approval needs an intelligible decoded view while the cryptographic control binds approval to the exact payload. If reconstruction after approval can alter fees, recipients or calldata, the approval is ceremonial. Contract interactions deserve typed decoding and allowlisted methods because a nominal token amount does not reveal approvals, delegate calls or unlimited allowances embedded in calldata.

Withdrawal policy needs composable rules

Policy evaluates the transaction and its context: customer authentication state, destination history, asset, amount, velocity, account restrictions, risk review and current system posture. Rules should be explicit, versioned and deterministic enough to replay. An allowlist can govern known operational addresses, but customer withdrawals often require a different path with cooling periods or additional review after destination changes. Aggregation matters because splitting a movement into smaller requests must not bypass a limit. Overrides need narrow scope, expiry, named approval and a reason. A policy engine should fail closed when required data is unavailable while giving operators a visible queue rather than silently abandoning obligations.

Approval must remain independent

Dual control only exists when approvers have independent credentials, sufficient context and no ability to approve their own initiation through another channel. The record should contain the exact intent, policy version, decoded transaction, requester, approvals, timestamps and any exception evidence. High-risk flows may require approval from separate organisational roles or devices. Avoid sending approval links that reduce the decision to a generic confirm button; destination and amount should be verified through a trusted interface. Approval fatigue is a design failure. Queues need grouping and prioritisation without allowing bulk action to conceal materially different destinations or policy exceptions.

The meaningful object of approval is the exact transaction intent under a stated policy, not a notification that some withdrawal is waiting.

Broadcast and confirmation are separate states

A valid signature does not mean a transaction was accepted, propagated or final. Record construction, approval, signature, broadcast attempts, node responses, inclusion and confirmation as distinct states. Idempotency prevents a retry from creating another economic transfer, while chain-specific replacement mechanisms require deliberate handling rather than generic resubmission. Reorganisations can reverse an observed deposit or withdrawal, and account-based chains can leave nonces blocked by an earlier transaction. Use multiple observation paths where appropriate and define finality by asset and transaction type. Customer-facing status must follow the actual state machine instead of presenting every broadcast as complete.

The ledger is not the blockchain

The chain records asset movements between addresses; it does not record the custodian's liabilities to individual customers. Maintain a double-entry internal ledger and map controlled addresses, pending transactions, fees and adjustments to it. Reconcile wallet balances to chain data and reconcile aggregate customer liabilities to controlled assets, investigating differences rather than posting unexplained balancing entries. Deposits need address ownership, asset recognition and confirmation policy. Tokens arriving on unsupported contracts, dust, airdrops and chain forks require explicit treatment. Network fees and consolidation transactions also move controlled balances without representing customer withdrawals. Reconciliation must understand those categories to avoid treating operational movements as unexplained loss.

Asset integrations expand the trusted surface

Each chain introduces address rules, signing semantics, fee markets, node behaviour, finality and upgrade risk. Token custody adds contract identity, decimal handling and potentially transfer restrictions. Integration tests should use authoritative protocol fixtures and independently verify encoded transactions before any production key is enabled. Node providers are useful but should not become the sole source of truth for balances or broadcast outcomes without understood failure handling. Chain upgrades, contract migrations and network splits need an ownership process that can pause affected actions. Adding an asset is therefore a custody change with security, ledger and operating requirements, not merely another symbol in a product catalogue.

Recovery must be practised

Recovery covers more than lost hardware. It includes unavailable participants, corrupted policy state, a compromised signer, inaccessible backup storage, network outage and the need to rotate from a suspected key. Procedures should specify authority, quorum, clean-room conditions, software sources, destination verification and how customer liabilities remain serviced during interruption. Test recovery with non-production keys and representative chain transactions, then verify that restored controls and audit records remain intact. Emergency actions, such as moving reserves to a new address, still require controlled intent and reconciliation. A plan that has never exercised the dependencies around its secret shares is documentation, not demonstrated recoverability.

Operate custody as a control plane

Monitor signer availability, policy decisions, rejected requests, hot-wallet liquidity, nonce or unspent-output health, chain observation lag and reconciliation differences. Logs must avoid secret material while preserving identifiers that connect application intent to signature and ledger entry. Administrative changes to policies, signers, assets and destinations require the same preparation, approval and effective history as financial actions. Incident response should be able to suspend narrowly by asset, workflow or signer instead of forcing an unsafe choice between normal operation and total shutdown. Sound custody emerges from these linked controls: keys resist extraction, transactions retain meaning, authority is divided, and every movement can be explained against both the chain and customer obligations.