LytPool

Description

Various functions of protocol contracts are missing necessary protocol/account status checks.

1. LYTPool.processRedemption: Missing withdrawStateActive modifier.
2. LYTPool.depositOffChain: Missing depositStateActive modifier.
3. LYTPool.depositFromTransfer: Missing depositStateActive modifier.
4. LYTPool.changeRedemptionDestination: Missing withdrawStateActive modifier.
5. LYTPool.processRedemption: Missing blacklist check on fundsDestination address.
6. LYTPool.changeRedemptionDestination: Missing blacklist check on fundsDestination address.
7. LYTPool.setIndicativeAndCollateralRates: Missing atState(ILYTPoolLifeCycleState.Active) modifier.
8. LYTPool.setExchangeRate: Missing atState(ILYTPoolLifeCycleState.Active) modifier.
9. LYTPool.maxRedeemRequest: Missing onlyNotPaused modifier.
10. LYTPool.maxRedeemRequest: Missing atState(ILYTPoolLifeCycleState.Active) modifier.

Recommendation

Consider adding all the mentioned status checks.

Description

In LYTPool contract it is possible to burn LYTPools tokens which are currently in active withdrawal queue.

Scenario:

1. A market maker holds 100 pool tokens.
2. Market maker requests a withdrawal of 50 tokens.
3. Issuer calls addAdjustmentAmount and burns 60 tokens of market maker.
4. Now since 60 tokens have already been burned, the redemption of 50 tokens from step 2 cannot be performed. The processRedemption call reverts at L396.
5. 40 pool tokens of market maker becomes unusable.

Recommendation

Add a maxRedeemRequest check in addAdjustmentAmount function.

function addAdjustmentAmount( ... ) public ... {    ...    if (debit > 0) {-     if (debit > assetBalanceOf(lender)) {-       revert DebitGreaterThanAssets();-     }      uint256 shares = convertToShares(debit);+     if (shares > maxRedeemRequest(lender)) {+       revert BurnExceedsBalance();+     }      _burn(lender, shares);      emit AccountDebit(lender, debit);    } else if (credit > 0) {      ...    } else {      revert InvalidAccess();    }  }

Description

The getActiveWithdraws function iterates over all active withdrawal requests and returns the full list. If a large number of redeemers submit withdrawal requests, this approach can result in high gas consumption, making the function inefficient and potentially impractical to call on-chain.

Recommendation

Introduce pagination (e.g., via index ranges or batching) to limit the number of withdrawal requests returned per call. This will reduce gas costs, improve scalability, and make the function safer to use when handling a large volume of requests.

Description

Currently, blocklisted users are still able to create redeem requests, which are then added to the activeWithdrawRequest list. However, when the protocol attempts to process these requests, the transaction reverts at the step where it tries to burn the blocklisted lender’s token.

This behavior leads to a situation where getActiveWithdrawRequest includes requests that can never be executed, causing inconsistencies and breaking assumptions for off-chain bots or automation that rely on this function to reflect executable withdrawals.

Recommendation

Prevent blocklisted users from creating redeem requests in the first place. Adding a validation check before requests are added to activeWithdrawRequest will ensure the list only contains valid and executable entries, avoiding stuck or unprocessable states.

Description

In LYTPoolServiceConfiguration.setLiquidityAsset function duplicate liquidity asset entries can be added to liquidityAssetKeys state.

Recommendation

Consider reverting if isLiquidityAsset[addr] is already set to value.

Description

The LYTPoolAccessControlFactory.create function does not check the paused status of _serviceConfiguration

Recommendation

Consider adding the check.

Description

The LYTPool.deposit function breaks the CEI pattern and performs an external call before updating its internal storage states.

Recommendation

Consider performing the _mint call before the _liquidityAsset.safeTransferFrom call.

Description

The IFactoryType enum datatype does not contain LYTPoolControllerFactory type. Instead it incorrectly contains FeeCollector type.

Recommendation

Consider replacing FeeCollector with LYTPoolControllerFactory in IFactoryType enum.

Description

The LYTPool.previewWithdrawRequest function rounds down the calculated shares amount. This rounding direction favors the users instead of pool contract.

As a security practice it is always recommended to always round in the direction which favors the pool contract.

Recommendation

Consider rounding up the shares value in previewWithdrawRequest function.

Description

The LYTPool.requestRedeemExecute function enforces a threshold of 100 active withdrawal requests per market maker address. Since a LYTPool will only have a limited number of whitelisted market makers which will perform all the pool token mints and burns, it is possible that those market makers may hit the 100 active requests threshol which will block further redemption requests by such market makers.

Recommendation

As market makers are whitelisted entities, the threshold of 100 requests can be removed or increased to a larger limit value.

Description

setIndicativeAndCollateralRates missing event emission so the offchain service cannot track _indicativeInterestRate and _collateralRate change.

Recommendation

function setIndicativeAndCollateralRates(    uint256 _indicativeInterestRate,    uint256 _collateralRate  ) public onlyPoolController {    _accounting.indicativeInterestRate = _indicativeInterestRate;    _accounting.collateralRate = _collateralRate;    emit IndicativeAndCollateralRatesChanged(_indicativeInterestRate, _collateralRate);  }

Description

The updatePoolData function is protected by the onlyRegisteredPool modifier. However, the LYPool.sol contract does not have a direct way to trigger updatePoolData.

Recommendation

Introduce a function in the controller contract that allows the controller to call into LYPool to call updatePoolData

Description

The comments says that the functions listed below are only callable by protocol admin, but the modifier is onlyIssuer, not onlyProtocolAdmin.

• addAdjustmentAmount
• setFeeCollectorAddress
• setIndicativeAndCollateralRates

Recommendation

Make sure Code implementations are consistent with the spec

Description

In LYTPoolAccessControl contract

• the natspec of allowParticipant specifies AllowedParticipantListUpdated event but ParticipantAllowed event is emitted
• the natspec of removeParticipant specifies AllowedParticipantListUpdated event but ParticipantRemoved event is emitted

Recommendation

Consider fixing the natspec comments.

Description

Multiple protocol contracts implements version function but its implementation is inconsistent across those contracts. In some contracts version returns 257 while in some it returns 256 or 512.

Recommendation

Consider removing the version function from all contracts or implement it in a consistent way across protocol.

Description

1. LYTPoolController.sol?lines=367,368: Incorrect comment as activatedAt value is never updated.

Recommendation

Consider fixing the comments

Description

The LYTPool tokens can be freely transferred by token holders. Those holders can avoid burn adjustments by transferring their LYTPool tokens to other addresses just before the addAdjustmentAmount transaction gets executed. Repeated execution of this mechanism can prevent burn adjustments from happening.

Recommendation

This could be an accepted risk. If a mitigation is required then token transfers can be paused before making a burn adjustment.

Description

These code instances are present in the codebase but are never used. Hence they can be removed.

1. LYTPool.sol?lines=197,197: isPermittedLender is not used in LYTPool.sol.
2. LYTPoolServiceConfiguration.sol?lines=52,59: The onlyProtocolAdmin and onlyIssuer modifiers are never used inside LYTPoolServiceConfiguration contract.
3. LYTPoolRegistry.sol?lines=24,24: The onlyOperator modifier is never used in LYTPoolRegistry contract.
4. LYTPoolController.sol?lines=81,83: Unused modifiers: onlyProtocolAdminOrIssuer, onlyProtocolAdminOrIssuerOrAutomation & atState.
5. ILYTPoolStructures.sol?lines=50,55: Initialized and DisruptionOrDefault states are never used.
6. ILYTPoolStructures.sol?lines=10,10: LYTPoolSettings struct is never used.
7. ILYTPoolStructures.sol?lines=67,67: ILYTPoolWithdrawStage.Repaid is never used.
8. ILYTPoolStructures.sol?lines=73,73: ILYTPoolDepositType.CrossChainDeposit is never used.
9. IPoolStructures.sol: IPoolStructures.sol file is never used.
10. IERC4626.sol: IERC4626.sol file is never used.

Recommendation

Remove the unused code to save gas.

Description

The withdrawStateActive modifier can be removed from requestRedeemExecute function as it is already present on requestRedeem function.

Recommendation

Consider removing the modifier from requestRedeemExecute function.