Root + Impact

Description

• Normal Behavior:
  The dsc_engine.vy constructor stores the input collateral addresses into the collateral_tokens array. During account valuation, the engine iterates over this array and sums up each collateral balance to compute the total collateral value.

  
  

• Specific Issue:
  The constructor does not check for duplicate collateral addresses. If the same address appears twice in the input array, the same balance is counted twice during valuation. A user can then mint more DSC than their actual collateral supports. While the current deployment script passes WBTC and WETH (two distinct addresses), a misconfigured or malicious deployment could introduce duplicates and break the protocol's solvency.

Risk

Likelihood:

• The current deployment uses two distinct addresses, so the bug is not triggered today.

• However, the constructor does not validate input, so any future deployment or upgrade could introduce duplicates.

• A compromised owner could deliberately deploy with duplicates.

Impact:

• Duplicate addresses cause collateral to be double-counted.

• Users can mint DSC exceeding their real collateral backing.

• The protocol can become insolvent if the owner is compromised or the deployment script is misconfigured.

Proof of Concept

The test deploys the engine with weth.address passed twice in the token_addresses array. The user deposits 1 WETH worth $100,000. Because the engine iterates over the array and sums each entry, the same balance is counted twice, making the collateral appear worth $200,000. The user can then mint 200,000 DSC against only 100,000 worth of real collateral. The assertion value == 200_000 * 10**18 confirms the double-counting.

Recommended Mitigation

Since the constructor takes exactly two collateral addresses, a single assert is enough to reject duplicates. This prevents the same token from being counted twice during valuation and ensures the protocol's solvency.