# Lido NEST audit summary > NEST automates LDO buybacks funded by Lido DAO treasury earnings. Our security review covered the contracts, the fixes, and the verified mainnet deployment. - Canonical: https://ack3.ai/research/lido-nest-audit-summary/ - Published: July 28, 2026 - Authors: Michal Převrátil, Jan Kalivoda, Naoki Yoshida, Josef Gattermayer - Category: Audit summary - Topics: audit, audit-summary, ethereum, lido, wake Lido NEST automates LDO buybacks funded by DAO treasury earnings, releasing funds only as fast as revenue accrues. Depending on the configured mode, it either deposits the acquired LDO alongside wstETH into a liquidity pool or sends it directly to the treasury. ## Revisions | Revision | Deliverable | Date | |---|---|---| | 1.0 | Security Review | June 22 – July 7, 2026 | | 1.1 | Final Report (fix review) | July 17, 2026 | | 1.2 | Deployment Verification | July 24, 2026 | The published report is revision 1.2 and contains all three revisions. ## Revision 1.0: security review Lido engaged ack3 to perform a security review of Lido NEST with a total time donation of 10 [engineering days](/research/glossary/engineering-days/) between June 22 and July 7, 2026. Michal Převrátil led the review, with Jan Kalivoda and Naoki Yoshida as auditors and Josef Gattermayer as audit supervisor. The review was performed on commit `2e70a1b` in the [stonks](https://github.com/lidofinance/stonks) repository and commit `18ea278` in the [core](https://github.com/lidofinance/core) repository. It covered the following new files in `stonks`: - `contracts/automated-buybacks/BuybackExecutor.sol` - `contracts/automated-buybacks/BuybackAllocator.sol` - `contracts/automated-buybacks/revenue/StakingRevenueSource.sol` - `contracts/automated-buybacks/AssetRecovererACL.sol` - `contracts/automated-buybacks/revenue/RevenueSource.sol` - `contracts/automated-buybacks/MathHelpers.sol` It also covered changes to `contracts/Stonks.sol`, `contracts/factories/StonksFactory.sol`, and `contracts/Order.sol` in `stonks` since commit `4c6d195`, and changes to `contracts/0.8.9/TokenRateNotifier.sol` in `core` since commit `eae8614`. We began by understanding the overall architecture and the purpose of the system. Then we performed a deep dive into the logic of the contracts and, in parallel, prepared a [differential](/research/glossary/differential-fuzzing/) [manually guided fuzz test](/research/glossary/manually-guided-fuzzing/) using the [Wake](/wake/docs/latest/) testing framework. In the later phase of the review, we launched an automated ack3 AI scan. During the review, we paid special attention to: - the integration with the Curve TwoCrypto pool, particularly the deposit protections; - access controls that are not too relaxed or too strict; - permissionless functions, assessed for griefing vectors or ways to take advantage of the automated buyback system; - discrepancies between the states of the two contracts, such as an amount already budgeted on one side but not yet reflected on the other; - the Chainlink integration and its consequences; - permissioned roles retaining full control over orders and the ability to intervene in emergency scenarios; and - common issues such as data validation. ## Findings The review resulted in 16 [findings](/research/glossary/findings/): 9 low, 3 warning, and 4 info. No critical, high, or medium severity issues were found. Most of the low-severity findings are edge cases in how the system tracks state across time or across cooperating contracts, rather than directly exploitable vulnerabilities. For instance, `L9` stems from a status enum that drifted out of sync with its interface, `L4` shows a fixed-window rate limiter that can be straddled to briefly exceed its cap, and `L3` leaves funds unmonitored after a configuration change. Ten findings were discovered by auditors and six by the AI scan. Every finding was manually reviewed and validated by the team. ### Curve TwoCrypto deposits As part of the review, we evaluated the consequences of the absent slippage protection on Curve TwoCrypto pool deposits, under the stated requirement that Lido NEST be the only contract interacting with the pool and that no other interference from the Lido side is expected. In our assessment, the current implementation is sound for the bootstrap phase and preferable to introducing a Chainlink-to-pool difference gate. We nonetheless identified two residual risks: - The Chainlink oracle may misreport the price of stETH or LDO, resulting in an imbalanced deposit and subsequent arbitrage. - A malicious actor may poison the internal state of the pool (pool balances, `price_scale`), leading to higher imbalance fees paid by Lido NEST during deposits. Both risks are inherent to the current design and, in our view, acceptable. The first stems from the Chainlink oracle itself and has a very low likelihood of occurring. For the second, the fees incurred by Lido NEST are bounded to a maximum of 0.026%, negligible relative to the deviation thresholds of the stETH/ETH (0.5%) and LDO/ETH (2%) oracles. Conversely, introducing an EMA gate or any other Chainlink-to-pool difference gate would allow a malicious actor to temporarily poison the shallower pool and block deposits through the gate. The review was conducted against the fixed parameters of the [deployed pool](https://etherscan.io/address/0xD7f1dA0a28E39dd0dB70E6Acdc2B49846AD22760#code). ## Revision 1.1: fix review The fix review was performed on commit `10a2499` in `stonks` and commit `dc9066b` in `core`. Beyond the changes addressing the reported findings, these commits also introduced minor code and comment modifications, likewise covered by the review. Of the 16 findings, 8 were fixed and 8 were acknowledged. No new findings were identified. Each finding's status and fix is documented in the report. ## Revision 1.2: deployment verification We verified the Lido NEST deployment on the Ethereum mainnet, on the same commits as the fix review. The verification concluded with a full match of the runtime bytecode, excluding the metadata hash, and reasonable values used for constructor arguments. Deployment parameters were additionally checked against [LIP-36](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-36.md) for the parameters it specifies. The verified contracts: `StonksFactory`, `Order` (sample), `StakingRevenueSource`, `BuybackExecutor`, `BuybackAllocator`, `Stonks` in LP and treasury mode, `TokenRateNotifier`, and `LidoLocator`. ## Report and code - [Full report (PDF)](https://github.com/lidofinance/audits/blob/main/Ack3%20Lido%20NEST%20Audit%20Report%2007-2026.pdf) - [Fuzz tests and deployment verification script](https://github.com/ack3-ai/tests-lido-nest) - Reviewed repositories: [lidofinance/stonks](https://github.com/lidofinance/stonks), [lidofinance/core](https://github.com/lidofinance/core)