The Standard

The Standard
DeFiHardhat
20,000 USDC
View results
Submission Details
Severity: medium
Invalid

SmartVaultV3 Mishandling Of Burn Fees

Summary

The SmartVaultV3 contract's handling of burn fees in EURO tokens can lead to a systemic shortfall, preventing users from reclaiming their full collateral. This issue threatens the long-term viability of the protocol by locking in user funds and undermining trust.

Vulnerability Details

  • The SmartVaultV3 contract demonstrates a flaw in its accounting for minted EURO tokens, which should reflect the vault's debt. Users minting EURO tokens are charged a mint fee, and when they burn EURO tokens to recover their collateral, they incur a burn fee. However, the smartVault's burn function decreases the minted variable solely by the net amount of EUROs burned, not accounting for the burn fee. This discrepancy leads to a mismatch between the total EUROs users expect to burn (the sum of minted variable in all vaults) and the actual EUROs available in circulation.

Example Poc :

Consider a user (assume this is the first user for Simplicity) who creates a vault and deposits collateral to mint 10,000 EUROs. With a mint fee of 10%, the user ends up with 9,000 EUROs, while the protocol collects 1,000 EUROs as a fee. The situation is as follows:

  • User's EUROs: 9,000

  • Protocol's EUROs (mint fee): 1,000

  • Total EUROs minted (recorded by the user's smartVault): 10,000

  • EUROs totalSupply: 10,000

function mint(address _to, uint256 _amount) external onlyOwner ifNotLiquidated {
uint256 fee = _amount * ISmartVaultManagerV3(manager).mintFeeRate() / ISmartVaultManagerV3(manager).HUNDRED_PC();
require(fullyCollateralised(_amount + fee), UNDER_COLL);
minted = minted + _amount + fee;
EUROs.mint(_to, _amount);
EUROs.mint(ISmartVaultManagerV3(manager).protocol(), fee);
emit EUROsMinted(_to, _amount, fee);
}

When the user aims to reclaim their collateral, they attempt to burn all their EUROs. Facing a burn fee of 5%, they need to burn 10,000 EUROs. Assuming the user obtains the 1,000 EUROs initially given to the protocol as mint fees, we have:

  • User's EUROs to burn: 10,000

  • Burn fee (5% of 10,000): 500 EUROs

function burn(uint256 _amount) external ifMinted(_amount) {
uint256 fee = _amount * ISmartVaultManagerV3(manager).burnFeeRate() / ISmartVaultManagerV3(manager).HUNDRED_PC();
minted = minted - _amount;
EUROs.burn(msg.sender, _amount);
IERC20(address(EUROs)).safeTransferFrom(msg.sender, ISmartVaultManagerV3(manager).protocol(), fee);
emit EUROsBurned(_amount, fee);
}
  • For the user to burn their 10,000 EUROs, they must pay a 500 EUROs fee. However, there are no additional EUROs in circulation to cover this fee since the total supply is precisely 10,000 EUROs, all in the user's possession. Consequently, the user cannot burn the entire 10,000 EUROs due to the fee deficit.

  • As users burn EUROs and pay fees, the total supply of EUROs reduces, but the recorded debt does not accurately decrease. With numerous users and transactions, the system will face a liquidity shortfall, lacking enough EUROs for users to pay off their debts and fully close their positions. This results in a system that is technically solvent but practically illiquid.

  • For a synthetic asset like the EURO token, which aims to be stable, this logical inconsistency is particularly troubling. It undermines the stability and reliability of the EURO token, potentially preventing it from maintaining its peg and serving as a stable synthetic asset. If left unaddressed, this flaw could ultimately lead to the protocol's demise, as users lose confidence in the system's ability to maintain its core functionality,and because the vault is overcollateralized, users should always be able to close their positions and retrieve their collateral

Impact

  • Over the long term, the discrepancy in the SmartVaultV3 contract's fee accounting will result in a growing shortfall of EURO tokens. As more users attempt to close their positions, the cumulative effect of unpaid burn fees will increasingly prevent the full recovery of overcollateralized assets. This systemic issue can lead to significant capital being locked within the platform, undermining user confidence and the protocol's financial integrity.

Tools Used

manual review

Recommendations

  • To resolve the fee-related issues,i would recommend to use a separate asset (e.g., a native token, tst token) for the collection of burn fees. These fees can be directed to a dedicated system-controlled smartVault to mint euro tokens if needed,but distinct from individual user smartVault. This change ensures that the EURO token supply remains unaffected by fee deductions, allowing users to fully redeem their collateral from overcollateralized positions without encountering a token deficit.

Updates

Lead Judging Commences

hrishibhat Lead Judge over 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

fee-loss

hrishibhat Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Design choice
Assigned finding tags:

fee-loss

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.