Restaking protocol development: where the mechanics break
A typical restaking protocol confidently passes the first days and begins to diverge from the network after two to three weeks.
The issue is not load but share accounting: it is fixed at the time of deposit, while the operator changes the set of services and partially withdraws funds. In solutions built on EigenLayer, the mechanics are the same — only the source of confirmations changes.
Payout failures accumulate in a cascade. The reward is calculated from an old share snapshot, some confirmations arrive with a delay, and rounding during recalculation drives the balance off by fractions of a percent. At first, the discrepancy is masked by manual top-ups — that is why it surfaces only on mainnet.
The protocol architecture must separate three independent layers: share accounting, reward distribution between operators and services, and the operator lifecycle with entry and exit windows.
When all of this lives in a single contract, changing the set of services entails recalculating payouts, and a rollback requires stopping the protocol.
A separate source of failures is non-idempotent event processing: a repeat produces a double credit, a miss produces underpayment that is invisible without reconciliation with network state.
We maintain an event log and reconcile before finalization so that discrepancies are detected before payout, not after a user complains.
Restaking protocol development that withstands this differs not in the contract language but in the accounting model and failure boundaries. Turnkey restaking therefore starts with a map of reward flows and operator exit scenarios, not with code. Below is how this is addressed at each layer.
What restaking provides: measurable effects and timelines
Restaking is measured not by the number of connected services but by three values: the share of operations that run without manual intervention, the median withdrawal time, and the number of support requests about reward calculations. We capture the same metrics before launch — otherwise there is no way to confirm the effect.
A protocol on EigenLayer reuses already staked capital: the same asset secures the base network and additional services. Capital does not need to be withdrawn and redeployed — the return on the same position grows, not the amount of locked funds.
Payout automation covers most of the routine: accruals, protocol fees, and reward distribution run on schedule in smart contracts, and the share of automated operations reaches 9 out of 10.
Manual work remains for disputed episodes and analysis of slashing scenarios — the things that truly require an engineer's decision.
Withdrawal speed is determined by the request queue: we batch requests and process them in a single pass, so the median time is reduced from a day to tens of minutes.
Along with manual calculation, a whole class of failures goes away — double accruals, lost shares, incorrect conversion rates.
The support load drops as a result: position status, accrual history, and queue position are visible to the user, and the question "where is my reward" ceases to be typical.
The first automation effects are noticeable in the first week after launch; stable statistics accumulate over a month.
Implementation options: ready-made modules, fork, custom code
The three paths to a restaking protocol differ not only in time to launch but also in who is responsible for contract behavior afterward.
Ready-made modules provide working primitives, a fork provides an almost ready system with someone else's architecture, and a custom codebase provides full control over share, reward, and slashing accounting.
All three options are compatible with the EigenLayer base layer — the only question is the amount of custom logic.
| Option | When it fits | Limitations |
|---|---|---|
| Assembly from ready-made modules | Standard economics, launch within tight deadlines, pilot on a limited asset pool | The reward model and slashing conditions are set by the module authors; non-standard scenarios require additional scaffolding |
| Fork of an open-source protocol | A fast start with custom parameters and a custom interface is needed | Architectural decisions and known limitations are inherited; updates from the base branch are ported manually |
| Custom contracts | Economics different from standard, custom strategies, requirements for disclosure of logic | The longest cycle to launch and ongoing maintenance with audits |
A practical criterion: as long as the reward and slashing model fits ready-made templates, assembly from modules wins — there is less custom code to verify and maintain.
As soon as custom distribution rules appear, the limitations of ready-made solutions begin to dictate the product economics, and a custom codebase becomes a way to avoid adapting it to someone else's code.
Switching between options is a state migration, so the fork point is fixed before the first deposit.
Workflow: audit, design, assembly, verification, handover
We structure the workflow so that each step relies on a verified previous one: first invariants are fixed on paper, then they move into code, and only then is the system allowed onto the network, where an error costs real assets.
-
Audit of the design and current setup. We analyze which assets and operators are involved, who receives rewards and from what, and where trust boundaries lie. The output is a role map, invariants, and a list of scenarios in which the protocol loses controllability.
-
Design of economics and access rights. We define reward and slashing logic, per-operator limits, withdrawal delays, and administrator roles. We agree on the design before the first line of code: edits here take hours, after launch — migrations.
-
Assembly of the core on EigenLayer. We implement strategy contracts, delegation processing, and reward distribution, and cover execution branches with tests. We separately walk through edge cases: zero deposit, simultaneous withdrawal, operator change.
-
Internal verification. Static analysis, fuzzing, reentrancy scenarios, gas usage measurement on bulk operations — all before network deployment.
-
Testnet. We deploy the full setup, reproduce real deposit and withdrawal flows, and check behavior during node failure and load growth. Only after that — mainnet.
-
Protocol handover. We hand over the repository, diagrams, deployment and upgrade instructions, and train your team. Support for the first weeks on the network is under a separate agreement.
What we hand over: code, diagrams, regulations, access
We hand over not an archive of code but a kit that allows a restaking protocol on EigenLayer to be run without the author: your team or our support can bring up a stand from scratch and investigate an incident using documents, not chat messages.
The kit undergoes acceptance together with you — we verify against the repository and run on-call shift scenarios.
- Source code and infrastructure as code: repositories of contracts, deployment scripts, and node configurations — the build is reproducible in a clean environment.
- Interaction diagrams: the flow of tasks between contracts, oracles, and operator services, trust boundaries, and system behavior during node failure.
- Role and access rights matrix: who changes parameters, pauses stake intake, and withdraws funds; separation of duties between keys.
- Protocol documentation: restaking mechanics, economic parameters, limitations, and extension points — a new engineer joins the project without verbal explanations.
- Maintenance procedures: scheduled work, contract upgrades, key rotation, backup, and recovery verification.
- Instructions for the on-call shift: step-by-step scenarios for typical failures — what to check first, how to roll back a release, whom to escalate to.
- Acceptance scenarios and logs: tests on critical paths, dashboards with threshold alerts, and action audit — deviation is visible before an incident.
Case study: how a protocol restored payouts after an oracle failure
A restaking protocol on EigenLayer distributed rewards among operators through an external price source: it confirmed the staking state, and the calculation of each participant's share depended on its response.
Once, the source began returning divergent data — some operations got stuck in the "confirmation not received" status, and rewards stopped reaching delegators.
Before the changes, the share of stuck operations reached 18%: each was investigated manually using logs and statements, and one incident took the on-call engineer from six to nine hours.
In a week, support received several dozen requests, and half of them were repeat requests from the same delegators.
We rebuilt the confirmation layer: the calculation began relying on several independent sources and cross-checking them, and questionable responses are placed in a buffer of unconfirmed operations instead of stopping payouts.
Recalculation from the buffer runs automatically, manual intervention is needed only to confirm a disputed operation, and every action is written to an immutable log — you can see who made the decision and on what basis.
After the rework, the share of stuck operations stays within 0.4%, investigation dropped from hours to minutes, and the flow of support requests fell by almost three times — repeat requests disappeared as a class.
Payouts continue even when sources diverge: the protocol accrues retroactively when confirmation arrives.
How does restaking differ from regular staking?
Regular staking solves one task — confirming network consensus. You deposit an asset, receive a share of emissions and transaction inclusion fees, and the main risk is limited to validator behavior and penalties for violating protocol rules.
Yield here is predictable: it is determined by network parameters and validator availability, not by third-party projects.
Restaking changes the mechanics: the same asset is reused as collateral in additional services that need economic security — oracles, bridges, data storage networks. One deposit works on several tasks at once, and income is split into several independent streams.
Technically, these are contracts that account for your share, transfer it to operators, and distribute responsibilities among them.
The difference in risks is fundamental. With regular staking, you are responsible only for your own validation; with restaking, conditions of third-party services are added: their penalties, bugs in their code, withdrawal delays.
The risk on the same amount of collateral becomes several times higher, and it cannot be assessed by yield alone — it must be calculated for each stream separately.
Infrastructure requirements also diverge. You need operators capable of simultaneously running several services, separating keys and roles, and revoking delegated shares in time.
Hence mandatory observability: see where and how much collateral is used and how quickly you can exit it.
Practical takeaway: staking is the base, restaking is an add-on with several income sources and several penalty sources. We design such protocols on EigenLayer and start with the threat model, slashing boundaries, and exit scenarios — before the first line of code.
Technical concerns: withdrawals, penalties, audit
Engineers ask three questions before all others: how to exit the protocol, who is responsible for a node violating the rules, and what a code review shows before launch. Below is how these scenarios are addressed in the architecture we build.
How to withdraw assets if we decide to leave the protocol?
Withdrawal goes through a queue: the request fixes the share, rewards on it stop, and after the unbonding period the assets are returned to the owner's address.
The period length is set at deployment and cannot be changed retroactively — otherwise the last participant would exit at the moment of calculation. Throughout the queue period, the share remains with the owner, not the operator.
Who pays validator penalties?
The penalty is deducted from the operator's collateral share contributed to security, not from the user's balance. A separate limit is allocated for each set of tasks, so a failure in one service does not affect the others.
The size of the safety buffer and the number of simultaneously active tasks are configuration parameters; we calculate them during risk modeling.
How do contract audits and logic upgrades work?
Before launch: static analysis, running random and edge-case scenarios against share invariants, checking exit and penalty, and an external audit with a report and review of findings.
An upgrade goes through a contract with execution delay and multi-key confirmation — a single role cannot quietly change payout calculation. Powers are separated: pause and upgrade have different holders.
Let's discuss the task: how we estimate scope of work
Restaking protocol development begins not with code but with an analysis of the economics: reward accrual rules, penalty logic, and income distribution between operator and delegator determine the architecture more strongly than any interface preferences.
That is why estimating the scope of work without input data turns into a conditional range that falls apart at the first scenario review.
You should send what already exists: a draft model, calculation tables, role diagrams, correspondence with lawyers, and deadline constraints. We will return with a work plan broken down by stages and separately highlight areas where we see technical risk.
- Economic model: how rewards are formed, what penalties are charged for, and how income is divided between operator and delegator.
- Target networks and assets: where restaking is launched, what is accepted as collateral, and whether there are liquidity limits.
- Roles and rights: who changes protocol parameters, who can emergency-stop it, and how access is separated.
- Operator set: how registration, verification, and removal from the set work, and which metrics affect status.
- Interface and integrations: whether a user dashboard, wallet connections, custody services, and external accounting are needed.
- Load and growth: expected number of users and operations, protocol behavior during peak withdrawal queues.
- Security: whether an external audit is needed, which failures are considered critical, and what recovery time is acceptable.
- Constraints: deadlines, your team composition, regulatory requirements, and launch jurisdiction.
Describe the task in free form — we will return with a scope estimate and a stage-by-stage plan, with no preconditions on your side.