Risk Disclosure

Dependencies

• Oracles: Chainlink for ETH/USD, UniswapV3 TWAP Oracles for TitanX and DragonX

Chain Risk

• Deployment chain: Ethereum Mainnet

• Cross-chain: none at launch (native to Mainnet and no cross-chain risks)

While USDx itself is native to Ethereum, it may eventually be supported by a cross chain messaging solution like LayerZero.

Smart Contract Risks

USDx has no manual pause, freeze, or shutdown functions. However, the protocol is capable of initiating an automatic shutdown of a collateral in case of an extreme price change of the respective collateral asset, or an oracle failure of that particular collateral asset.

• See our audits for more information: Pashov Audit Group, Hunter Sec

• Pause function: none

• Protocol freeze function: none

• Protocol temporary circuit breaker: If Uniswap V3 TWAPs diverge significantly

• Protocol shutdown function: Yes, it would be algorithmically targeted towards a specific collateral if the price of ETH/USD moves by more than 20%. A guardian will then manually verify that this was a valid or invalid price movement.

• whitelist or blacklist: whitelistable redemptions are possible

• transfer freeze functionality: none

Collateral Risk

• Collaterals assets accepted: TitanX, DragonX, with possible extensions pending timelocks and a multisig

• Collaterals assets accepted within the protocol are non-upgradeable and cannot be changed

What’s the shared-collateral risks? Each supported collateral asset constitutes an individual borrow market with its own group of borrowers and a unified Stability Pool backing their debts. This separation impacts user groups differently:

• Borrowers: Collateral risk is limited to the collateral asset held by the borrower. A borrower isn’t negatively affected by a failure of another collateral asset.

• USDx Holders: As a multi-collateral stablecoin, USDx is reliant on effective liquidations of undercollateralized loans in every borrow market to remain overcollateralized. Holders are subject to the risks of all supported collateral assets.

• Backstop Pool depositors get exposure to all supported system assets. However, as USDx holders, they are similarly affected by potential depegging.

Are there any safety mechanisms in place for potential de-pegs of the underlying collateral asset? The protocol aims to protect each borrow market from becoming undercollateralized by throttling debt creation and collateral withdrawal in unhealthy markets and by shutting down the entire market as a last resort. There are two safety thresholds:

Oracle Risk

If Chainlink oracles fail, collateral markets might get priced inaccurately, leading to unfavorable redemptions or excessive or delayed liquidations. Oracle staleness could also cause problems by using out-of-date prices during shutdowns, leading to improper liquidations or redemptions.

Infrastructure Risk

• Onchain infrastructure: None other than Infura nodes (transactions could get delayed or dropped) None for on-chain functionality.

Governance and Economic Risk

• Core protocol: is immutable - nothing can be upgraded

• Upgradable code: none

• Updatable parameters: redemption rates, loan rates, debt caps, MCR/CCR (after timelock and multisig), collateral list. See CollateralController contract for full list.

• Timelocks: 3 day timelock for new collateral inclusion, 1 day timelock for all critical administrative tasks

• ⅔ gnosis multisig is responsible for collateral setting updates

Bad Debt mitigation and Shutdown: In extreme cases, such as a severe drop in collateral value or failure of a supported collateral, the system may become undercollateralized. This could lead to the shutdown of a specific collateral, and the remaining debt could become "bad debt"—unbacked by sufficient collateral. This could in the worst case lead to bank runs: a portion of the system debt can not be cleared, and hence a portion of the USDx supply can never be redeemed.

Liquidity Risk and Liquidations

Potential risk: There's no guarantee that the liquidation gains are actually gains. In the worst case, e.g. when the oracle lags behind or a collateral flash-crashes within a few blocks, the gains could turn into losses. USDx tries to minimise this by using a weighted average price for the liquidation price, which is 'pullable' by 10% based on a short term TWAP.

Redemption mechanism and risk for USDx Stability

To prevent USDx from falling below $1, the platform includes a redemption mechanism. Any USDx holder can redeem 1 USDx for $1 worth of collateral, ensuring that USDx remains pegged to its intended value. Redemptions are prioritized by the lowest health Positions first. Importantly, redemptions do not result in a net loss for borrowers but ensure the peg remains intact.

Liquidation Process

In the event of liquidations, the system first looks to the Backstop Pool. If the Pool contains sufficient USDx, it burns an amount equivalent to the borrower’s debt and redistributes the borrower’s collateral to the Pool’s depositors. These depositors receive collateral, proportional to their deposits.

If the Backstop Pool is depleted and cannot cover the entire debt, the system falls back on two other liquidation modes:

• Just-in-Time (JIT) Liquidation: A liquidator deposits the amount of USDx needed to cover the remaining debt directly into the Backstop Pool, immediately triggering liquidation

• Redistribution Mode: If JIT liquidation is not chosen, the entire debt and the MCR% of it in collateral is redistributed to fellow borrowers who hold the same type of collateral. Their debt increases proportionally, but they also receive a share of the liquidated collateral, ensuring system-wide balance.

This multi-layered liquidation process ensures that each collateral market is isolated from the others, minimizing systemic risk and allowing users to manage their positions independently.

MEV Risks

Frontrunning risk: Borrowers may attempt to evade redemptions by either adjusting their Positions health or closing and reopening their Position. This "frontrunning" could occur when the USDx price falls below $1, as savvy borrowers try to protect their positions from redemptions that would otherwise target them based on their health. Both “hard” frontrunning (directly from mempool observations) and “soft” frontrunning (reacting to the USDx peg) could negatively affect redemption efficiency and system stability, while also unfairly affecting borrowers that are playing by the rules.

Mitigation: Two fees are applied to disincentivize this behavior:

1. Upfront Borrowing Fee: Charged when a borrower opens a Position or increases its debt. By applying this fee, borrowers are discouraged from continually closing and reopening Positions to evade redemptions, as it increases the cost of frequent adjustments.

2. Redemption and Loan Escrows: When loans are opened on volatile assets with lagging TWAPs, a loan escrow is enacted, which is also matched with a redemption escrow. This makes risk free front running of lagging price updates much more difficult, shifting the usually risk free actions of MEV to moreso a trading style risk equation, where uncertainty is created to disincentivise dishonest actions.

These measures help ensure that borrowers cannot easily front-run system redemptions, while also making oracle update front runs on redemptions more difficult.