Part 2

Summary

Three public/external update functions in the contract—updateMarketCreditDelegations, updateMarketCreditDelegationsAndReturnCapacity, and updateVaultCreditCapacity—lack any role-based restriction. Each of these functions calls Vault.recalculateVaultsCreditCapacity, which can iterate over numerous vaults or markets. Consequently, they can be invoked by anyone, potentially consuming significant gas and causing performance issues or minor denial-of-service (DoS) scenarios.

Vulnerability Details

These functions are:

https://github.com/Cyfrin/2025-01-zaros-part-2/blob/35deb3e92b2a32cd304bf61d27e6071ef36e446d/src/market-making/branches/CreditDelegationBranch.sol#L694-L719

• No Access Restriction: Any external actor can call these functions, bypassing checks like onlyKeeper or onlyOwner.

• Potentially Large Loops: Each call triggers Vault.recalculateVaultsCreditCapacity, which can loop over all or many connected vaults, consuming significant gas.

Because these are “update” or “sync” functions, they do not directly transfer funds. However, they impose an unbounded computational cost on each call—if arrays grow large or if the system has many vaults, this could be used to clog the network or force high gas usage.

Impact

• DoS by Gas Consumption: Attackers can repeatedly call the functions to flood the system with high-cost transactions. This does not directly compromise funds but can disrupt normal operations.

• Performance Degradation: Spam calls may lead to unnecessary recalculations, clutter logs, or raise transaction costs for other users interacting with the protocol.

Tools Used

• Manual Code Review: Examined the update... functions and the downstream calls to Vault.recalculateVaultsCreditCapacity.

Recommendations

1. Restrict Access

   • Add appropriate role-based modifiers (e.g., onlyKeeper) so that only authorized entities can trigger expensive recalculations.

2. Implement Rate Limits or Cooldowns

   • If public access is required, introduce time-based or usage-based restrictions to limit spam calls in a single block or over short intervals.

3. Monitor and Optimize

   • Continuously observe gas costs and system performance. If the lists of vaults or markets become extensive, consider optimizing how recalculateVaultsCreditCapacity processes them (e.g., batching).

4. Consider a Fee or Incentive Model

   • If the system design allows public calls, charging a small fee or rewarding correct updates can mitigate malicious spam and still allow decentralized updates.