search

bitshares / bsips

BitShares Improvement Proposals and Protocols. These technical documents describe the process of updating and improving the BitShares blockchain and technical ecosystem.
https://bitshares.github.io
63 stars 86 forks source link

BSIP-70: Peer-to-Peer Leveraged Trading #189

Closed pmconrad closed 5 years ago

pmconrad commented 5 years ago

Initial PR created - we're at a point where we're abusing the issue discussion for versioning (see variant A/B), so it's about time to move this into git. This PR is based on the current OP of #170 with some fixes and clarifications, plus a means to let issuers decide which markets should be opened for lending.

froooze commented 5 years ago

I want to add some fundamental design improvements to this protocol:

MichelSantos commented 5 years ago

I want to add some fundamental design improvements to this protocol:

@froooze I appreciate the recommendations. I think that you'll find many of the recommendations are already in the specifications. I'll reply to each of your points.

The CR of a margin position can only be increased, when debt is reduced or collateral is increased.

Naturally the CR is always fluctuating with the valuation of the collateral. Therefore I presume from your recommendation that you would like to place an additional restriction on what the borrower may do with the margin trading account. I'll first describe how the current specifications constrain what the borrower may and may not do.

Current Specifications The borrower may pay back the entire debt when closing the position (which instantaneously raises the CR to infinity). The borrower may not pay back only portion of the debt under normal conditions. Paying back part of the debt while still keeping the loan open could be a variation in the future.

The borrower may not withdraw the loan asset ever while the loan is open. The borrower may withdraw the tradable asset if and only if the remaining portolio, which might consist of some loan asset and some tradable asset, keeps the the post-withdrawal CR ≥ MCR. Any withdrawal will reduce the CR. If CRbefore ≥ MCR and if CRafter ≥ MCR, it is still a reduction of the CR.

Additional Specification I presume that your recommended constraint also comes with an implied ability to partially repay the debt while keeping the loan/margin position open. Therefore a successful leveraged trader may have a portfolio increasing in valuation with an increasing CR but will never be able to withdraw his profits without first reducing some of the debt. This is a reasonable constraint. But given that there is already a restriction on withdrawals to respect the MCR, how important do you think this additional constraint is?

With a option to lock up the debt asset side by side of the margin position to increase CR, the debt must not be payed back to increase CR.

You might be pleased to learn that the current specification (a) does not permit partially paying back the debt, and (b) does not permit withdrawing the loan asset from the portfolio. So I think that this recommendation is already in the current specification.

Locking up the debt in a separated way for the margin position, no extra collateral as security is needed

This concern can be handled with two features of the current specification:

(a) the trading limit prevents the borrower from trading away all of the loan asset to ensure that the portfolio always has enough the loan asset such that

Bliquidafter ≥ K = (MCR - 1) × B0

(b) therefore a concerned lender can be sure that the portfolio always has enough loan asset to repay the lender by creating a loan offer with an MCR of 2+x (or 200+%).

Collateral is only needed for the interest rate, which is payed in front

Alternate collateral assets is certainly an interesting possibility for a future version of this proposal.

Borrower can set a time limit how long he wants to borrow the debt asset

This is already present in the specifications with

Before the time limits ends, the borrowed debt asset is reduced linear to avoid jumps in CR

I don't understand this idea. Even without this recommendation, why would there be jumps in the CR?

With this idea, what benefit is provided? Is this recommendation a form of automatic partial repayment of the debt?

Supply/Demand for the lending pool does affect the interest rate for debt asset https://medium.com/hydro-protocol/how-lending-pool-interest-rates-actually-work-375794e71716

The current specification allows every lender and borrower to come to an agreement to any fixed interest rate independent of the interest rate that other parties are supplying/demanding. There is no lending pool. All of the various participants will discover the interest rate for any pair of assets and that interest rate will vary over time.

Furthermore that interest rate will almost definitely be different for different loan durations.

Is your recommendation to have a separate leveraged trading where a central entity or a single contract is changing the loan offers depending on the demand? If that is case then I submit that people can build their own bots or hire fund managers to dynamically adapt their offers on this new order book system.

The max amount of debt which can borrowed from the lending pool depends on the amount of BTS, which are locked in the specific margin position

I must reiterate that there is no lending pool. Lenders each make their own lending offers which are placed into an offer book. Each matching of a loan is a match with another counter-offer.

Furthermore the loan asset can be any asset: BTS, bitCNY, GATEWAY.X, etc.

Is your recommendation to treat BTS as a special collateral asset that must be used as collateral? Or that can optionally be used as collateral?

Option to borrow 0-100% from the lending pool when CR < MCR

The current specification is voluntary lending between two accounts. There is no pool. The lender picks a minimum MCR. The borrower must provide a CR ≥ any compatible MCR.

By definition this is impossible.

Prioritize the margin calls for the interest rate

The current specification has two rules for automatic matching of offers. Both rules prioritize interest rate of compatible offers above all other parameters.

froooze commented 5 years ago

@MichelSantos:

  1. The actual version of the lending protocol is decoupled from the personal margin position, which limits the efficiency.
  2. My protocol can be seen as extra liquidity for margin positions.
  3. The borrower of the debt asset has no intention to trade, but to increase his CR to reach MCR.
  4. The new borrowed debt is separated locked, the margin position is not touched.
  5. Because debt is not paid back, the bitAsset can always get redeemed after a certain time.
  6. The lending pool has the advantage no agreement between borrower and lender are needed.
  7. The lending pool has a smaller slippage.

To make things more clear I start a complete write up in a separate topic, where we can discuss the details.

Inmortak commented 5 years ago

What's up guys!

I haven't read the whole thing for it's pretty long and complex. One question though, would this help to solve the current sell wall on bts/bitUSD pair?

froooze commented 5 years ago

I haven't read the whole thing for it's pretty long and complex. One question though, would this help to solve the current sell wall on bts/bitUSD pair?

The current version of this protocol does not solve the fundamental problems. My approach can reduce the margin calls by about 90%.
The trick is to borrow bitUSD from the liquidity pool to increase CR, without paying back any debt. Margin calls are only needed to cover the interest rate for the extra borrowed bitUSD.

We create a bitUSD cloud around the margin positions to increase liquidity, reduce margin calls and system risk.

dls-cipher commented 5 years ago

Price for gateway assets are determined how ? By internal market price (DEX) or through external price feeds ? Or its locked under the price/terms of p2p agreement at the moment of creating debt.

Chee®s

dls-cipher commented 5 years ago

What's up guys!

I haven't read the whole thing for it's pretty long and complex. One question though, would this help to solve the current sell wall on bts/bitUSD pair?

In my humble opinion not really. It would just moved more bitUSD to some other assets instead of providing more liquidity for the mentioned pair.

froooze commented 5 years ago

In my humble opinion not really. It would just moved more bitUSD to some other assets instead of providing more liquidity for the mentioned pair.

Yes, here is a liquidity conflict. I can only lend the debt asset once. For non-debt assets this makes sense, but for debt assets the current approach is not constructive.

froooze commented 5 years ago

I see a liquidity conflict with the margin position liquidity pool: https://github.com/bitshares/bsips/issues/182

pmconrad commented 5 years ago

@froooze @dls-cipher @inmortak I think you may be confusing this leveraged trading proposal with our existing smartcoins. There is no direct connection between the two. Neither trade asset nor debt asset need be a smartcoin. Even if one is, the other need not be its backing asset. E. g. it would be possible to lend bitUSD for trading against bitCNY, or lending BTS for trading against OPEN.BTC.

MichelSantos commented 5 years ago 
1. The actual version of the lending protocol is decoupled from the personal margin position,

This is true

which limits the efficiency.

@froooze Efficiency of what objective or process? I believe that your objective, although related, is different than this BSIP's objectives.

To make things more clear I start a complete write up in a separate topic, where we can discuss the details.

I think that your points here and the objective of your proposal in #182 are valuable and interesting but they are specifically focused on the CR of smartcoins

MichelSantos commented 5 years ago

What's up guys! I haven't read the whole thing for it's pretty long and complex. One question though, would this help to solve the current sell wall on bts/bitUSD pair?

In my humble opinion not really. It would just moved more bitUSD to some other assets instead of providing more liquidity for the mentioned pair.

@Inmortak I agree with the "not really" of @dls-cipher in the sense that the mechanism of this proposal may be used for either side of the BTS/bitUSD pair, and may be used in completely different pairs BTS, smartcoins, or UIAs. Account holders can choose how they might use this mechanism.

MichelSantos commented 5 years ago

Price for gateway assets are determined how ? By internal market price (DEX) or through external price feeds ? Or its locked under the price/terms of p2p agreement at the moment of creating debt.

@dls-cipher The price of gateway assets in a portfolio are determined from the internal market (DEX). Some more details and exceptions can be found here.

An important idea to keep in mind is that the portfolio is appraised in terms of the asset type that is lent (e.g. bitUSD or UIA or BTS etc.). The portfolio will consist of some amount of the loan asset and tradable asset

Here is one example of how a portfolio is appraised which makes use of the reference price from the DEX.

froooze commented 5 years ago

@MichelSantos

@froooze Efficiency of what objective or process? I believe that your objective, although related, is different than this BSIP's objectives.

Yes, the #189 approach is not designed to save the margin positions, but to enable lending for trading.

I think that your points here and the objective of your proposal in #182 are valuable and interesting but they are specifically focused on the CR of smartcoins

The only important thing I have now, is the prioritization of the margin position liquidity pool for debt assets, when there is demand from the margin positions. When the interest rate of the margin position liquidity pool reaches a certain level, the user can only lend the debt asset to the margin position liquidity pool.

froooze commented 5 years ago

@MichelSantos: How can BSIP-70 save the margin position? Can you provide an example?

MichelSantos commented 5 years ago

How can BSIP-70 save the margin position? Can you provide an example?

(@froooze I will presume that "saving the margin position" means to increase the CR of "bad debt" or to reduce some of the bad debt. Please tell if you intended some other meaning.)

It will not. That is not its primary objective. BSIP-70 cannot be used directly by a debt holder who has no other assets, goods, or services to help their difficult position where the collateral has lost value.

All legitimate ideas for "saving the margin position" involve a rescue by people (a) with assets, goods, or services separate from the collateral already in the margin positions ("other assets") (b) who anticipate an increase of demand for the collateral (relative to the debt asset) in the future

Without these two conditions, the bad debt will only get worse and there will be no saving of margin positions.

What a "rescuer" could do depends on her risk tolerance, and the confidence of her predictions.

BSIP-70 might help save margin positions if a rescuer has a particular forecast. For example, if a rescuer anticipates with high confidence that the collateral asset type (e.g. BTS) will increase in value in 2 years but has low confidence about its price during the 2 years, she could:

  1. Borrow bitUSD for BSIP-70 trading against BTS with a loan duration of 2.5 years
  2. After the BSIP-70 loan is created, she immediately sells her bitUSD into the margin wall to obtain BTS; this trade helps to reduce overall bad debt.
  3. If her predictions are correct she will be profitable before she needs to repay/close her loan within 2.5 years (she can always pay back earlier if she desires).
MichelSantos commented 5 years ago

@jmjatlanta Please review three clarifications about early closure

pmconrad commented 5 years ago

@MichelSantos it has always been my understanding that the minimum duration is agreed upon by both parties, and that early payback is not possible. (Payback can be initiated by the borrower while the minimum duration has passed but the maximum duration has not been reached yet.)

shulthz commented 5 years ago

What‘s the preventive method for the situation which the network halted on a block last night？

pmconrad commented 5 years ago

What‘s the preventive method for the situation which the network halted on a block last night？

Chain halts are rare and typically short in relation to loans. They need no special consideration in this context.

jmjatlanta commented 5 years ago

@MichelSantos @pmconrad Was the comment at https://github.com/bitshares/bsips/pull/189#issuecomment-528226576 resolved? I believe Peter is saying that minimum duration should not be set when the offer is created, but after negotiation between borrower and lender. The latest changes seem to indicate it is decided by the lender only.

pmconrad commented 5 years ago

Hm, somehow Michel's latest push didn't invalidate your approval, then Ryan merged it. In a PM from Michel I understood that he'd prefer to honour the minimum duration as well. We may need another PR to undo the last commit.

abitmore commented 5 years ago

somehow Michel's latest push didn't invalidate your approval

Dismiss stale pull request approvals when new commits are pushed is now enabled. It was not.

MichelSantos commented 5 years ago

@jmjatlanta Peter is correct in that my latest update made the BSIP inconsistent with regards to early repayment. I'm preparing an update to rectify. I'll make a new PR and reference this one.

froooze commented 4 years ago

@MichelSantos @pmconrad Did you consider a option to use BSIP-70 through a lending pool, instead of a order book, to improve performance and user experience?

MichelSantos commented 4 years ago

Did you consider a option to use BSIP-70 through a lending pool, instead of a order book, to improve performance and user experience?

@froooze I find that unpooled lending allows every person to decide what risk, interest, and loan duration that they are comfortable with for borrowing or lending. This is much more flexible and avoids contentious and continuous debates about the appropriate risk, interest, loan duration, and fairness when under-collateralized situations occur.

Anyone who is interested in pooled lending or pooled borrowing could use the mechanism from this BSIP and operate a "managed fund" through a single account. A pooled lending pool, for example, could work as follows:

  1. The managers create a single managed account
  2. Investors deposit funds into managed account in accordance with the terms and conditions of that fund
  3. The managers create loan offers from some of the investments in the managed account 4a. The mechanism described in the BSIP operates as described 4b. The managers must retain sufficient funds in the managed account, or add their own funds into the managed account, to cover withdrawals and interest that are described by the terms and conditions from Step 2.