Turnkey non-custodial wallet development from scratch

Why a non-custodial wallet loses keys and access

The classic failure of a hastily assembled non-custodial wallet is one private key for all operations. It sits in the service config or in an encrypted file next to the decryption password, and while the load is small, the scheme holds.

As soon as hundreds of signatures per day pass through it, losing the private key stops being a hypothesis, and there is nothing with which to restore access: the backup is either missing or taken from the same server.

The second source of failures is not technology but access. An engineer leaves, taking the seed phrase or the password to the key storage, and the company loses the ability to sign transactions along with control of the balance.

Proving who disposed of funds and on what basis also fails: operation logs are scattered across services and do not reconcile with one another.

A separate category is the lack of separation of signing roles. When key storage is arranged as one shared secret, the employee initiating a payment and the one confirming it act under a single account, and internal control disappears.

A threshold scheme with multiple signers and a confirmation policy requires the consent of independent key holders — this class of risks goes away.

This is the price of the risks of self-custody, which people usually remember after an incident. We examine how it is closed: an isolated perimeter for keys, separation of signing roles, verifiable access recovery, and an operation log suitable for resolving disputed cases.

What changes in working with assets after implementation

A routine operation — a transfer, changing limits, adding a signer — stops being a messenger chat.

The signature is collected inside the application: the initiator sees how many confirmations are required and who has already provided them, and the transaction goes to the network within minutes.

Manual approvals do not grow with the number of counterparties, because thresholds are set by the wallet's own rules, not by agreements in a chat.

Key separation closes a separate class of failures — theft of one device or leakage of one phrase. A multisignature scheme requires a specified number of signatures from a set of holders, so neither an employee nor a contractor with access can withdraw funds alone.

Losing one carrier does not stop operations: the remaining participants retain the quorum and continue operations without reissuing.

Access recovery time is measured in minutes, not days of correspondence with service support. The backup phrase is generated according to the open standard BIP-39, so the wallet can be restored in any compatible application and is not tied to our code or someone else's server.

Storage autonomy means that keys remain with the owner, and the unavailability of an external service does not block assets.

Because of this, the cost of downtime stops being a value that cannot be assessed: the unavailability window shrinks from hours to minutes, and each operation leaves a verifiable trace in the signature log.

We record these metrics before and after implementation — they show what the transition delivered, rather than general promises.

Non-custodial wallet vs custodial and hybrid

The choice of an asset storage model comes down to two questions: where the private key physically lives and who can initiate a signature. Custodial storage with a provider relieves the team of caring for keys, but access to funds begins to depend on a third party's policy.

A non-custodial wallet is built around a threshold: the key either is never assembled in full on any node, or is split between hot and cold environments. Below are the alternatives that are actually chosen at the start of a project, with their applicability boundaries.

In practice, a combination is more often chosen: the hot environment handles frequent small operations, while hardware isolation holds the reserve.

The threshold and set of signers are fixed at the start — changing the model later means reissuing keys and a new procedure, not editing settings.

How we run the project: from threat model to handover

A non-custodial wallet project begins not with the interface but with the question of what we are protecting and from whom.

The stages follow strictly one after another: the threat model and key scheme are agreed upon before the first line of code, otherwise the architecture has to be redone along with the storage.

1. Analysis of use cases and threat model. We fix who controls the key, where it lives, and which channels we consider trusted. The output is a prioritized list of threats and verifiable security requirements.
2. Key scheme design. We choose how the key is created, split, and recovered: a single mnemonic phrase, a threshold scheme with multiple holders, or a hardware carrier.
3. Implementation of the signing core and storage. Key material never leaves the user's device, transactions are signed locally, and critical paths are covered by checks immediately.
4. Testing on a test environment. We run through recovery, device loss, data substitution, and connection loss in an isolated environment — separately checking whether anything extra leaks out.
5. Solution acceptance. We compare the result against the original threat model using criteria fixed before work started, not the impression from a demonstration.
6. Handover of source code and documentation. We hand over the code, interaction diagrams, key scheme description, and build and update instructions — support is possible by the customer's team.
7. Wallet implementation and support. We run the release cycle and respond to requests, closing what only manifests with real users.

Project artifacts: key schemes, regulations, documentation

The project ends not with a demonstration of a working application but with the handover of a package by which your team can operate the wallet, pass audits, and change contractors without losing context. Below is what physically remains in your repository and internal knowledge base.

• The wallet's source code in full: client modules, transaction generation and signing, build from the repository with a single command — with no parts left "on the contractor's side."
• Infrastructure diagrams: which nodes are under our control, where key material is stored, what happens when each node is unavailable, and how this affects operations.
• Access policies: who and through which channel gets into environments, where the login log is kept, how quickly access is revoked when an employee leaves.
• Role matrix: the "role — allowed actions — required confirmation" mapping, including higher-risk operations: release, changing limits, recovery.
• Key rotation regulation: frequency, who initiates replacement, how the fact is recorded and confirmed that the old key is no longer accepted.
• Recovery and rollback procedure: scenarios of access loss, compromise of one of the signing parties, return to a previous build with state integrity verification.
• Wallet documentation: architecture, data flows, external dependencies, and support service instructions with analysis of typical user requests.
• Handover package for a new contractor: code entry point, history of decisions made, list of accesses and tasks where the owner's involvement is required.

We accept the package together with you according to a checklist: each item either exists in your environment or has a written justification for why it is not needed.

Case study: a wallet for a service with a payment flow

The customer is a payment service with a flow of incoming and outgoing operations.

At the time of the review, the wallet operated in a semi-manual mode: keys were stored in one place, the on-duty engineer assembled and signed transfers by hand, and any large debit was approved in correspondence. Some operations were delayed, and investigating a single key-related incident took almost a day.

We rewrote the signing environment: keys were distributed across independent storages with a hardware component, confirmation rules by amount and recipient were added, and responsibility was separated between services.

The bulk of operations is now handled by an automated scenario, while human involvement remains where it is justified by risk — large amounts and new recipient addresses. The scheme was checked against the mobile wallet checklist from OWASP.

Metrics before and after

The main shift is not the speed of an individual transfer but the class of failures.

Automation of confirmations removed routine from the on-duty engineer and eliminated the cause of nighttime investigations: limits and signing rules are described in configuration, not in instructions for a person, so the system's behavior does not depend on the shift.

Configuration branches are versioned, so returning to the previous signing scheme remains possible without rebuilding the wallet.

How does hardware key isolation differ from software?

With software key storage, the private key sits in an encrypted storage on the workstation itself, and transaction signing is performed in the same process where the key is decrypted. While the machine is clean, the scheme works unnoticed.

But any malware with access to the process memory gets both the key and the ability to sign — separating these two events is technically impossible.

Hardware isolation breaks this link: the private key is generated and remains inside a separate chip and physically never leaves the device; only the finished signature goes out. Each operation is confirmed on the device itself.

Compromise of the workstation ceases to be compromise of the key: the attacker sees addresses and amounts but can no longer sign a transfer without physical access.

Where it is excessive. If signing happens automatically — scheduled server payouts, rebalancing, trading operations — there is no person with the device at the moment of signing, and such a scheme simply does not fit. For small operational amounts, the process overhead does not pay off either.

Therefore the choice is determined by the threat model, not by the formula 'more reliable or more convenient.' In practice we build a hybrid: a hardware key for cold storage and large transfers, a software one for operational expenses with strict limits and role separation. First we describe exactly whom we are protecting against, and then choose where the key lives.

Technical doubts: keys, backups, audit

Engineering objections to a non-custodial wallet are usually the same: what happens if a key share is lost, will the system survive a change of signing scheme, who is responsible for updates after handover. We answer briefly on each point.

Can the signing scheme be changed later?

The signing module is separated from storage logic and operation history, so changing the scheme does not require reissuing the wallet. The transition is step-by-step: new addresses are introduced in parallel, old ones remain operational until funds are fully moved.

How is code correctness verified?

We run access recovery scenarios on a test environment, including negative ones: lost share, corrupted copy, incorrect build order. Separately, we perform an independent code review and a reproducible build — the customer builds the same artifact from the source code.

Who is responsible for updates after handover?

Releases are signed, with rollback instructions; updating the signing module happens without stopping the wallet. After that, an agreed support regulation applies: we notify about critical changes in networks and release compatible versions.

Let's discuss the task: what to send for an accurate estimate

The accuracy of a wallet development estimate is determined by the input data, not by the number of screens in a mockup. Below is the minimum set that allows us to fix the architecture, break the work plan into stages, and give timelines without a buffer 'for the unknown.'

• Use cases: who owns the keys, where the boundary between the service and the user runs, which operations are standard and which are one-off (one signature, several signatures, a wallet managed by several parties).
• Number of roles and access model: administrator, operator, auditor, end user — this determines both permission separation and the scope of pre-launch checks.
• Recovery requirements: code phrases, recovery through trusted persons, key splitting among custodians — each option has its own support cost and its own class of risks.
• Supported networks and assets: the list at the start and what is planned to be added later — this defines the integration layer and the scope of test benches.
• Infrastructure constraints: own nodes or external providers, availability requirements, placement in your environment or on our side.
• Integrations: exchanges, payment gateways, transaction analytics, corporate systems — what already works and in what form accesses are opened.
• Timeline to a working environment: the date by which a prototype, closed testing, or public release is needed — the order of stages depends on it.

Describe the task in free form and attach any existing diagrams and accesses — we will come back with an estimate, a work plan, and an architecture proposal.