Root + Impact

Root Cause: The COLLATERAL_TOKENS array is defined with a fixed size of 2 elements, and the constructor only accepts exactly 2 token addresses and 2 price feed addresses.

Impact: The protocol cannot support more than 2 collateral types without code modifications. This contradicts the documentation stating the code should work for "any basket of assets" and limits the protocol's ability to scale or adapt to market demands.

Description

Normal Behavior: According to the documentation, the protocol should allow forking and swapping "WETH & WBTC for any basket of assets" with the code working the same.

Issue: The collateral token array is hardcoded to exactly 2 elements, preventing support for more diverse collateral baskets without code modifications.

Risk

Likelihood:MEDIUM

• Reason 1 : Any protocol fork wanting more than 2 collateral types encounters this limitation immediately

• Reason 2 : Adding new collateral to an existing deployment is impossible

Impact:

• Impact 1 : Cannot support diverse collateral baskets without redeployment

• Impact 2 : Reduced protocol flexibility and composability

Proof of Concept

A protocol fork attempts to support WETH, WBTC, and LINK as collateral. The deployment fails because the constructor signature requires exactly address[2] for token addresses. The only solution is modifying the contract code, recompiling, and redeploying, negating the "swap and deploy" simplicity promised in documentation.

Recommended Mitigation

Use dynamic arrays with a reasonable maximum size instead of fixed-size arrays. This allows deployers to configure any number of collateral tokens up to the maximum while maintaining gas efficiency.