Reported issues
No clear threshold on when the oracle is updated will cause stale prices to be accepted
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.
If any stable depegs, oracle will fail, disabling swaps
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.
Users may not be able to fully redeem USD1 into USDT even when reserve ratio is above 100%
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
No slippage or deadline control for swapping while stability burning
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
Unitas swap function is vulnerable to Sandwich Attack at oracle price update
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
USD1 is pegged to USDT instead of being pegged to USD
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
In case the portfolio makes a loss, the total reserves and reserve ratio will be inflated
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 updated