# RedeemQueue could be optimized Low/Info · Three Sigma · Cross-chain liquidity layer 1 · 25th June, 2024 Finding 3S-Mitosis-N09 of the Mitosis security review. - Protocol: https://mitosis.org/ - Report: /reports/mitosis - Source: https://cdn.sanity.io/files/qoqld077/production/b6b3bd7bb47407d99e76abb7c6dc615c1db5018e.pdf --- ### Description The current RedeemQueue implementation goes through requests and marks them as resolved one by one. This is expensive and a much better solution is keeping track of the last index that was resolved, and if the request index is smaller than the last resolved, it means it was resolved (indices are sequential). [Here](https://github.com/lidofinance/lido-dao/blob/master/contracts/0.8.9/WithdrawalQueueBase.sol#L332) is the function that settles redeem requests. It gets the correct index to redeem until to by perform binary search, but can also pass it as argument (so the search is performed off chain). It's also not required to store request.amount as it can be calculated by fetching the last request and subtracting from the current cumulative amount. ### Recommendation It would be much cheaper to redeem batches at once, so a similar method to Lido's could be implemented. ### Status Addressed in [#bed727e](https://github.com/mitosis-org/evm/pull/205/commits/bed727e3f44841436864af64ff59eda73babb50b). --- Related findings: - [Queue MapleWithdrawalManager may revert due to honest removeShares() or manual redeem calls](https://0xsimao.com/findings/maple-finance-ii-queue-withdrawal-shares-redeem): Maple Withdrawal Manager