Background

Threshold USD is being built as a public good for the Threshold Network. Value gets captured to the Threshold DAO treasury instead of a protocol token.

Threshold USD is a fork of Liquity.

Liquity is a completely immutable system. Once a user has conducted a security audit of the source code they can be certain about how it works. At some point in the future if the price feeds no longer work the price feed logic will fail.

Threshold USD has the following high level differences to Liquity.

• Fees from minting and redemption go to the Protocol Controlled Value.
• There is no protocol token.
• Governance can add additional decentralised collateral types.
• The protocol takes a loan against its future fees to seed the stability pool. While the loan is in effect the DAO can not withdraw fees.

It is important to note that the protocol loan is essentially some “clever” accounting. The loan only leaves the protocol if used in taking a liquidation. The liquidated collateral is then converted back into thUSD using B.Protocol. Deep liquidity in thUSD — 3CRV and TBTC — WBTC pools is necessary for efficient routing. This is so that LPs don’t need to wear the Impermanent Loss risk of a thUSD — TBTC pair.

Immutability provides certainty at the expense of adapting to new information. We balance these needs by allowing governance to control the thUSD token mintlist.

Considerations

1. Collateral Changes.
2. Price Feeds.
3. Protocol Controlled Value.
4. New Features for the protocol.

1. Collateral Changes

Adding a new collateral type requires an on-chain DAO vote. First to start the change and then finalise adding a new collateral. This adds the BorrowOperations contract into the minlist.

At launch it may look like:

In the future STETH and WETH may be added as collateral, which would look like:

Controlling which contracts can mint maintains flexibility for DAO approved changes.

Vesta Finance (also a Liquity fork) uses a similar approach, but all the collateral is in one set of contracts. Vesta supports more collateral types, with one price feed per collateral. Having all collateral in one contract makes it more difficult to change price feed logic.

Attack Vector: Adding collateral without a fixed supply schedule. Some tokens have the ability for governance to mint tokens. A Malicious protocol could mint, borrow and redeem against harder assets like BTC and ETH. The Mochi protocol is a good example of this type of risk.

Mitigation: New collateral requires discussion on the forums and a sponsor to move to a DAO vote. Two time delayed on-chain votes are required to call this function. The Threshold Council can veto these votes. The addition of collateral types beyond TBTC and ETH will require a high bar is met.

Attack Vector: Remove all collateral types
An attacker could remove all collateral types and cause user funds to be stuck. If the Total Collateralisation Ratio falls below 110% redemptions become blocked.

Mitigation: To remove a collateral requires the same steps as adding a new collateral.

Right of redemption in a graceful upgrade.

Upgrading a collateral’s logic has the same process as adding a new collateral.

The goal is to have a stable coin with decentralised collateral.

Some high level things to know

• Redemption is against the trove with the lowest c-ratio first.
• If a troves c-ratio falls below 110% it can be liquidated for profit.
• In the event of a bank run the redemption fee scales
• The c-ratios of users deposits should be over a range.
• Troves below the Minimum Collateral Ratio are skipped for redemptions. They get proportionally redistributed across all troves.
• In recovery mode, debt and collateral is redistributed if the Individual Collateral Ratio falls below 100%. This is proportionality distributed across all the other borrowers.
• Redemptions are blocked when the Total Collateral Ratio is less than 110%.

These are considerations when new contracts are deployed and capital needs to migrate. The Total Collateral Ratio is for a set of contracts and not shared across collateral types.

Sunsetting contracts requires removing the restrictions on redemptions.

2. Price Feeds

There are two approaches to making changes to the price feed.

• Migrating assets to a new set of immutable contracts.
• Having upgradeable contracts.

The downside to upgradeable contracts is that it places a burden on the user. The user needs to stay up to date in what the project is doing.

The benefit of migrating assets between immutable contracts over upgradeable contracts is certainty. Once a user has reviewed the code they can be confident in how the system will operate.

Attack Vector: Poisoned Price Feed
Upgradeable price oracles are vulnerable to an attacker replacing the price feed.

It is also possible that an attacker could compromise an existing feed.

Mitigation: Changing the price feeds requires deploying new contracts. To surface the new contracts to users also requires an update to the UI.

Deploying new contracts is a two step process. First the DAO votes to start using the new contracts, then after 90 days the DAO votes to confirm the change. Both the initiation and confirmation votes can be vetoed by the Threshold Council.

Using two price feeds helps to protect the network from artificial price manipulation.

Attack Vector: Frozen Price Feed
Price movements when a price feed is not updating allow an attacker to profit. This risks the protocol becoming under collateralised.

Mitigation: If the timestamp more than four hours old, the system uses the fallback oracle. It is worth noting that the switch from the primary oracle is based on its state, not the price. In the event that both oracles become frozen then the last good price is used as a fallback.

Attack Vector: Hard Fail
While the price feeds work today there are no guarantees for the future.

Mitigation: If a price feed no longer works, minting is removed for that group of contracts. A new set of contracts with a different price feed is then deployed. Users would be encouraged to migrate their deposits.

The DAO would need to take action if both price feeds for an asset are sunset.

Scenario: Changing price feed logic
If an improved oracle system becomes available, new smart contracts would be deployed. The old group of contracts would be removed from the mintlist. The old contracts would continue to operate without minting functionality.

3. Protocol Controlled Value

Liquity seeds its stability pool through token incentives. Threshold USD seeds the stability pool with a loan to itself against future fees. Protocol fees get paid to the PCV. The fees are accessible to the treasury after the protocol loan has been paid in full.

Liquity and Threshold USD will still function in the event of the stability pool being empty.

Each set of contracts has a seperate PCV contract.

Attack Vector: Unbacked tokens
The protocol is essentially doing some “clever accounting” in seeding the stability pool. The protocol is kept in balance as the loaned funds in the stability pool cant be withdrawn for other uses. If an attacker could remove the loaned tokens, they could redeem them. This would leave the circulating tokens unbacked.

Mitigation: Restricting PCV actions to time gated governance votes. Non transferable ownership of the PCV contracts.

Attack Vector: New logic
Upgradeable PCV logic introduces the risk of an upgrade making the loan transferable.

Mitigation: Changes requires deploying a new set of contracts. The initial loan to seed the stability pool will only be for the first type of collateral.

4. New Protocol Features

Some thUSD functions have restrictions on which contracts can call them. Each Stability Pool, Trove Manager and Borrower Operations gets stored for this purpose.

The minting functionality gets gated by a mintlist. This allows minting to be revoked from the Borrower Operations contract. The rest of the functionality for Borrower Operations continues to function.

LUSD has traded at a premium in times of market stress which limits its utility. Long term success for Threshold USD will be dependant on the stable coin being able to remain stable.

Other types of contracts might be added to the mintlist through governance. An example of this might be a vending machine contract to release pressure on the peg. Allowing restricted minting against other decentralised stable coins as collateral.

Allowing a finite amount of thUSD to be minted at a fixed premium.

Some of the premium would go to the treasury.

Once the market pressure subsides then bots will be able to arb out the premium.

This would leave the vending machine empty.

Restrictions would limit the amount of other collateral backing thUSD by proxy. If this was ineffective or risky, the contract could simply be removed from the mintlist.

Attack Vector: Minting unbacked tokens
This introduces the risk of unbacked or centralised collateral entering the system.

Mitigation: Adding to the mintlist requires the same steps as adding a new collateral.

Summary

We try to balance the certainty of immutability with adapting to new information.

• The deployed contracts are immutable so users can audit and trust them.
• Upgradability gets preserved through a mintlist on the thUSD token contract.
• Changes to the mintlist get made through a two step, time gated governance vote.
• Governance votes can be vetoed by the Threshold Council.

We trade the risk of an oracle not being available in the future for the risk of humans subverting time gated governance.