Comment on page
Reported issues
- Will fix
- The oracle was not checking for the freshness of the price. We fix this to check for price timestamp and trigger an update for the price or the timestamp.
- Won't fix
- The oracle does not reject a price change but only limits the maximum change
- If the EMC price keeps going in one particular direction, the oracle will keep updating the price with maximum allowed change in place
- At the surface it may look like that it enables arbitrage opportunities and protocol may lose funds but in reality arbitrage is not efficient because there is limited secondary market for Unitas tokens
- Other markets for Unitas tokens are CEXs where the fee is 0.5%-1% on each transaction. Additionally there is transaction fee levied by the Unitas protocol on each EMC conversion. Combining this with gas fee, the protocol limits the opportunities of arbitrage unless the price deviation is high enough.
- Because CEXs to DEX is not an efficient wrt time, it is difficult to make a profit. Adding this to fact that the oracle consecutively updates the EMC prices.
- Arbitrage can be profitable at large transaction volume but by virtue of being small, the protocol limits big transactions. Any big transaction will change the over-reserve ratio and will stop new minting.
- Won't fix
- The team may decide to put a portion the reserve USDT to use to generate additional yield
- This process initially is going to be manual
- The team will ensure that reserve pool has enough percentage of the USDT available for redemption
- Won't fix
- There is no stability burn designed for phase 1
- When stability burn is enabled, it will only burn the protocol profit
- Protocol will generate revenue and store it in the treasury wallet
- All USD1 in the treasury belongs to the protocol and has no liability to any users
- When USD1 is burnt from treasury it only decreases the overall supply while keeping the USDT in the reserves, leading to decrease in over-reserve ratio
- Won't fix
- Because Unitas does not user xy=k style pool for swaps, sandwich attack is not possible
- In case of xy=k pools like Uniswap and Curve, each transaction impacts the price, but in Unitas price is not driven by the transactions but market price of USDT/EMC
- Won't fix
- In Unitas phase1 all accounting based upon on USDT
- If USDT depegs, protocol only redeems USDT for USD1, in 1:1 ratio
- This means that no matter what USDT is valued at, 1 USD1 = 1 USDT
- Another argument is USDT depeg fud is common but USDT repegs itself pretty quickly
- Won't fix
- In phase 1 we will be conservative and take minimum to no risk reserve USDT
- We can diversify and risk manage but the simplest and the best method is to not use any USDT to generate additional yields
Last modified 4mo ago