Why position accounting breaks when integrating Renzo
Liquid restaking breaks the usual accounting model: the number of tokens in the wallet does not change, while the value of the position grows. A service built on reconciling by number of units shows zero accruals — even though the yield has already accumulated.
When integrating Renzo, this is the first place where internal data and the actual state of the restaking position diverge.
The second gap is discrepancies in accruals. The exchange rate is recalculated not on a schedule, but based on validator performance: between updates the position value stays flat, then changes in a single step.
If reconciliation takes a snapshot once a day and stores only the latest value, the jump reaches reporting late, and the difference settles into an unaccounted balance.
The third is stuck withdrawals. Withdrawal goes through a request queue: the rate is fixed at the moment of request, and funds arrive later.
A service that debits the position immediately shows the user an empty balance even though the asset is still in transit; the reverse error is worse — the position is listed as active when it has already been withdrawn.
And finally, manual balance reconciliation.
As long as the proportion between the principal of the position and accumulated yield is calculated manually using the latest known rate, a partial withdrawal takes the wrong share: rewards are written off together with the principal amount or remain hanging on a closed position. Errors accumulate quietly — until the first client complaint or reporting discrepancy.
We discuss further how this is closed: with an event log, state snapshots, and reconciliation that balances without manual adjustments.
The effect of correct accounting of ezETH positions and accruals
An ezETH position changes through several flows at once: liquid restaking yield, boost rewards, and the token's exchange rate to the underlying asset.
When each flow is reconciled with a separate export, discrepancies accumulate on rounding and differences in the fixing time — and surface already in reporting, where recovering the cause is expensive.
Correct integration with Renzo maintains the position as a single event log: each operation records the exchange rate at the moment of execution, reward accrual is broken down by source, and the total reconciles automatically when the period closes. Only what requires human judgment remains manual — reviewing a disputed accrual or anomaly.
Hence the measurable effect.
Reconciliation time drops from 6–8 hours per period to 30–40 minutes, the share of manual operations falls from 70% to single-digit percentages, and the failure class «balance discrepancy without an explainable cause» disappears from regular incidents: a discrepancy is either explained by its source or blocks the entry until it is reviewed.
The cost of failure also changes separately. ezETH accounting is restored by recalculating the log — minutes instead of a day of manually matching exports — and rolling back to the previous state does not require re-entering accruals.
We capture these metrics before and after integration so that the result is verifiable rather than declarative.
Options for connecting to liquid restaking: comparison
There are three ways to connect to liquid restaking, and they differ not in interface convenience but in who holds the keys and who is responsible for errors.
Direct connection to the official Renzo contracts gives full control over the logic, but shifts event monitoring, balance reconciliation, and handling of failed operations to your team.
A proprietary intermediary layer isolates the product from changes to external interfaces and maintains a single operations log. An external operator removes the load, but along with it takes control: limits, withdrawal delays, and the set of scenarios are set by its side.
Workaround schemes — manual transfers between addresses, custom wrappers over official contracts — surface at the first pause in the protocol, and investigating such an incident is more expensive than choosing the standard path from the start.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection to official contracts | You have your own protocol development team and need the full set of operations | Monitoring, reconciliation, and error handling are entirely on your side; you track contract updates yourself |
| Proprietary intermediary layer | Multiple products or networks, need unified reporting and a single point of failure | Requires maintenance: operation queue, balance reconciliation, separate access perimeter |
| Working through an external operator | Fast launch, no in-house protocol support | Provider limitations: limits, withdrawal delays, reduced set of operations, dependence on its availability |
The choice here is not about the speed of the first launch, but about where you are prepared to hold responsibility for a failure.
How the work proceeds: from position audit to handover of procedures
Integration is not a single setting but a chain of stages, where each subsequent one relies on the result of the previous.
Below is what the work looks like when the client needs a manageable scheme rather than a set of one-off scripts: from asset inventory to documents by which the client's team works independently.
- Position audit. We bring into one picture where ezETH and derivative positions currently are: addresses, networks, contracts involved, pool shares, open requests. The output is an asset map with owners, status, and restrictions for each address.
- Access rights. We separate roles: who initiates an operation, who confirms it, who has read-only access. We set limits by amount and frequency, and separate key sets for each environment so that production actions are not performed with the same keys as verification actions.
- Flow scheme. We fix the asset route: where it comes from, which steps it passes through, and what happens if any of them fails. We separately mark points where manual control is needed and the conditions under which an operation stops automatically.
- Configuration. We assemble the configuration for the fixed scheme: call parameters, limits, retries on failures, and logging of every action with an operation ID.
- Testing on a test environment. We run the full set of scenarios on a copy of the production network: deposit, partial withdrawal, failure of one of the steps, exceeding the limit, resubmission. We check not only successful passes but also correct stopping.
- Acceptance of work. We reconcile the result against the agreed checklist: amounts, fees, operation completion time, behavior on failure. We show logs and discrepancies, if any.
- Withdrawal procedures. We hand over documents: how to initiate withdrawal, which limits apply, who confirms and in what order, what to do in an incident, and how to roll back to the previous state.
What remains in your perimeter: schemes, policies, procedures
Integration is complete not when the first transaction has gone through, but when the perimeter can be raised and maintained without us.
Along with the working solution, you receive artifacts by which an engineer — yours or a new contractor — will understand how the asset flow is structured and what to do in a failure.
- Asset flow schemes — where ETH comes from, at what point it goes to Renzo, how ezETH is returned, and at what rate the result is calculated.
- Access policies — which keys and multisigs sign what, who initiates deposit, withdrawal, and parameter changes.
- Operator roles — a rights matrix: observer, operator, treasurer, administrator, and the boundaries of each one's responsibility.
- Withdrawal procedures — step-by-step procedure for withdrawing funds, including the protocol exit window and actions during a delay.
- Emergency action procedures — conditions for stopping operations, manual withdrawal procedure, escalation route.
- Configurations — contract addresses, limits, and fee parameters; secrets remain in your vault, not in the repository.
- Solution documentation — architecture, external dependencies, failure points, and the update procedure when protocol contracts change.
Such a kit removes the main risk of working with liquid restaking protocols: the solution stops depending on one person who remembers why a parameter was set exactly that way. Describe the task — we will come back with an estimate and plan, including the documentation scope.
How discrepancies in reward accounting were eliminated: before and after metrics
A liquid restaking pool operator on Renzo closed the reporting period manually. Rewards came from several sources, the ezETH rate changed, and each position was reconciled against network exports and the internal database.
Closing the period took two specialists three business days — and this was not a crunch but a regular cycle.
Before: manual reconciliation and discrepancies in reports
Reconciliation was done by matching tables: an export for deposits, separately for withdrawals, separately for accruals. Each cycle found 6-9 discrepancies, and some surfaced only in the next period, when there was no longer any way to explain them. The report went to management late, and rewards could only be controlled after the fact.
After: automated accounting and reward control
We broke down the accrual logic into contract events, linked them to positions, and consolidated them into a single accounting perimeter.
Every accrual gets a record with source, time, and a link to the on-chain operation; a deviation from the expected volume is flagged and goes into an alert the same day.
Period closing was reduced to 30-40 minutes, the share of unreconciled records stays below 0.5%, and the export for reporting is assembled with a single query.
We separately preserved a change log: any figure in the report can be expanded down to the source event. This is reward control in which verification does not depend on who maintains the table.
How direct Renzo integration differs from workaround schemes
Direct integration is calling the official Renzo contracts from your product and reading confirmations from their event log. There is no intermediary link between the service and the protocol: the transaction goes to the target contract, and the state is read from the chain. A workaround scheme adds a participant — a swap aggregator, a custodial wallet, or a custom route.
The difference shows up in the transparency of calculations. With direct integration, the exchange rate, protocol fee, and final amount of tokens received are recorded by transaction events — they can be reconciled independently without trusting someone else's reporting.
In a workaround scheme, only the balance total is visible, and a discrepancy is explained by the provider's internal terms, with no way to verify it.
Each extra link adds risks you do not control: quote discrepancy at the moment of the trade, volume limits, a pause in someone else's contract, inability to cancel a request.
If an intermediary holds assets at its own address, responsibility also becomes blurred — it is unclear to whom to make a claim in a failure.
The withdrawal procedure in a direct scheme is defined at the contract level and is reproducible: request, confirmation, receipt of the underlying asset — with clear waiting windows and request state.
In a workaround, the queue is formed by the intermediary, timelines fluctuate, and priority depends on its internal policy. For scenarios with reporting and audit, this is the deciding factor.
Hence the rule: where balance reconciliation, risk limits, and predictable withdrawal are needed, the direct route is used. A workaround is justified only for one-off operations outside your perimeter.
Technical concerns about architecture, keys, and risks
Some integration questions surface not at the start but at acceptance — when access and accounting need to be explained to security and accounting. We collected the most frequently asked ones, with specifics on the mechanics.
What happens to already deployed positions?
The underlying asset remains in the protocol; only the accounting route changes: migration goes through a wrapper contract, and the old position continues to work throughout the switch.
Rollback is returning the pointer to the previous contract, without exiting the position and without losing what has accumulated.
Who holds the private keys?
The keys remain with you: transaction signing goes through a hardware module or threshold multisig.
Our services receive a service key with a daily limit on operation volume and access only to the required methods — it is revoked with one operation, without reissuing the main keys.
How real is slashing?
A penalty occurs for double signing, downtime, or a validator configuration error.
We keep the share at a single operator limited, distribute it across several independent ones, and remove it from the queue automatically upon degradation — the risk remains, but within predefined limits.
Why does withdrawal take days?
The position goes through the protocol's exit queue, so the timeline is measured in days, not minutes. For urgent requests, we maintain a liquidity buffer and a separate swap route — it covers the need faster than the queue, with a price difference that we calculate in advance.
How should rewards be accounted for in reporting?
Rewards do not arrive as separate transfers but as balance growth, so we build accounting by epochs: a position snapshot at the period boundary and the rate at the moment of accrual. The output is an export for accounting with a breakdown by each operator and period.
Let's discuss your task: what is needed for an estimate and plan
To come back with a task estimate and work plan rather than generalities, we need to understand your perimeter: where assets are held, who signs operations, and what is already configured on the Renzo side.
Describe the task in free text and attach what you have on hand — we will clarify the rest with questions.
- Data composition: which assets and in what volume you plan to direct into liquid restaking, where rates come from, and how accrued yield reaches your reporting.
- Current perimeter: networks, wallets, and services already involved in the process — to understand what we reuse and what we add.
- Accesses and roles: who issues keys or access to the custodial service, how operations are approved, and which limits apply.
- Fault tolerance requirements: acceptable downtime, whether automatic rollback is needed, how your side responds to a rejected operation.
- Procedure and audit: internal rules for working with digital assets, requirements for logs, and events that must be recorded.
- Expected result: scenarios that must work at launch and acceptance criteria — this is how we fix the scope and timeline of the connection without ambiguity.
After the review, you receive an integration scheme, a breakdown of work by stage, connection timelines, and the procedure for handing the solution over to your team — with documentation and support during the launch period. Describe the task: this is enough for us to come back with an estimate and plan.