Author Topic: Trustless, Decentralized Bond Market Draft  (Read 11473 times)

0 Members and 1 Guest are viewing this topic.

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
Interesting feature I found on BTC-China's Pro Exchange.  When it comes to forced liquidations, they use something called Early Assignment Profit.  See below.  Perhaps this is something we could employ.  Although like a few others here, I think it makes more sense to implement a bitcoin sidechain first. 


Pro Exchange uses Early Profit Assignment™, which means that when there are forced liquidation events and a lack of liquidity, the platform will automatically select and close the highest earning positions, and immediately notify the customer(s) whose positions have been closed. Early Profit Assignment™ immediately locks in customer(s)’ profits when it closes their positions, and the customer(s) can re-open their positions as they choose. Early Profit Assignment™ ensures that forced liquidation events never cause systematic losses, and thus eliminates the need for socializing losses from winners.
Interesting. But maybe only practicable in a liquid market.
1. what price will be used on the force-closing?
2. To prevent from force-closing of positions, traders will probably compete on closing old positions which already have enough profit then opening a new position.

BitShares committee member: abit
BitShares witness: in.abit

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
Interesting feature I found on BTC-China's Pro Exchange.  When it comes to forced liquidations, they use something called Early Assignment Profit.  See below.  Perhaps this is something we could employ.  Although like a few others here, I think it makes more sense to implement a bitcoin sidechain first. 


Pro Exchange uses Early Profit Assignment™, which means that when there are forced liquidation events and a lack of liquidity, the platform will automatically select and close the highest earning positions, and immediately notify the customer(s) whose positions have been closed. Early Profit Assignment™ immediately locks in customer(s)’ profits when it closes their positions, and the customer(s) can re-open their positions as they choose. Early Profit Assignment™ ensures that forced liquidation events never cause systematic losses, and thus eliminates the need for socializing losses from winners.

Offline donkeypong

  • Hero Member
  • *****
  • Posts: 2329
    • View Profile
Honestly, I think this is like Stealth. It will be nice to have, but I wouldn't choose to grant it a high priority. Why? Because we should focus on projects that improve this ecosystem by bringing in more liquidity and market cap. We need to take some bigger steps, bigger risks, make a bigger splash. How many people will actually use these bonds who aren't already long term investors?


Sidechaining first
Bond Market second

Sounds good to me.
« Last Edit: March 03, 2016, 03:53:58 am by donkeypong »

Offline giant middle finger

  • Full Member
  • ***
  • Posts: 99
    • View Profile
Let's work on sidechaining first and let the big banks decide on their standard crypto based  bond market format:

http://mobile.reuters.com/article/idUSL8N16A30H

We will fork their format after they are done. Why waste resources. We are just going to have to conform to this market standard eventually.  Measure twice, cut once.

Remember how many times we tweaked the DEX?  Let's learn from someone else's trial and error for a change.

Sidechaining first
Bond Market second
« Last Edit: March 03, 2016, 06:28:45 am by giant middle finger »

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
How is the bitshares blockchain going to handle to computation intensity of this algorithm, while attempting to maintain 3 second block times?  3 seconds may not be enough for a witness to calculate the required liquidation cascade and then broadcast the block.    Given the importance of what takes place in that block, it seems very important that it not result in a fork or orphaned block.  Do we have plans to handle these issues?
Good question.

I think we need to do some stress testing first, so we can know our capacity, and maybe set some limitations at first, for example maximum number of orders, max spread and etc. While the market grows, we improve the code, improve hardware of witnesses, adjust parameters etc.
BitShares committee member: abit
BitShares witness: in.abit

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
1. If canceling an open order would result in insufficient orders on the books to buy back the debt with the collateral, then a margin call is executed first, then the order is canceled (if it wasn’t used as part of the margin call).

To BM/Devs, I know this might not be the next feature, but  what would be a ballpark development time and cost for it be?
It sounds like the system is front-running. I don't think it's a good behavior.

//Update: however, if all participants already know the rules/risks, and still participate in the market, it's acceptable for me.
« Last Edit: March 01, 2016, 12:10:09 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
In Polo, it seems that if you have at least the maintenance collateral amount you're safe unless the price moves against you, in this model it seems you can be margin called based on orders moving around/being removed from the book. Is it the same on polo, if not could this put of borrowers off or not really in your opinion?

Imo we should replicate the polo system as much as possible, as it is proven to work.  (In a year, there has not been a black swan big enough to cause a failure, even with some wild swings in prices). 

In the polo system, lets say that you go long BTS, to the maximum allowed 40% margin requirement.  (2.5x
long).  Polo doesnt actually check against the last price that the coin was traded at to see if your margin is okay, it checks against the buy orders that are on the books.  So if the last price of a trade was 900 sats, but there is no buy orders down until 850 sats, it actually looks at the 850 sats to calculate your margin.  And if that 850 sat buy order is not big enough to cover your position (your long is more BTS), then it will look down the order book further until it gets to the point where it sees how you can cover all of your position. 
This is similar to what BitShares 2.0 did at the beginning: a trial to eliminate price feeds. The market need to have liquidity first (huge buy wall) to support such feature.

//Update: Just saw it's mentioned in the rest of your post.
« Last Edit: March 01, 2016, 12:05:38 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
In Polo, it seems that if you have at least the maintenance collateral amount you're safe unless the price moves against you, in this model it seems you can be margin called based on orders moving around/being removed from the book. Is it the same on polo, if not could this put of borrowers off or not really in your opinion?

Imo we should replicate the polo system as much as possible, as it is proven to work.  (In a year, there has not been a black swan big enough to cause a failure, even with some wild swings in prices). 

In the polo system, lets say that you go long BTS, to the maximum allowed 40% margin requirement.  (2.5x
long).  Polo doesnt actually check against the last price that the coin was traded at to see if your margin is okay, it checks against the buy orders that are on the books.  So if the last price of a trade was 900 sats, but there is no buy orders down until 850 sats, it actually looks at the 850 sats to calculate your margin.  And if that 850 sat buy order is not big enough to cover your position (your long is more BTS), then it will look down the order book further until it gets to the point where it sees how you can cover all of your position. 

The amount of BTC you could get by market selling your position onto the books is how much poloniex actually considers your position to be worth.

From what I understand of bytemasters proposed system, it works the same.



Lets say that the person with the buy wall at 850 sats in our example cancelled his order.  Now, polo recalculates how much you could sell your BTS for. Lets say that the 850 wall was a big wall and you were relying on its existence.  Without it, poloniex sees that you would have to dump all the way down to 400 sats in a liquidation!   It recalculates your margin and determines that you are below the 20% liquidation level and are no longer safe. Therefore it autoliquidates your position, and crashes the price to 400 sats.


So the removal of an order from the books on polo can trigger forced liquidations.  Bitshares would need to do the same thing.  Its necessary in order to protect lenders.


I might suggest that for robustness sake, that if this scenario occurs that what Bitshares should do is to not allow the order to be cancelled but instead to liquidate the position into it, when the person tried to cancel the order.  Essentially, when the buy wall owner submits the order to cancel to the blockchain, the blockchain responds 'oh no, if you pull that order then it will cause forced liquidations.  Therefore you cannot pull the order, and the forced liquidations are happening now instead'. 


What will happen as a result of this is that people are going to put in big buywalls, and others are goign to take margin positions in front of them, and then the buywall placers are going to pull their walls in order to get cheap (whatever theyre buying).  This happens on polo.  Its what happened when Bitshares crashed after the 2.0 release, the price would start to drop, a whale would remove a buy order, and it would trigger liquidations.

But there isnt any way to avoid this if we want to protect lenders, and imo we NEED to protect lenders.  Lending needs to be safe.  The margin traders take all the risk.  After all, everyone knows margin trading is risky.

 +5%  +5% Thanks for the detailed response & explanation Ander

Quote
Imo we should replicate the polo system as much as possible, as it is proven to work. 

 +5% I agree, I'm always in favour in using what has already proven to work, is popular and with the settings people are familiar with.

Quote
I might suggest that for robustness sake, that if this scenario occurs that what Bitshares should do is to not allow the order to be cancelled but instead to liquidate the position into it, when the person tried to cancel the order.  Essentially, when the buy wall owner submits the order to cancel to the blockchain, the blockchain responds 'oh no, if you pull that order then it will cause forced liquidations.  Therefore you cannot pull the order, and the forced liquidations are happening now instead'. 

It looks like this proposal already has that feature too?

1. If canceling an open order would result in insufficient orders on the books to buy back the debt with the collateral, then a margin call is executed first, then the order is canceled (if it wasn’t used as part of the margin call).

To BM/Devs, I know this might not be the next feature, but  what would be a ballpark development time and cost for it be?
If you want to take the island burn the boats

Offline CoinHoarder

  • Hero Member
  • *****
  • Posts: 660
  • In Cryptocoins I Trust
    • View Profile
[    ] killer app
[ x ] nice feature
[    ] should be high up on the priority list
« Last Edit: March 01, 2016, 04:49:11 am by CoinHoarder »
https://www.decentralized.tech/ -> Market Data, Portfolios, Information, Links, Reviews, Forums, Blogs, Etc.
https://www.cryptohun.ch/ -> Tradable Blockchain Asset PvP Card Game

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
In Polo, it seems that if you have at least the maintenance collateral amount you're safe unless the price moves against you, in this model it seems you can be margin called based on orders moving around/being removed from the book. Is it the same on polo, if not could this put of borrowers off or not really in your opinion?

Imo we should replicate the polo system as much as possible, as it is proven to work.  (In a year, there has not been a black swan big enough to cause a failure, even with some wild swings in prices). 

In the polo system, lets say that you go long BTS, to the maximum allowed 40% margin requirement.  (2.5x
long).  Polo doesnt actually check against the last price that the coin was traded at to see if your margin is okay, it checks against the buy orders that are on the books.  So if the last price of a trade was 900 sats, but there is no buy orders down until 850 sats, it actually looks at the 850 sats to calculate your margin.  And if that 850 sat buy order is not big enough to cover your position (your long is more BTS), then it will look down the order book further until it gets to the point where it sees how you can cover all of your position. 

The amount of BTC you could get by market selling your position onto the books is how much poloniex actually considers your position to be worth.

From what I understand of bytemasters proposed system, it works the same.



Lets say that the person with the buy wall at 850 sats in our example cancelled his order.  Now, polo recalculates how much you could sell your BTS for. Lets say that the 850 wall was a big wall and you were relying on its existence.  Without it, poloniex sees that you would have to dump all the way down to 400 sats in a liquidation!   It recalculates your margin and determines that you are below the 20% liquidation level and are no longer safe. Therefore it autoliquidates your position, and crashes the price to 400 sats.


So the removal of an order from the books on polo can trigger forced liquidations.  Bitshares would need to do the same thing.  Its necessary in order to protect lenders.


I might suggest that for robustness sake, that if this scenario occurs that what Bitshares should do is to not allow the order to be cancelled but instead to liquidate the position into it, when the person tried to cancel the order.  Essentially, when the buy wall owner submits the order to cancel to the blockchain, the blockchain responds 'oh no, if you pull that order then it will cause forced liquidations.  Therefore you cannot pull the order, and the forced liquidations are happening now instead'. 


What will happen as a result of this is that people are going to put in big buywalls, and others are goign to take margin positions in front of them, and then the buywall placers are going to pull their walls in order to get cheap (whatever theyre buying).  This happens on polo.  Its what happened when Bitshares crashed after the 2.0 release, the price would start to drop, a whale would remove a buy order, and it would trigger liquidations.

But there isnt any way to avoid this if we want to protect lenders, and imo we NEED to protect lenders.  Lending needs to be safe.  The margin traders take all the risk.  After all, everyone knows margin trading is risky.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Empirical1.2

  • Hero Member
  • *****
  • Posts: 1366
    • View Profile
The challenge is to create a bond market where lenders can earn interest while being 100% protected against default by the borrowers. This means that at all times the blockchain must be able to cover all loans on the market.

Why 100% default protection to lenders? why not mimic traditional bond markets where lenders assume risk for payment? Interest income should come from bearing risk IMO, a necessary condition for circumspection and functioning markets.

Because we want people to actually use the system and lend. 

By the way, this system appears to me to be copying Poloniex's system really well, which is a good thing.  Poloniex has been doing such lending for around a year now and hasnt yet has a single instance of screwing over the lenders and not being able to repay them, due to the robustness of their algorithm.

Bitshares copying that algorithm is what we should be aiming for.

That's good if it replicates something similar to the Poloniex system.

In Polo, it seems that if you have at least the maintenance collateral amount you're safe unless the price moves against you, in this model it seems you can be margin called based on orders moving around/being removed from the book. Is it the same on polo, if not could this put of borrowers off or not really in your opinion?
If you want to take the island burn the boats

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander

A margin call can happen for any of the following reasons:
1. If canceling an open order would result in insufficient orders on the books to buy back the debt with the collateral, then a margin call is executed first, then the order is canceled (if it wasn’t used as part of the margin call).
2. If filling an order would result in insufficient orders on the books to satisfy all debt at the SWAN PRICE, then the margin call is executed first.

This is important to protect lenders, so I think these are good ideas.


When a margin call liquidation occurs, it will often trigger a cascade, and will be very computationally intensive.  When this happens on poloniex, for example, the site freezes up for a few seconds or maybe even longer, while it executes liquidations. (The results can be crazy.  For example, recently CLAMS had a rally that went from .001 to .002 in a day, and when it broke above .002 it triggered a cascade of liquidations that took it from .002 to .003, a 50% increase, in an instant, while poloniex was frozen executing the liquidatons.



How is the bitshares blockchain going to handle to computation intensity of this algorithm, while attempting to maintain 3 second block times?  3 seconds may not be enough for a witness to calculate the required liquidation cascade and then broadcast the block.    Given the importance of what takes place in that block, it seems very important that it not result in a fork or orphaned block.  Do we have plans to handle these issues?



Finally, I'm very glad to see progress finally being made on this. :)  Thanks to everyone working on Bitshares.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
Calling this a bond market is misleading...  It doesn't have any of the charactertics of a bond.

There's no call date and no coupon.  Also the collateralization of this doesn't fit the description of a traditional bond market.

To properly do a bond market, there needs to be some sort of reputation system in place so that investors can evaluate risk.  Lending to an anonymous person you no nothing about is a non-starter.

Its the margin trading lending market. :)  And its what Bitshares needs in place in order to be able to both allow margin trading inside bitshares, and award yield to savers.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
The challenge is to create a bond market where lenders can earn interest while being 100% protected against default by the borrowers. This means that at all times the blockchain must be able to cover all loans on the market.

Why 100% default protection to lenders? why not mimic traditional bond markets where lenders assume risk for payment? Interest income should come from bearing risk IMO, a necessary condition for circumspection and functioning markets.

Because we want people to actually use the system and lend. 

By the way, this system appears to me to be copying Poloniex's system really well, which is a good thing.  Poloniex has been doing such lending for around a year now and hasnt yet has a single instance of screwing over the lenders and not being able to repay them, due to the robustness of their algorithm.

Bitshares copying that algorithm is what we should be aiming for.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

Is this SWAN price the same SWAN price that is used now?

Similar concept, but not identical.   SWAN is the price at which the least collateralized position is unable to fully cover itself with its collateral.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.