-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BSIP-70: Peer-to-Peer Leveraged Trading #189
Conversation
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.
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 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
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.
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+%).
Alternate collateral assets is certainly an interesting possibility for a future version of this proposal.
This is already present in the specifications with
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?
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.
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?
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.
The current specification has two rules for automatic matching of offers. Both rules prioritize interest rate of compatible offers above all other parameters. |
To make things more clear I start a complete write up in a separate topic, where we can discuss the details. |
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? |
The current version of this protocol does not solve the fundamental problems. We create a bitUSD cloud around the margin positions to increase liquidity, reduce margin calls and system risk. |
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 |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 clarification requested and 1 possible typo.
I see a liquidity conflict with the margin position liquidity pool: |
@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. |
This is true
@froooze Efficiency of what objective or process? I believe that your objective, although related, is different than this BSIP's objectives.
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 |
@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. |
@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. |
Yes, the #189 approach is not designed to save the margin positions, but to enable lending for trading.
The only important thing I have now, is the prioritization of the |
@MichelSantos: |
(@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 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:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this proposal is complete.
@jmjatlanta Please review three clarifications about early closure |
@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.) |
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. |
@MichelSantos @pmconrad Was the comment at #189 (comment) 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. |
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. |
|
@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. |
@MichelSantos |
@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:
|
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.