Why non-custodial staking fails at withdrawal
Classic scenario: validator assembled, assets placed in non-custodial staking, rewards accrue for months.
And at the moment when funds need to be withdrawn or the validator exited, there is no one to provide the signature: keys and signing roles are consolidated into a single point — one machine, one key directory, one administrator with access to it.
The Ethereum network and other networks with separate signing and withdrawal keys require their formal separation. In practice, the attestation key, exit key, and withdrawal key sit in one storage and are unlocked by one account. As long as the team composition does not change, the scheme works without remarks.
It breaks during shift rotation, revocation of access from an external engineer, or loss of access to the storage: a single signing point of failure turns into a block on asset withdrawal.
At the same time, the assets themselves are listed on the balance and appear available — right up to the first attempt to exit the validator.
The cost of the breakage is not only downtime. The validator continues to receive penalties for missed attestations, and recovery goes through log analysis, assembling keys from backups, and re-synchronization.
The risk of third-party custody manifests not as theft, but as the inability to control your own assets.
We break down how this is closed: signing roles are separated across different perimeters, access is granted on a threshold basis, and validator exit is moved into a separate procedure with testing on a test network.
What changes after separating keys and assets
After separating keys and assets, not only the access model changes, but also the set of measurable parameters by which implementation quality is checked.
The signing key remains with the holder, while asset accounting is maintained separately — the service cannot dispose of funds, even if its infrastructure is fully compromised.
This is the first checkpoint: if the technical ability to sign a withdrawal without the owner remains, separation is not complete.
Next are signing roles. Day-to-day operations, reward withdrawal, and rebalancing are covered by a hot key with a limited policy, while changing the validator set, parameters, or recipient addresses requires a cold key and a quorum.
The threshold scheme distributes shares among independent custodians, so one compromised signing machine does not grant access.
The third point is access recovery time. Backup shares are stored with different parties and assembled according to a described procedure: recovery takes tens of minutes and does not depend on the operability of a single node or correspondence with support. It is verified by a rehearsal — before it is needed in an incident.
Finally, which class of failures goes away. A whole layer disappears: withdrawal freeze, refusal to sign, unavailability of the asset custodian, dispute over who owns the funds. Only failures related to your own keys and contract logic remain — a narrow and predictable set.
Withdrawal ceases to be a manual operation: a request follows a known route, and the withdrawal window is measured in minutes and does not depend on someone else's schedule.
Formats of non-custodial staking and their limitations
Non-custodial staking is primarily about who keeps the keys, not about who operates the equipment. Even with delegation, assets do not go onto the service's balance: only the owner initiates withdrawal.
But the right to dispose of a share and control over its operability are different things, and then the fork begins: who keeps the node in the network, who is responsible for its availability, and what happens to the share during a failure or penalty deduction.
Formats should be compared along three axes — where keys are stored, who is responsible for node operability, and how deeply you manage its parameters. Below are the alternatives that are realistically chosen between at the start.
| Option | When it fits | Limitations |
|---|---|---|
| Validator pool | You need to enter quickly, without your own infrastructure, and keys remain with the owner | You do not influence the pool fee, validator set, or their update schedule; the entry threshold is minimal, and so is controllability |
| Node operator | You do not need your own equipment, but dedicated parameters and reporting are required | Dependence on one operator: their downtime or policy change directly affects your share |
| Your own validator | The asset volume and control requirements justify operation | Full entry threshold: servers, redundancy, monitoring, updates, on-call duty, risk of penalty deduction for misses |
The entry threshold is the main divider between these formats. Your own validator means round-the-clock duty, a second node for cold backup, and a proven update procedure without missing voting rounds.
A pool removes operations entirely, but along with it goes influence over parameters. A node operator is a compromise where part of the responsibility remains with the contractor.
Architecture limitations matter more than yield: the fewer intermediate layers, the lower the risk of losing access to the asset, but the higher the engineering load. We break down how to select this balance for your scenario.
Implementation stages: from key audit to handover of procedures
Non-custodial staking breaks not on mathematics, but on the organization of access to keys.
We conduct implementation as a sequence of verifiable steps: first we record how ownership is structured now, then we design the signing scheme for the customer's threat model, and only then do we write code. Each stage is closed with an artifact that can be checked before moving to the next.
- Key audit. We inventory all keys and shares: where they were generated, where they are stored, who gets access to them, whether there are copies outside the perimeter. The output is an ownership map and a list of discrepancies between the declared and actual model.
- Signing scheme. We select a threshold configuration: how many shares are needed for an operation and how they are distributed among parties. One compromised participant or node cannot withdraw funds alone.
- Role configuration. We separate the operation initiator, signers, and observer, set limits and time windows. Actions enter an immutable log — disputed situations are resolved by facts, not correspondence.
- Withdrawal testing. We run scenarios on small amounts: standard withdrawal, withdrawal when some signers are unavailable, an attempt to operate outside the limit. We make sure the rollback does not leave funds in a suspended state.
- Node monitoring. We set up control of validators and delegation: missed blocks, yield drops, balance discrepancies. Alerts arrive before the problem becomes a loss.
- Procedure handover. We provide documentation: share issuance procedure, rotation, incident actions, responsibility zones. We train the customer's team on the test perimeter.
What remains with you: configurations, schemes, policies, procedures
Non-custodial staking development ends not with a demo launch, but with a folder of artifacts in your perimeter.
We hand over not a "black box," but a description of the system in the form in which your engineer or another contractor can maintain it: schemes, policies, roles, procedures, and recovery procedures.
- Component interaction schemes — who exchanges data with whom, where trust boundaries lie, how the operation path is structured from initiation to confirmation in the network.
- Access policies — which key storages are used, who and through which interface initiates actions, how access is granted and revoked.
- Role matrix — an "operation × role" table: what one on-duty engineer is allowed, what requires a second signature, who owns the decision.
- Versioned configurations — node parameters, monitoring rules, deployment templates: the environment is brought up reproducibly, not "from the engineer's memory."
- Response procedures — missed attestation, node failure, discrepancy with the network, operator compromise: action order, responsibility zone, target response time.
- Documentation and change log — instructions for deploying from scratch, on-duty memo, procedure for withdrawing funds and exiting validation without contractor involvement.
- Acceptance checklist — including test recovery on a clean environment: until your engineer has brought the system up themselves, the handover is not considered complete.
Case: separating signing roles and withdrawing assets without an intermediary
The client is a validator operator who set up non-custodial staking for several dozen wallets.
The signing key and withdrawal key lay in one storage under one role, so any operation with assets went through an intermediary, and an engineer with access to signing could technically initiate withdrawal. Here is what the metrics showed before and after separating roles in the Ethereum network.
Metrics before implementation
Asset withdrawal took from two to three days: the request went to an intermediary, confirmation was awaited manually, and some operations hung until the next business day.
Over the quarter, 5-6 signing incidents were recorded — from re-signing the same dataset to an attempt to withdraw from an address that should not have been accessible.
Access recovery after an engineer change dragged on for days and depended on whether the intermediary would respond.
What was changed and what became
The perimeters were separated: the signing key remained on the validator in a closed segment, and the withdrawal key moved to a separate storage with a 2-of-3 threshold scheme — shares with different holders, and a withdrawal signature can only be assembled jointly.
Now asset withdrawal takes 15-25 minutes without an intermediary or manual confirmations, and no signing incidents remained over a comparable period: every dataset passes through a log tied to a role and operation and is rejected before signing if it does not match the template.
Signing key rotation no longer affects the withdrawal perimeter — a compromised key is changed within an hour, and funds remain with the owner. Access recovery is covered by a one-hour procedure because shares are stored with different people and do not depend on one person.
How does separate key storage differ from multisignature?
Separate storage answers the question of who has the right to dispose of funds, while threshold signing answers how many custodians are needed for a signature to take place.
In the first model, each participant has their own full key, and the rule is checked against a fixed list of signers. In the second, the key is split into shares: a threshold number of them is sufficient for signing, and no single node sees the full key.
Multisignature is transparent: the signer list and threshold are public, and an operation can be examined after the fact to see whose vote blocks it.
The limitation is that the key is stored in full by the owner, so compromise of one machine enables actions on behalf of a legitimate participant: the threshold protects the treasury, but not the vote itself. The computation volume for verifying signatures grows with the number of signers.
Threshold signatures remove both limitations: a share does not allow signing independently, the key is never assembled in any process, and one compact signature goes to the network regardless of the number of shares.
Shares are distributed across hardware security modules of different legal entities and in different perimeters — the module only outputs the computation result, and the share cannot be extracted from it.
The boundary runs along responsibility zones. The question of who is responsible for an operation and how this is confirmed for audit is solved by separate storage and multisignature with an explicit list.
The question of eliminating a single point of failure is solved by a threshold scheme. In practice, they are combined: shares in hardware security modules of different organizations plus a contract that fixes limits and responsibility zones.
Common technical questions about implementing a signing scheme
Before approving a work plan, engineering teams ask the same set of questions: where the signing key lives, what will happen to assets if a node fails, and whether already deployed funds can be transferred without exiting activation. Below are short answers; a detailed breakdown with configurations happens at the design stage.
Who gets access to the signing key?
The key is generated on the customer's side and is never assembled in full: shares are distributed among participants according to a threshold scheme, and a signature is formed only with the consent of a specified number of holders.
Our team configures the procedure and audit, but does not gain the ability to single-handedly dispose of funds or substitute the withdrawal address.
What happens if the node operator fails?
Signing change and planned exit from activation are performed with separate keys that remain with the customer.
Equipment failure leads to missed duties and a network penalty, but not to asset loss: the node is brought up from a saved state, and during a long downtime the asset is withdrawn and returned to operation without haste.
How can already deployed assets be transferred?
If the current scheme allows changing the disposal address, we transfer control to a new address assembled according to a threshold scheme — assets continue to operate, and a full withdrawal is not required.
When control is rigidly tied to a custodian, we plan an exit and redeployment cycle with a downtime window during which rewards do not accrue.
These concerns are closed before the first launch — the asset migration plan and separation of responsibility between parties are built on them.Let's discuss your key storage and signing role scheme
Evaluating such a task is not done "by eye" — it unfolds from your current scheme.
Therefore we start with a review: where validator keys are stored, who initiates signing, how the roles of operator and asset owner are separated, what happens during staking withdrawal, and how well signing thresholds (for example, 2-of-3) match your risk profile. Based on the review, we return with an estimate, work plan, and handover order for operation.
What you keep after this stage:
- A review of the current key storage and signing scheme: hot and cold perimeters, who has access, where the single point of failure is.
- An assessment of the signing scheme and roles: which roles are needed for your risk profile, where they should be separated, and where the current arrangement is excessive.
- A stage-by-stage implementation plan with dependencies between them — what can be rolled out in parts without stopping active validators.
- Work order and responsibility zones: what we cover, what remains on your side, and in what timeframes.
- Handover order for operation: signing and rotation procedures, access recovery procedure, acceptance, and training of your team.
- A list of inputs for the start: role scheme, access to perimeters, signing owners on the customer's side.
To return with an estimate rather than general words, describe the task: how many validators, how keys are currently stored, which signing roles are already set up. This is enough to assemble a work plan and handover order for operation.