YuzuUSD

Striking the NAV in YuzuILP, i.e. realising the actual yields into the poolSize, requires the admin calling updatePool while the contract is paused. This pausing serves the purpose of stopping deposits and redemptions which affect the poolSize, preventing possible sandwiching attacks, and allowing the admin to pass the exact currentPoolSize to updatePool while the pool size remains constant.

However, pausing a contract has the undesirable effect of causing all interactions with it from all users to fail. Usually protocols implement a paused state as a last resort against ongoing attacks, to be used only under special circumstances. However, here pausing is part of the normal operation of the contract and will happen on a regular basis. Note that the paused state needs to remain for several blocks since the admin first needs to pause, wait for the transaction to finalize, then call updatePool, wait again, and finally unpause.

Users who happen to submit transactions during this window will not only lose their gas, but they will also be confused about the reason for this failure and will have to understand the cause and resubmit their transaction.

We recommend either to change this design, or at least to provide an off-chain solution (e.g. plan carefully for pool updates, advertise the pausing windows in the UI, disable the operations in the UI, etc).

YuzuProto, the functionality of which the three main token contracts inherit to varying degrees, allows both instant and delayed redemptions. Instant redemptions are funded through the liquidity buffer in the token contract, while delayed redemptions are funded by a third-party.

However, deposits and withdrawals are not symmetric in the way they interact with the liquidity buffer:

• Withdrawn tokens are removed from the liquidity buffer.

• But deposited tokens are sent to the treasury, not to the liquidity buffer.

This asymmetry allows a malicious user to drain the liquidity buffer at any moment as follows (for example in YuzuUSD):

• The liquidity buffer has X USDC
• The malicious user mints X YuzuUSD by supplying X USDC (the latter are transferred to the treasury).
• Then immediately redeems X YuzuUSD, acquiring back X-fee USDC from the contract.
• The liquidity buffer is now empty (while the treasury has X new tokens and the fee receiver has the fees).

This “draining” action can be used by the malicious user as a DoS mechanism: the user can monitor the transactions and perform such a drain every time the admin adds new liquidity (or frontrunning users who perform instant redemptions).

Of course “draining” has a cost, since the malicious user needs to pay for the fees (and the gas of the transaction). However, fees are only a disincentive, not a real mechanism to prevent DoS. First, the fees are configurable (they can even be set to zero) so a low fee can make such an attack realistic.

More importantly, DoS attacks by nature do not need to be directly profitable to be attractive to a malicious user, the real incentive could very well lie outside the protocol. For instance:

• A malicious user might try to depeg the token. If they can effectively block instant redeems for a prolonged period, users might lose faith in the system and start selling the token, allowing the malicious user to gain more than the cost of the attack by shorting the token. Faith in the system is important in stablecoins.
• In a different scenario, a competitor might benefit from a DoS by causing bad publicity and driving users to their own protocol. The gain of such a move could outweigh the cost, making the attack profitable.

Given the above, we recommend making the protocol more resistant to such attacks. For instance, deposits could be sent to the treasury only if the liquidity buffer is healthy, ensuring that an instant deposit and withdrawal do not immediately drain the buffer.

In YuzuILP (Insurance Liquidity Pool) the poolSize and dailyLinearYieldRatePpm are together used to calculate the total assets of the pool. poolSize changes accordingly on deposit or redeem. YuzuILP.updatePool is used to realise actual yields, include them in poolSize and to update the daily rate.

Given an update, there is no enforced relationship between the previous poolSize and the new poolSize. This centralisation is by design, given funds are held in a separate treasury contract, and accruing real yield elsewhere. Nonetheless, this setup requires complete trust in the admin to update values that totally control the value of the users’ assets. We advise that any off-chain processes handling these updates are well thought out, tested, and audited for robustness, to ensure trust in the system.

A separate treasury contract, which was not under audit, holds all of the users’ collateral. Then, for YuzuUSD tokens, standard redemptions are funded through the liquidity buffer of the contracts themselves, while redemption orders are funded through a caller contract. For StakedYuzuUSD redemption orders are also funded through the contract itself.

This requires significant trust that the contract is funded appropriately by the admin (i.e. providing an appropriate liquidity buffer), and that redemption orders will eventually be fulfilled. There is also no guarantee about the order in which orders are fulfilled. If the contract’s liquidity buffer is not maintained, then, for YuzuUSD, only non-guaranteed redemption orders are available to the user.

• Redemption fees in YuzuProto.
  • Treasury contract address in YuzuProto.
  • Supply cap of the different tokens.

IYuzuILPDefinitions defines two unused errors: InvalidPoolSize and InsufficientPoolSize.

The redemption fees (see YuzuProto::{setRedeemFee, setRedeemOrderFee}) are a maximum of 100%. Consider a more reasonable fee maximum, to avoid possible errors in fee setting from having negative effects on the protocol and users.

Building the project produces a large number of compiler warnings, for insurance:

• Unused function parameter in several functions
• Function state mutability can be restricted to pure again in several functions

Although none of the warnings affect the functionality of the protocol, we recommend fixing them, not only to make the code cleaner, but also to ensure that future more critical warnings do not remain unnoticed.

Note that unused parameters can be removed from base contracts even if they are used in subcontracts. For clarity they can be added in comments, eg
function _withdraw(address /* caller /, address / receiver */, ...)

Note finally that some of the warnings are “bogus” and cannot be fixed (eg unreachable code). In this case they should just be silenced.