ABM Protocol
Search…
The Emergency Shutdown Process for Multi-Collateral dotBTC (MCD)

Introduction to the Emergency Shutdown Process

The ABM Protocol, which powers Multi-Collateral dotBTC (dotBTC ), backs and stabilizes the value of dotBTC to a Target Price of ATH of BTC. The stabilization mechanism is handled through an autonomous system of smart contracts, a dynamic combination of Vaults, and appropriately incentivized external actors, such as Keepers.
The ABM Protocol has an Emergency Shutdown (ES) procedure that can be triggered as a last resort to protect the system and its users against a serious threat or to facilitate a Protocol upgrade.

Overview of the Emergency Shutdown Process

Summary

Emergency Shutdown is intended to be triggered in the case of a system upgrade or serious emergencies, such as long-term market irrationality, a hack, or a security breach. When triggered, ES stops and shuts down the ABM Protocol while ensuring that all users, both dotBTC holders, and Vault users, receive the net value of assets they are entitled to under the Protocol’s smart contract logic. However, the value of Collateral that dotBTC holders can redeem may vary, depending on the system surplus or deficit at the time of ES. It is, therefore, possible that dotBTC holders will receive less or more than ATH of BTC worth of Collateral for 1 dotBTC .
The process of initiating ES is decentralized and controlled by ABM voters, who can trigger it by depositing ABM into the Emergency Shutdown Module (ESM), a contract with the ability to call End.cage or by an Executive Vote. In the case of the ESM method, 500,000 ABM must be deposited into the ESM to trigger ES. Additionally, once users deposit ABM into the ESM, it is immediately burned. Whether through the ABM or Executive Vote method, when Cage is called, it must alter the behavior of almost every component of the system, as well as perform under a variety of possible undercollateralization scenarios.

The Implementation Properties of Emergency Shutdown

  • dotBTC no-race condition: Every dotBTC holder will be able to redeem the same relative quantity of collateral proportional to their dotBTC holdings, regardless of when they interact with the contract.
  • Vault Parity: Vault Owners are prioritized, allowing them to withdraw their excess Collateral before dotBTC holders are able to access Collateral.
    • At the time of ES, individual Vaults, entire collateral types, or the ABM Protocol can be undercollateralized, which is when the value of debt exceeds the value of the Collateral ("negative equity"). Thus, the value of Collateral that dotBTC holders can redeem may vary, depending on the system surplus or deficit at the time of ES. It is, therefore, possible that dotBTC holders will receive less or more than ATH of BTC worth of Collateral for 1 dotBTC .
  • Immediate Vault redemption: After ES is initiated, Vault owners are allowed to free their Collateral immediately, provided that they execute all contract calls atomically.
  • No off-chain calculations: The system does not require the cage authority to supply any off-chain calculated values (i.e., it can rely entirely on the last OSM feed prices).
  • Vow Buffer Assistance: After ES is initiated, any surplus or bad debt in the buffer acts as a reward or penalty distributed pro-rata to all dotBTC holders. For example, if 10% of total system debt is in the form of net surplus in the Vow, then dotBTC holders receive 10% more Collateral.

dotBTC and Collateral Redemption During Emergency Shutdown

Emergency Shutdown Process for Vault Owners

Vault owners can retrieve excess Collateral from their Vaults immediately after the initialization of ES.

Emergency Shutdown Process for dotBTC Holders

dotBTC holders can, after a waiting period (for processing) determined by ABM voters, barter their dotBTC for a relative pro-rata share of all types of Collateral in the system. The amount of Collateral that can be claimed during this period is determined by the ABM Oracles at the time ES is triggered. It's important to note that dotBTC holders will always receive the same relative pro-rata amount of Collateral from the system, whether their claims are among the first or last to be processed. The ABM Protocol will initially offer a web page for this purpose to make the process easier for dotBTC holders.

Why Emergency Shutdown Prioritizes Vault Owners Over dotBTC Holders

The prioritization of Vault Owners over dotBTC Holders during ES can be broken down into three main points:
  1. 1.
    Overcollateralized Vaults do not subsidize the ABM Protocol for undercollateralized Vaults during the current operation of the system, so it's consistent for ES to have the same behavior. The main difference is that a potential haircut is transferred from ABM holders to dotBTC holders, as no assumptions can be made about the value of ABM after a shutdown.
  2. 2.
    Giving priority to Vault owners to recover their excess Collateral (if their Vault is not undercollateralized) incentivizes them to maintain overcollateralization. This is important because the incentive remains even if an ES seems likely, which ultimately makes the Protocol more resilient.
  3. 3.
    Stability fees accrued pre-ES are not waived by ES. Vault owners may accept higher fees if they know they are protected from the collateralization levels of others, potentially resulting in a higher surplus during ES scenarios as well as allowing for a higher DSR during normal operation.

Auction Settlement During Emergency Shutdown

There is a time delay in the Emergency Shutdown that is determined by governance. The delay must expire before any exchange of dotBTC for Collateral can take place. The general guidance is that the delay should be long enough to ensure all auctions either finish or get skipped; but, there is no guarantee of this in the code. Importantly, anyone can cancel a collateral (Flip) auction at any time, whereas Surplus (Flap) and Debt (Flop) auctions are frozen by the initial calling of Cage. Both Flap and Flop auctions can be called to return the bids to the last bidder.
Note also that auction cancellation is not an immediate process, as ecosystem participants must cancel all ongoing collateral auctions to appropriate the Collateral and return it to the collateral pool. This allows for faster processing of the auctions at the expense of more processing calls. As for the surplus and debt auctions, they must also be called. If no one calls these functions, the auctions will not be canceled.

Emergency Shutdown Intentions

Emergency Shutdown may take two main forms. For one, ES may be triggered, and the system is terminated without a future plan for redeployment. This allows users to claim excess Collateral or claim Collateral from their dotBTC .
On the other hand, Emergency Shutdown may be initiated with a Redeployment Scenario. This situation may arise when the system has been triggered into a shutdown event. Still, ABM token holders, or a third party, have decided to redeploy the system with necessary changes to rerun the system. This will allow users to open new Vaults and have a new dotBTC token while claiming Collateral from the old system.

How Emergency Shutdown Affects Users

During an Emergency Shutdown, each of the various ABM Ecosystem Stakeholders should act accordingly:

dotBTC Holders

If your wallet has the viable interface to claim Collateral or migrate your dotBTC , or it has a Dapp browser built into it, you may use the migration portal to claim Collateral and/or migrate. If your wallet does not support the above functionality, you must transfer your dotBTC to a new wallet that enables the functionality before proceeding to use the migration portal.

Vault Owners

If you use ABM/borrow app to manage your Vault, proceed to the migration portal and follow the outlined emergency redemption process.

ABM Holders

ABM holders may vote on polls and executive votes as it relates to the Emergency Shutdown triggering process. This is done in the Emergency Shutdown Module (ESM) frontend or directly through the ES CLI. Additionally, ABM holders may also vote as it relates to a future redeployment of the ABM Protocol on the Governance Portal.

Centralized Exchange or Custodial Wallet

In the case of Emergency Shutdown, service providers may follow the actions recommended below.
Recommended Procedure
  • Alert users to the current situation and provide guidance on the right action(s) to take. Depending on the ES scenario, Shutdown, or redeployment, advise them to act accordingly.
  • Give users options to withdraw their dotBTC/ABM from the exchange, or inform them that the exchange/wallet will handle the Emergency Shutdown process on their behalf.
Scenario: Shutdown
  • Choose one of the following options:
    • Option 1: Let users withdraw dotBTC and ABM from the platform, and then guide them to the migration portal for the redemption process.
    • Option 2: Claim dotBTC equivalent in Collateral on behalf of users using the migration portal.
    • Choose one of the following:
      • Distribute Collateral to users.
      • Get withdrawal address from users for collateral types not supported on the exchange.
      • Keep the Collateral (to sell off, for example) and update user internal fiat balances to reflect their entitled amount.
Scenario: Redeployment
  • Migrate dotBTC holdings to new dotBTC token on behalf of users using the migration portal.
  • Alternatively, carry out-migration by interacting directly with the migration contracts using CLI tools.
  • If applicable, migrate ABM token holdings on behalf of users using the migration portal
  • Update token address(es) in your system.

Non-Custodial Wallet

In case of Emergency Shutdown, non-custodial wallet providers should alert your user base about ES and provide public links for more information. You may follow the recommended procedures listed below in the case of Emergency Shutdown.
  • Scenario: Shutdown
    • Redirect users to the migration portal to claim their dotBTC equivalent in Collateral, or create an interface to handle the process locally.
  • Scenario: Redeployment
    • Inform users to migrate their dotBTC on the migration portal, or create an internal interface to handle the process locally.
    • Add featured support for new token(s).

Decentralized Exchanges (DEXs)

As a decentralized exchange, you can inform users with a banner about the current status of the ABM Protocol and direct them toward relevant communication channels to find out more. You may choose one of the two following options to allow your users to carry out the ES redemption process:
  • Direct them to the migration portal, where they can start the claiming process for their dotBTC.
  • Build an interface to handle the ES process on your platform, inform your users, and have them act accordingly.
  • Scenario: Shutdown
    • Inform users to claim equivalent value of dotBTC in Collateral on the migration portal or create an interface to handle the process locally.
  • Scenario: Redeployment
    • Inform users to migrate their dotBTC to the new dotBTC (and ABM if applicable) on the migration portal, or create an interface to handle the process on your platform.
    • Add new token(s) to the exchange.

Vault Integrators

As a Vault integrator, it is very important that you integrate with ABM Protocol contracts (more specifically, end.sol). This crucial integration will allow you to quickly create a reactive logic that will handle the post-ES process for your users. If you are a custodial service, such as a centralized exchange, please inform your users in advance about your plan on handling the Emergency Shutdown event. You may follow the recommended procedures listed below in the case of Emergency Shutdown.
Recommended Procedure
  • Scenario: Shutdown
    • Claim users’ funds through the migration portal or by direct interaction with the migration contracts, and make them available in their accounts.
  • Scenario: Redeployment
    • Migrate users’ funds to a new redeployed system using the migration portal or by interacting directly with the migration contracts.
As a non-custodial Vault integrator, please make sure to integrate with the ABM Protocol contracts (end.sol). This allows you to be notified at the exact moment the Shutdown has been triggered. Otherwise, it is suggested that you inform your users on how they can free Collateral in Vaults. If you do decide to use your own services, you will need a UI that allows users to withdraw their Vaults from a proxy contract so it shows up on the migration portal. Direct your users there. Alternatively, you may create an interface that will help users migrate their dotBTC in case of a new redeployment, or allow users to claim their Collateral in case of an only shutdown scenario.

Decentralized Applications (Dapps)

Dapps are suggested to integrate with ABM Protocol contracts (end.sol), which effectively provides a notification system that shows if Emergency Shutdown has been triggered. In terms of preparation, when ES has been triggered, have the following ready for your users:
  • A UI interface that alerts and informs users about the event.
  • If your Dapp uses a proxy, you will need to enable users to exit from the proxy in order to use the migration app/portal.
  • Provide official communication channels for more information as well as a link to the migration portal for dotBTC and Vault redemption.

Custodial Services

If you control access to the smart contracts backing your Dapp, it is suggested to allow your users to retrieve dotBTC or access their Vaults from their personal wallet as well as direct them to the migration portal for the ES redemption process. Alternatively, you may claim dotBTC collateral or claim excess Collateral from Vaults on behalf of your users at the migration portal, and proceed to distribute it to your users, ensuring that they successfully retrieve it.

Non-Custodial Services

If you don’t control the smart contracts backing your Dapp directly, then you may direct your users to the migration portal for dotBTC and Vault redemption. Alternatively, you may create an interface that allows your users to claim a dotBTC equivalent in Collateral, or claim excess Collateral from Vaults in case of a system shutdown. Additionally, if there's a redeployment of the system, migrate dotBTC to the new redeployed system and/or claim excess Collateral from Vaults.

Market Makers

As a market maker during ES, you may provide liquidity in the market so that dotBTC holders can exchange their dotBTC for other assets. After there is no market to cover, you can act as a dotBTC holder and start migrating dotBTC to new dotBTC in case of system redeployment or claim equivalent dotBTC collateral in case of a system-wide shutdown.

Detailed Description of the Emergency Shutdown Mechanism for MCD

This is an involved and stateful process that involves the following 9 steps.

1. Locking the System and Initiating Shutdown of the ABM Protocol (aka Caging the System)

Locking the prices down for each collateral type is done by freezing the following user entry points:
  • Vault creation
  • Surplus/Debt Auctions
  • dotBTC Savings Rate (DSR)
  • Governance entry points
Next, the system will stop all of the current debt/surplus auctions, allowing individual auctions to be canceled by calling a function that moves the first phase of a collateral auction to the End. This process is completed by retrieving the Collateral and repaying dotBTC to the highest bidder of the respective auction contract. One reason these auctions are frozen and canceled is that the Emergency Shutdown process is designed to pass along the system surplus or system debt to dotBTC holders. In general, there are no guarantees regarding the value of ABM during a Shutdown and the mechanisms that typically rely on ABM market value cannot be relied upon, ultimately resulting in there being no reason to keep running the auctions that impact ABM supply. More specifically, the reasons debt and surplus auctions get canceled are as follows:
  • Surplus auctions no longer serve their purpose. This is because, after a shutdown, the surplus is designed to be allocated to dotBTC holders. Thus, canceling surplus auctions during Shutdown allows the system to return the surplus dotBTC back to the Settlement engines balance and ultimately back to dotBTC holders.
  • Debt auctions also stop serving their purpose. This is because the bad debt is passed as a haircut (lower-than-market-value placed on an asset being used as Collateral in a Vault) back to dotBTC holders if there is no other system surplus available.
As for collateral auctions, they are not immediately canceled (but can be canceled by any user) because they are still tied to the valuable Collateral in the system. Collateral auctions continue to run, and Keepers can continue to bid on them. If there are no bidders, the live auctions can also be canceled.
Despite the fact that auctions can continue to run, this does not guarantee that all of the remaining Vaults are overcollateralized. There is also nothing to prevent the undercollateralized and unbitten Vaults from existing at the moment cage is called.
During this time, the function that adds the debt (total dotBTC wanted from the auction) cannot be called, as the function requires the system to be running normally, disabling liquidations after Shutdown. Additionally, after the End begins, all Vaults must be settled at the tagged price, and then the remaining Collateral from a settled Vault must be removed.
Overall, this results in collateral auctions being able to continue during Shutdown or by having them reversed by a user by canceling live auctions (similar logic to the surplus auctions). If an auction is canceled, the bids are returned to bidders, and Collateral is returned to the original Vault (with the liquidation penalty applied in the form of increased debt).
Notes regarding collateral auctions:
  • End moves the first phase of collateral auctions to the End by retrieving the Collateral and repaying dotBTC to the highest bidder.
  • The second phase of auctions allows bids to be made, while decreasing the quantity up for auction. During this phase, completed auctions are settled as they have already raised the necessary dotBTC and are already in the process of returning the Collateral to the original Vault holder.
Other Notes:
  • ABM could still have value if the current ABM token is tied to another deployment of the system. Note that the system makes no assumptions about the economic value of ABM post-Shutdown.
  • It is important to note that on-auction debt and surplus are canceled, and balances are transferred to the End contract. The last step in this process is to begin the cooldown period.

2. Setting the Final Prices for the Collateral Types in the ABM Protocol

This process is completed by setting the system shutdown price for each collateral type. The final prices are determined by reading the price feeds from the ABM Oracles. This is required, as the system must first process the system state before it is possible to calculate the final dotBTC /collateral price. In particular, we need to determine two things:
(a) The shortfall per collateral type considering undercollateralized Vaults.
(b) The total quantity of dotBTC issued (total debt), which is the outstanding dotBTC supply after including the system surplus/deficit.
Firstly, this is determined (a) by processing all Vaults with a function that cancels owed dotBTC from the Vault (described below). Next, (b) unfolds as described below.

3. Settling Vaults at the Final Price by Canceling Owed dotBTC

Next, the system will allow for the canceling of all the owed dotBTC from the Vault(s) in the system. Any excess collateral remains within the Vault(s) for the owner(s) to claim. Then, the backing collateral is taken.
Next, the debt is determined (b) by processing the ongoing dotBTC generation operations of the auctions. Processing the ongoing dotBTC generation ensures that the auctions will not generate any further dotBTC income. This guarantees that ongoing auctions will not change the total debt of the system, which also includes the two-way auction (collateral auction) model not allowing for any more dotBTC to be generated. Due to this, the dotBTC generation comes from the first phase of collateral auctions. Thus, if everything is in the second phase of an auction (bidding on the decreasing quantity up for auction), we know the generation is over. Generation is over when all auctions are in the reverse/second phase. In addition to ensuring that the auctions will not generate any further dotBTC , the dotBTC Savings Rate (DSR) must also be shut off during the End so that the total debt does not change.
Example:
In terms of user scenarios, the process begins with users bidding more and more dotBTC until the debt is covered. Next, they start offering less and less Collateral.
The auctions that are in the second phase (reverse auctions) no longer affect any more of the total debt, as the dotBTC was already recovered. Lastly, for the auctions in the first phase, they can be canceled, and the Collateral and debt returned to the Vault.
One of two methods can ensure that Collateral and debt are returned to the Vault:
  1. 1.
    The processing cooldown duration (length of the debt queue); or
  2. 2.
    By canceling live auctions.

4. Using the Cooldown Period or Canceling Live Auctions

  1. 1.
    Set the cooldown period. The duration of the cooldown period only needs to be long enough to cancel owed dotBTC from the undercollateralized Vaults, and cancel the live first phase auctions. This means that it can, in fact, be quite short (i.e., 5 minutes). However, due to the possibility of scenarios such as network congestion occurring, it may be set longer.
  2. 2.
    Canceling a live auction will cancel all ongoing auctions and seize the Collateral. This allows for faster processing of the auctions at the expense of more processing calls. This option allows dotBTC holders to retrieve their Collateral much faster. The next procedure is to cancel each of the individual Collateral (Flip) auctions in the forward first phase auctions and retrieve all of the Collateral and return dotBTC to the bidder. After this occurs, the second phase—reverse auctions—can continue as they usually would, by setting the cooldown period or canceling the live auctions.
Note that both of these options are available in this implementation, with the canceling of the live auctions being enabled on a per-auction basis. When a Vault has been processed and has no debt remaining, the remaining Collateral can be removed.

5. Removing the Remaining Collateral from a Settled Vault (Only After There is no Debt in the Vault)

Next, the system will remove the Collateral from the Vault. After the Vaults have been settled at the set final price and the owed dotBTC from the Vault has been canceled, the Vault owner can call this process as needed. It will remove all of the Collateral remaining after step 3—basically, all of the Collateral that was not backing the debt. If the user did not have debt in a Vault at the time of the End, he can bypass steps 3 and 4 and can proceed directly to this step to free his Collateral.

6. Stabilizing the Total Outstanding Supply of dotBTC

After the processing period has elapsed, the calculation of the final price for each collateral type is possible using the thaw function. The assumption is that all under-collateralized Vaults are processed, and all auctions have unwound. The purpose of this function is to stabilize the total outstanding supply of dotBTC . Note that it may also require extra Vault processing to cover the system's surplus. Checking that the amount of dotBTC surplus in the core Vault engine is 0 is a requirement during this phase. This requirement is what guarantees that the system surplus has been taken into account. Furthermore, this means that before you can stabilize the total outstanding supply of dotBTC, you must cancel the owed dotBTC from as many Vaults as needed to cancel any dotBTC surplus in the Vow. Canceling dotBTC surplus is done by canceling out the surplus and debt in the system's balance sheet before you can stabilize the total outstanding supply of dotBTC .

7. Calculating the Fixed Price for a Collateral Type, Possibly Adjusting the Final Collateral Price with Surplus/Deficit

In this step, the calculation of the exchange price for a given collateral type is determined, as well as the potential adjustment of that final exchange price in the case of deficit/surplus. At this point in the mechanism, the final price for each collateral type has been computed; dotBTC holders can now turn their dotBTC into Collateral. Each unit of dotBTC can claim a fixed basket of Collateral. dotBTC holders must first lock their dotBTC so that they can be ready to exchange it for Collateral. Once the dotBTC is locked, it cannot be unlocked and is not transferable. More dotBTC can be locked later, as well.

8. Locking dotBTC and Exchanging it for Collateral

This step is when Collateral is dispensed to the dotBTC holders who have already locked their dotBTC in to be exchanged. The larger the amount of dotBTC locked in, the more Collateral can be released to the dotBTC holders.

9. Exchanging the Locked dotBTC for Collateral (Proportional to the Amount Locked)

Lastly, the system will allow the exchange of some of the dotBTC that has been locked for specific collateral types. Note that the number of collateral tokens will be limited by how much locked dotBTC users have.