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