Part 2

Summary

VaultRouterBranch::getIndexTokenSwapRate is called with the shouldDiscountRedeemFee parameter hardcoded as false in every function in the zaros contracts. This design flaw prevents the protocol from dynamically granting discounted redeem fees to specific addresses. Once deployed, there is no mechanism for selectively applying fee discounts—effectively locking out any potential for whitelisting addresses that should benefit from reduced fees.

Vulnerability Details

In the redeem flow for VaultRouterBranch::redeem, the getIndexTokenSwapRate function is invoked with the shouldDiscountRedeemFee parameter set to a constant false boolean. This hardcoding means that the redeem fee discount logic is not configurable per user or address:

// (For proof-of-concept purposes this may have been temporarily set, but once deployed no dynamic control exists.)

Without dynamic control over the fee discount parameter, there is no way to provide fee discounts for privileged addresses (for example, partners, early adopters, or certain strategic users). This prevents the protocol from offering any custom fee structure.
As the fee discount flag is hardcoded, the protocol cannot adjust fees on a per-address basis without redeploying or upgrading the contract. This limitation reduces flexibility and may be inconsistent with the intended business model.

This behaviour is analogous wherever VaultRouterBranch::getIndexTokenSwapRate is called in any function in the zaros contracts in scope.

Impact

Inflexible Fee Policy: The inability to dynamically apply fee discounts means that all users are subject to the same fee structure, even if the protocol’s economic model intends to incentivize certain users with discounted fees.

Operational Limitations: The lack of whitelisting increases administrative overhead since adjusting fee discount policies would require contract redeployment or an upgrade, rather than a simple update of a whitelist mapping.

Tools Used

Manual Review

Recommendations

Introduce a Whitelist Storage Variable: Create a storage variable (e.g., a mapping of addresses to a boolean) to maintain a whitelist of addresses that are eligible for discounted redeem fees.

Pass Fee Discount as a Parameter in the Redeem Function: Modify the redeem function to accept a bool shouldDiscountRedeemFee parameter. This parameter should not be hardcoded but instead determined based on whether the caller is whitelisted.

Implement a Whitelist Check: In all relevant functions, check if msg.sender (or the relevant address) is in the whitelist:

Provide Administrative Functions: Add functions that allow protocol administrators to add or remove addresses from the whitelist, enabling dynamic adjustments to fee discount eligibility.