OZ Fix: ezETH Renzo Library Rounding

[junkim012]

TODOs

OZ

• ezETH Library Changes

ezETH Library Changes

The main problem is that due to multiple truncating divisions, there may be a broad range of ethAmountIn that leads to the samemintAmountOut. There are two goals to the ezETH library with regards to handling this rounding error induced by the Renzo math.

1. Minimize cost for users by allowing them to reach the desired mintAmountOut at the lowest possible ethAmountIn.
2. Minimize the difference between the desired mint amount and the actual mint amount, minimizing the difference in expected and actual deposit amount.

Old Method vs. New Method Comparison

• The old method refers to the getEthAmountInForLstAmountOut function that this PR modifies, which began by calculating the ethAmountIn with mintAmountOut - 1, and subsequently incrementing the inflationPercentage.
• The new method refers to the getEthAmountInForLstAmountOut function in this PR, which does a simple backcompute, and rounds up the final ethAmountIn.
• Although we show things empirically via fuzz, we do not yet have a formal theoretical understanding of the rounding behavior, so we resort to observations to make this decision.

1. Changes in the dust bound [Old vs. New]

• Fuzz Setup
  • _existingEzETHSupply bounded between [1e18, 120Me18] (120Me18 being an absurdly high existing ezETH supply).
  • exchangeRate bounded between [1e18, 3e18].
  • minMintAmount bounded between [1e9, _existingEzETHSupply] (Assumes that no one mint amount is greater than the entire supply).
• Observations
  • The old method dust is always greater than new method dust
  • The difference between the old method dust and the new method dust bound is approximately 1e9.
  • Out of 100K runs,
    • 148 runs had old method dust < new method dust.
    • 2329 runs had old method dust > new method dust
    • 97523 runs had old method dust == new method dust
• Summary
  • Most of the times, the two methods were equal, but the new method reduced the dust amount in ~2% of the overall runs.

2. Changes in the ethAmountIn [Old vs. New]

• The goal is to minimize the ethAmountIn while minting at least the minimum amount out.
• Observations
  • Out of 10K fuzz results,
    • 9576 runs resulted in equal ethAmountIn’s
    • 420 runs resulted in old method ethAmountIn greater than new method ethAmountIn
    • 2 runs resulted in old method ethAountIn less than new method ethAmountIn
  • Out of 100K fuzz
    • 156 runs had old method ethAmountIn < new method ethAmountIn
    • 2400 runs had old method ethAmountIn > new method ethAmountIn
    • 97444 runs had old method ethAmountIn == new method ethAmountIn
• Summary
  • Again, most of the times, the two methods were equal, but the new method more frequently minimized the ethAmountIn.

New Method Fuzz

1. Is the new backcompute always optimal for users?

• We consider the ethAmountIn to be optimal "if one less than the ethAmountIn would have resulted in a mintAmount less than the minimum amount out."
• Out of 100K fuzz results
  • The output of ethAmountIn - 1 was always strictly less than the output of ethAmountIn, showing that this ethAmountIn was optimal.

2. Is there an exact maximum dust bound?

• We still don’t have a theoretical bound to the maximum amount of dust that can be greated given the user input and known variables. This fuzz sets out some guarantees at ‘realistic’ worst-case values.
• Fuzz Setup
  • Max bound for existingEzETH fuzzed assuming all circulating ETH turns to ezETH. ~120Me18 tokens.
  • The exchangeRate will most likely not exceed 2e18 (doubling value through staking yield).
  • The incoming mint amount being less than double the entire supply of ezETH (impossible since we are also assuming that ).
• Observations
  • Even fuzzed with these extreme max bounds, the max dust does not exceed 1e9.

Conclusion

1. With the fuzz, we can see that the ethAmountIn is optimal.
2. There is no formulaic bound on max dust, but there is a realistic-worst-case bound.
   The new method simplifies logic and is shown to lower cost for users (with smaller ethAmountIn) and with lower dust (which doesn’t affect ‘cost’ as the dust gets deposited into user vaults, but reduces the non-exact behavior of the contract).

[openzeppelin-code]

OZ Fix: ezETH Renzo Library Rounding

Generated at commit: 8d2fcc90250999f739e3e3289f6aaa31fbbcee15

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 10 37 51
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector