Cold storage setup for private keys of crypto projects

Where protection breaks: weak points of cold key storage

The most common point of failure is the private key that lives where it signs.

As long as the service keeps the key on disk next to the application, a key leak from a hot wallet starts with one vulnerable dependency or one extra access to the server — and after that, transactions are signed not by your code.

There is no reverse operation on the network: a withdrawal is confirmed irreversibly, and “returning it as it was” is technically impossible.

The second failure is the lack of separation of signing rights. When all operations go through one key, a client payout and a transfer of contract ownership are signed with the same authority.

Insider access to keys in such a scheme is almost unrestricted: whoever has access to the server also has access to funds, and incident investigation comes down to finding who had the technical ability to do it.

The third is a key backup in plaintext: in a repository, in a database dump, in an administrator’s note. The fourth is discovered last of all — the absence of a recovery procedure.

Loss of access to the wallet comes not from an attack, but from the storage medium failing and no one left to assemble a signing quorum.

The cost of all these failures is the same: funds leave without the possibility of dispute, and the project is left with contract reissuance and a conversation with token holders.

That is why below we examine how this is closed — from signing isolation to a verifiable recovery procedure.

Isolated signing: what changes in protection and operations

Isolated signing turns cold key storage from an archive into a working mode: the key no longer lies in the memory of a service accessible from the network.

A transaction is assembled on the host and goes to offline signing by a separate environment, and only the signed result comes back — the private key never leaves the device in any form.

Key access window

Previously the window was permanent: while the service runs, the key is accessible to any process with rights to the file or storage. After the transition, the window narrows to a signing session — tens of minutes for a specific task.

Between sessions the key is sealed, export is blocked by policy, and an export attempt is already an event for investigation.

Along with the window, a whole class of security failures goes away: build compromise, leak through logs and memory dumps, contractor access to the server, theft of a copy of the key directory. Previously each of them led to a leak of the entire key set at once.

Wallet access recovery stops being a matter of luck: the key is split into shares using the SLIP-0039 scheme and reconstructed by threshold, for example 3 of 5. The procedure is rehearsed on staging in advance, so during an incident it takes an hour, not days.

Audit of signing operations becomes verifiable: the log records the initiator, transaction fingerprint, device and result, is written on the module itself and sent to an external event collector. It shows the share of rejected operations and the time from request to signature.

Offline storage methods: comparison of approaches and limitations

The choice of offline storage method depends not on cryptography but on the key usage mode: how many signatures per day it serves and how many people are allowed to access it.

A hardware wallet is convenient while there is one signer; a transaction signing module is for when operations flow continuously.

Multisignature with role separation divides authority between operator and treasurer and removes a single point of failure. An offline key carrier and a backup splitting scheme solve a different task — recovery of key material after device loss.

Combining approaches is possible and necessary: the hot environment signs routine operations within the limit, the cold one signs large withdrawals.

The limitation is the same for all — access policy and a proven recovery process; without them any scheme degrades to one person with a storage medium on their desk.

Implementation procedure: from audit to handover to operations

Implementing cold storage is not buying devices but a sequence of work where each stage ends with a verifiable artifact. The order below is arranged so that the private key never ends up on a network-accessible machine at any step.

1. Audit of key handling. We compile an inventory: how many keys and addresses, who initiates transactions, where backups are stored and who has seen them. The output is a list with criticality class and a map of current risks.
2. Role separation scheme. We separate the operation initiator, approver and key share holder. For significant addresses we set an m-of-n signature threshold: compromise of one participant does not allow funds to be withdrawn.
3. Device setup. Key generation on an isolated device without a network interface, recovery phrase on a physical medium, shares distributed across different storage locations.
4. Signing test on a test environment. We run the full cycle on a testnet: transaction assembly, offline signing, broadcast, address and amount verification. Separately, we make sure signing is impossible without a quorum.
5. Key recovery policy. We define how and by whom access is restored if a device or share is lost, and conduct a training recovery — an unverified procedure is not considered working.
6. Handover to operations. We transfer the key map, instructions for the on-call shift, rotation and device decommissioning procedure, and assign responsible persons.

Then ongoing support remains: rotation, adding new addresses and scheduled repeat recovery checks.

What the client retains: configurations, schemes, policies

At the output the client receives not a set of one-off actions but a working cold storage environment: a device where the key never leaves the secure element, and procedures by which the shift operates it. Six months later, a person not involved in the setup should be able to use this environment.

• Signing flow diagram — who initiates the operation, where the unsigned transaction is assembled, on which device it is confirmed and how the result is returned to the network.
• Key access matrix — roles and separation of duties: who initiates, who approves, who sees only the address, how many signatures are required for a transfer.
• Key rotation policy — scheduled intervals and triggers for unscheduled replacement (holder departure, suspected compromise), procedure for removing the old address from circulation.
• Access recovery instruction — a step-by-step scenario for loss of a device or unavailability of one holder, mandatory with verification on a separate environment.
• Documentation on signing procedures — request form, checklist before confirmation, escalation procedure for disputed operations.
• Configured devices and media with mnemonic phrases — initialization procedure, copies distributed across geographically different locations, accounting and media change procedure.

We hand over everything in a form suitable for external audit: the security service or investor sees that key control does not rest on one person and one folder.

Case: separated roles and removed the single point of failure

In a project with daily transaction issuance, the signing key was stored in one wallet, and four people had access to it — including contractors who no longer worked with the team.

This is a classic single signing point of failure: compromise or loss of access stopped operation issuance entirely, and the logs could not show who exactly confirmed a transaction.

What was changed

Roles were split into three environments — treasury, security and operations — and each received separate hardware storage Ledger with its own key.

Signing was moved to multisignature with a 3-of-5 threshold: a transaction is assembled only when holders from different roles confirm it, and one key no longer gives full control over funds.

Two backup keys are stored offline with different holders, so the loss of one employee does not block work.

Metrics before and after

The number of people with full access to the key decreased from four to three signers with separate permissions.

Transaction issuance previously involved correspondence and manual confirmation — hours passed from request to signature; now the threshold is assembled in parallel and issuance fits within minutes.

Recovery after loss of access shrank from weeks to one day: it is enough to assemble the threshold from the remaining holders and reissue one key without affecting the others. Dependency of signing on one person is fully removed.

How does hardware signing differ from multisignature?

These are two different layers of protection, and they do not substitute for each other. Hardware signing is about isolating the device from the network: the key is created and remains inside the secure chip, the transaction goes for signing, and only the signature comes back. Compromise of a workstation or traffic interception no longer exposes the private key.

Multisignature solves a different task — distributing trust among holders. The address is configured so that withdrawal requires, for example, three of five signatures, and one compromised or lost key does not move funds.

But each key in the set is still stored somewhere: if it lies as a file on a network-accessible server, the scheme is devalued — the attacker only needs to repeat the same technique.

Therefore in practice a combined protection scheme is used: hardware signers at several holders, a multiple-signature threshold plus policies — amount limits, recipient address whitelist, execution delay for large withdrawals. Then theft of one device or pressure on one person does not give access to funds.

The risk delineation is simple. Hardware signing removes the risk of key leakage from infrastructure, but does not save from device loss, holder coercion or an error in the policy itself.

Multisignature removes the risk of a single point of failure and collusion, but gives nothing if keys are on network-connected machines.

Neither approach cancels the procedural part: role separation, signature log, backups of the mnemonic phrase on offline media, holder rotation. Short answer: hardware signing and multisignature cover different failure classes, and for treasury addresses we design them together.

Technical doubts: common implementation questions

Technical objections usually surface not at the start but at the handover to operations stage: who signs if the holder is unavailable, what to do when the responsible person changes, and how to make sure access restrictions work not only on paper. Below are answers to the questions we most often resolve before, not after, launch.

What to do if the key holder is unavailable?

The threshold scheme is built so that the signature can be assembled without any one participant — for example, a 2-of-3 quorum. If unavailability is prolonged, the shares are reassembled to a new responsible party, and the previous one is annulled. Separately, we fix the policy: waiting window, escalation procedure, who makes the decision.

How to verify that access restrictions actually work?

We conduct exercises: we try to assemble a signature without a quorum, with someone else’s share, from an external network. All attempts must fail and be recorded in the audit log. We regularly reconcile logs with the policy and run a test transaction along the standard path.

How is the responsible person for keys changed?

Through a rotation ceremony: the new holder generates their own share, the old one is destroyed in the presence of witnesses, and the key and addresses remain the same. No stage happens alone — this excludes substitution and allows proving the legitimacy of the change.

How is the backup of key material stored?

Copies are distributed geographically and stored on media resistant to external influences, each part separate from the others. Once a quarter we check recovery on a clean machine: until the copy is deployed and has signed a test operation, it is considered non-working.

Let's discuss the task: we'll return with an estimate and work plan

An accurate estimate of the scope of work rests on input data, not general wishes.

To return with a key protection implementation plan, not an abstract list of measures, we need to see the current key handling scheme: where they are now, who accesses them and for what reason, how operations are signed, and what volume of assets the environment serves. Describe this in free form; we will clarify the details in correspondence.

At the output you get:

• Audit of the current environment: key storage map, access channels, bottlenecks and points where signing is done manually or from a machine with broad access.
• Target key handling scheme — with role separation, confirmation thresholds and an explicit boundary between hot and cold parts.
• Key protection implementation plan in stages: first critical assets and mandatory checks, then operational conveniences.
• Backup and access recovery policies, including the procedure for loss of some custodians.
• Access matrix and operation logging: who, when, at whose request and after what check signed the operation.
• Post-launch verification procedure: how we make sure signing proceeds normally and extra people do not have access to keys.

We discuss the signing task according to your operating mode — one-off operations, regular payouts, multiple signers. Describe where keys are currently stored and what is critical not to lose — we will return with a scope estimate and stage schedule.