Root + Impact

Description

• The redeem_collateral() external function does not validate that amount_collateral > 0, allowing users to call the function with a zero value.

• This creates inconsistent validation behavior compared to deposit_collateral(), which correctly enforces amount_collateral > 0.

  In DSCEngine.vy, the redeem_collateral() function is implemented as:

Unlike _deposit_collateral(), which contains:

there is no equivalent validation in redeem_collateral().

As a result:

• redeem_collateral(token, 0) executes successfully

• No revert occurs

• State-changing logic is executed unnecessarily

Unit test confirmation:

This test fails because the function does not revert.

Risk

Likelihood: Medium

• Reason 1 Users can easily call the function with 0.

• Reason 2 No restrictions prevent zero input.

• Reason 3 Easy to trigger.

Impact: Low (Direct), Moderate (Systemic)

• Impact 1 No direct fund loss.

• Impact 2 No accounting corruption.

• Impact 3 No financial loss, but poor validation and potential gas griefing.

  
  

  Severity: Low / Informational

  (Depending on contest rules, may qualify as Low due to inconsistent validation across core state-changing functions.)

Proof of Concept

Expected behavior: revert with DSCEngine__NeedsMoreThanZero
Actual behavior: executes successfully.

Root Cause

The external function redeem_collateral() delegates to _redeem_collateral() without enforcing:

Unlike other entrypoints in the protocol, zero-value input is not sanitized at the boundary.

Recommended Mitigation

1. Enforce Strict Input Validation at the External Boundary

Add explicit validation in redeem_collateral():

This ensures:

• Consistent validation logic across protocol entrypoints

• Prevention of meaningless state execution

• Cleaner integration semantics

• Reduced gas griefing surface

2.Optional Hardening (Best Practice)

Consider validating token approval at the external boundary as well:

Although currently validated in _deposit_collateral(), duplicating validation at the external boundary improves explicitness and defense-in-depth.

3.Design Principle Recommendation

All external state-changing functions should enforce:

• Non-zero numeric inputs

• Valid token addresses

• Clear revert reasons

Boundary validation is a protocol integrity requirement.

Conclusion:

This issue does not lead to direct fund loss but introduces inconsistent validation, unnecessary state execution, and potential griefing surfaces.

Enforcing strict non-zero validation at the protocol boundary strengthens reliability, consistency, and integration safety.