Lido fork for liquid staking: development, adaptation, bootstrap

Lido fork development: bottlenecks of liquid staking

A fork of a liquid staking protocol breaks not at the contract deployment stage, but under the first real stress.

A withdrawal request enters a queue that hits the throughput of the base layer: only a share of validators can exit at the same time, and if a large holder withdraws more than the liquidity buffer can return in time, funds get stuck for days and weeks.

The user sees the status “processing,” the team sees a growing tail of requests that cannot be closed without external liquidity.

The second bottleneck is exchange rate divergence. The balance of the exchange token is recalculated based on the oracle report, and between reports it lags behind the market price.

Any delay in the report, a disputed result, or a sharp entry/exit of large capital widens the divergence, and the secondary market responds with a discount.

Formally the token is backed, but in practice the holder loses on exit — and this is what destroys trust faster than any bug in the code.

Validator penalties are socialized: slashing of one operator reduces the balance of all exchange token holders, not just the one who ran the faulty node.

Without a separation of responsibility between operators and without a buffer to cover penalties, the loss is spread across the entire body of holders, and their yield sags without a clear explanation.

Under load, settlement delays are added: balance recalculation, reward accrual, and oracle circuit updates begin to lag behind each other, and the data in the interface diverges from the actual state of the contracts.

Desynchronization by itself does not steal funds, but it opens a window for arbitrage against the protocol. We analyze how each of these failures is closed at the fork architecture level.

The effect of an own protocol: measurable metrics

We take metrics before and after: baseline values — on the shared Lido network and on the client's current circuit; target values — after launching an own validator set.

The point is not “it became nicer,” but specific figures: how long the user waits for withdrawal, what share of operations fails, and how quickly the circuit returns to operation after a node failure.

The key shift is in the point of control. In a shared network, withdrawal time is determined by someone else's queue: other operators drain it, and the request waits along with everyone else.

With an own pool, you set the queue length — by the number of validators in a shift and the key rotation order. The same applies to failures: previously it was an external risk, now it is a manageable configuration parameter.

The table shows the main thing: it is not the number of failures that changes, but their class. The scenario where one node or one operator stops all withdrawals goes away — the standby picks up the keys, and the state is raised from the replica without manual intervention.

Three paths: transferring ready-made code, adaptation, assembling modules

Transferring ready-made code, adaptation, and modular assembly differ not by “correctness,” but by what you inherit along with the code: the economics, the validator registry, admin rights, and the set of external dependencies.

The first path is the shortest, but it also transfers someone else's design decisions — they are later overridden with patches, not settings.

The boundary between adaptation and modular assembly runs not by the volume of edits, but by the number of external dependencies.

While fees and reward rules change, adaptation is enough; as soon as an own token issuance model, non-standard withdrawal of funds, or an own validator key circuit appears — there is nothing to transfer, and the modules are assembled anew.

Infrastructure requirements grow non-linearly: adaptation adds an audit circuit and load runs, while assembly adds a validator registry, oracles, and redundancy. Describe the task — we will come back with an estimate and a plan for each of the three paths.

Work order: audit, scheme, setup, verification, handover

Implementing a fork is not a one-time contract deployment, but a sequence in which each stage removes the risk of the next. The order is the same both for a Lido fork for an own protocol and for adapting an already operating scheme — only the depth of elaboration differs.

1. Requirements and current circuit audit. We analyze where and in what form the stake is already placed, which networks and custodial schemes are involved, and what limits are set by accounting and internal policies. The result is a list of restrictions that the scheme must comply with.
2. Designing the fund flow scheme. We fix the path of funds: deposit acceptance, issuance of the receipt token, reward distribution according to the oracle report, protocol fee, withdrawal. We separately describe limits, the pause mechanism, and roles with separated rights.
3. Setting up nodes and roles. We deploy validator nodes, separate signing and management keys into different storages, and set up monitoring for node failure and missed duties.
4. Preparing the test circuit. We run the full cycle on a copy of production parameters, connect wallets, accounting, and venues for the receipt token.
5. Acceptance checks. Scenarios for deposit and issuance, oracle report, withdrawal, validator failure, pause, and contract upgrade — each with an expected result and a run protocol.
6. Operations handover. We provide regulations, the role scheme, and an alert map, describe incident procedures, train the team, and remain on support.

Delivery package: configurations, schemes, issuance regulations

We deliver the work not as a “working protocol in words,” but as a package by which your team can operate the system without us. Everything discussed is recorded in artifacts: from environment files to the procedure for the on-call engineer during a failure. Below is what exactly remains with the client.

• Node configurations: parameters of the consensus and execution layers, separate sets for test and production circuits, hardware requirements with load headroom.
• Fund flow schemes: deposit path to the pool, moment of derivative token issuance, reward distribution, withdrawal queue and limits with balance reconciliation points.
• Role and access matrix: who changes parameters, who signs transactions, separation of hot and cold keys, multisig thresholds, rotation procedure.
• Upgrade regulations: how logic edits are made, who approves them, how they are tested on the test circuit, and how they are rolled back to the previous state.
• Incident response regulations: criteria for stopping operations, on-call duty, response times, recovery procedure from backups.
• Monitoring: list of metrics and thresholds that trigger alerts, and post-incident reviews.
• Operator documentation: step-by-step node launch from scratch, key rotation, recovery after failure.

We hand over the package along with a walkthrough: we show the team where each parameter is located and what will happen if it changes. This way, support does not depend on one person and does not require coming back to us for every question.

Case study: metrics before and after launching a staking protocol

The liquid staking protocol was launched as an adapted fork of an open implementation: the Lido architecture was taken as a basis, while the withdrawal modules, work with validator operators, and share accounting were rewritten for its own rules. Below are metrics taken from the working circuit, not from a demo stand.

What was before the rework

The first version was brought to the network with manual withdrawal queue management: requests were collected in batches once a day, so withdrawal took from two to three days, and on peak days stretched to five.

The share of active validators stayed around 60% — a new node was put into operation only after manual deposit reconciliation and operator confirmation.

About 8% of operations — deposit, withdrawal, reallocation of stake between operators — ended in failures and required a manual re-run.

What was changed

The withdrawal queue module was rewritten: the request processing limit is calculated per epoch, requests are executed in batches without waiting for manual confirmation, and exiting the queue does not block the acceptance of new deposits.

Validator onboarding was automated — the node is raised immediately after deposit confirmation, and stake reallocation between operators follows the specified weights.

The result

Withdrawal time in normal mode is 4–6 hours, at peak — up to a day, meaning the request is no longer a multi-day operation. The share of active validators grew to 93%: deposited funds stopped sitting idle waiting for a manual step.

Operation failures dropped from 8% to less than 1%, and the remainder comes from external provider failures, which are closed by automatic retry.

Re-runs and manual reconciliations have been removed from the process, and discrepancies in share accounting are visible on the dashboard the moment they appear, not a day later.

What to do if the fork is already deployed but liquidity is not growing

In an already deployed protocol — a Lido fork — we start diagnostics from three nodes: stake acceptance, exchange rate, and exit. If the deposit contract is paused or the operator pool limit is reached, the depositor hits a rejection before seeing yield.

Next we analyze the rate: protocol fee, consensus rewards, distribution of income from block execution.

The second common failure is divergence of the rate from the market. An infrequent oracle report creates an arbitrage gap: the share trades at a deviation from the underlying asset, collateral venues increase the discount, and the depositor moves to direct staking.

We rebuild the report frequency and rate smoothing so that the share price does not jump at the report boundary.

Connecting liquidity is parameters, not a campaign: pool depth, range step in concentrated pools, listing on aggregators, recognition of the share as collateral on credit markets.

This works only after the rate is calculated honestly and exit is predictable — otherwise we attract turnover that leaves at the first deviation.

The refinement proceeds without downtime: we upgrade the live protocol behind a proxy layer while preserving the storage layout, roll it out through a governance delay, and keep a second version of share accounting and a migration contract that accepts old and new shares alongside.

Indexers and reporting are switched to dual reading so that the transition does not break the balance history.

Relaunch criteria are metrics, not feelings: the share of stake in the protocol, rate deviation from the underlying asset, pool depth for a large order, withdrawal time. While at least one is out of norm, incentives only mask the hole.

Common technical questions: launch risks and limitations

Before launching a Lido fork, clients check four things: what will happen to funds already placed, whether the system can be kept in a closed circuit, who is responsible for validator penalties, and how to replace the reward calculation module.

Below are direct answers, including protocol limitations that are better to know before launch, not after.

Can the system be launched without going to external venues?

Yes. The operator list is limited, the issuance of liquid wrappers is disabled at the configuration level, and secondary markets are not connected.

The price of this decision is that depth is provided only by own funds; the gain is that dependence on external oracles and external liquidity disappears. External venues are added later, one by one, with a check of their impact on the wrapper rate.

Who is responsible for validator penalties?

The penalty falls on the node operator, and in the fork this is hardcoded in the rules: a share of the operator's reward is withheld as a coverage buffer, and any excess is covered by the insurance reserve.

For external operators, the buffer size and compensation procedure are fixed in the contract and checked by automation — responsibility is not blurred between participants.

How to replace the reward calculation module?

The module is moved into a separate contract and updated through governance with an execution delay: the old and new logic run in parallel until settlements for previous periods are closed.

Before replacement, the update is run on a test network with a copy of the state, and the switch is made at the period boundary so that already accrued amounts are not recalculated.

Let's discuss the task: we will come back with an estimate and work plan

To come back with an estimate and work plan, we need not a list of wishes, but specific inputs.

The target network determines the scope of adapting the Lido fork contracts, the reward model determines the calculation logic and distribution modules, and the set of roles determines the access scheme for critical operations.

Based on the review, we send a document: scope of work by stages, launch timelines, and the responsibility boundary — what we cover and what remains on your side. The estimate is broken down by stages, so you can launch in parts and change the order to suit your priorities.

• Target network and compatibility requirements — determine the contract set and scope of refinement.
• Token parameters and reward logic: protocol fee, yield distribution, issuance and redemption.
• Roles and rights: validator operators, treasury, management committee, who approves critical operations.
• Key and access requirements: signature schemes, limits, separation of powers between participants.
• Integrations: wallets, aggregators, liquidity pools, price data sources.
• Regulatory inputs and user access rules — affect verification and restriction modules.
• What has already been done: audit, prototype, calculations — reduces timelines and removes duplicated work.

Let's discuss the task: describe the current state of the project and a target date — we will come back with an estimate, scope of work, and stage timelines.