Minimal required changes to revive a BitShares MPA after a black swan event?

Motivation

On #bitshares, market-pegged assets, aka MPA, aka #SmartCoin s, can suffer a "black swan" event. A black swan occurs when the least collateralized short position has insufficient collateral to buy back the borrowed SmartCoins at the current feed price. What happens then is that the MPA is tagged with a "settlement price", defined as the collateral ratio of the least collateralized short. All short positions are closed automatically, by collecting sufficient collateral into a settlement pool and paying out the remainder to the short's owners. MPA holders can use the forced settlement operation to receive their share from the settlement pool in exchange for their MPAs.

MPAs that have suffered a black swan are effectively dead. They can still be transferred or traded, but they can no longer be shorted. Eventually, all significant holders wlll have settled their positions, and some dust will remain scattered all over the place, where the value of the dust position is lower than the fees required to get rid of it.

The same is true for #Prediction-Markets. Prediction Markets don't suffer black swans, but at some point the prediction will be resolved in the same way that an MPA resolves a black swan - i. e. a settlement price is defined, short positions are closed, and holders can settle their positions individually. After that, the Prediction Market is effectively dead.

The most recent example of a black swan is #GRIDCOIN, and I think it has left a bad impression on its issuer, and serves as a bad example for possible future candidates:

That's unfortunate & quite a short lived experiment in BitShares by the Gridcoin community then. [...] I hope black swan handling/recovery functionality is added into BitShares in the future, time to look into other DEXs.

I also believe that the one-shot property is one of the major reasons why prediction markets haven't gained traction yet.

Goal

I'd like to find a minimally invasive way to revive assets after a global settlement or black swan event. Since we currently don't have a designated dev team, this will have to be done as a community effort. Community support is also required because we need to implement and accept a hardfork for this.

I'm looking for a "minimally invasive" solution because

• I want to avoid breaking things, obviously.
• I hope a small change can be done without the usual hassle with worker proposals. I'd volunteer to implement changes, but I will need help testing.

Starting point

Reviving MPAs / PMs consists of two basic steps, IMO:

1. Resolve all open positions
2. Reset the asset object in the database to a usable state

I believe the second step is safe to do after the first has been completed.

• For an MPA, it is sufficient to remove the settlement price. Once it has been removed, price feeds can be published again, and with sufficient price feeds, shorting becomes possible.
• PMs should be reset into a state that requires issuer action to re-enable shorting, possibly by setting some flags at the time the settlement price is removed.
  Both can be done within a maintenance interval at little computational cost.

The first step, however, looks much trickier to me. For example, I'm not clear about what are "open positions":

• holders
• market orders (sell and buy)
• shorts that use the to-be-revived asset as collateral (?)
• fee pool
• anything else?

For each type of "open position", we need a way to close it. Suggestions:

• Resolve holders by allowing the issuer to invoke forced settlement if the asset has a settlement_price.
• Resolve market orders by allowing the issuer to cancel orders if one of the assets has a settlement_price.
• Ignore the fee pool - it belongs to the issuer anyway.
• For shorts I don't see a solution, but that should be a rare case. I hope.
• Anything else?

By allowing the issuer to take action we avoid overly complex computations. The fees should be paid by the issuer. We might want to offer a reduced settlement fee in that case, since protecting shorters is not necessary at this point.

Please join the discussion on BitSharesTalk!