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

BSIP70: Lending for Margin Trading #170

Closed MichelSantos closed 4 years ago

MichelSantos commented 5 years ago 
BSIP: 70
Title: Peer-to-Peer Leveraged Trading (Variant B)
Authors: George Harrap, Michel Santos, Peter Conrad
Status: Draft
Type: Protocol
Created: 2019-06-17
Discussion: https://github.com/bitshares/bsips/issues/170

Abstract

This BSIP defines a protocol upgrade in order to support peer-to-peer lending, borrowing and margin trading markets on the BitShares DEX. Lending is defined as any user of the BitShares DEX having the ability to post an offer to lend any BitShares asset they own to a market where a borrower may take that offer (by posting collateral) and pay the lender a lender-defined amount of interest over a time period.

The Borrower may choose to take the offer or post their preferred borrowing interest rate as a Bid and when taken, execute an exchange transaction with that token for another specified by the lender. The borrower will pay the lender interest in the asset type that was borrowed. Should the value of their margin position fall by a specified amount, the borrowers' balance will be margin called and sold on the market to payback the debt to the lender. The borrower risks losing their collateral in the case of a margin call and the lender risks the orderbook depth being insufficient to pay back their loan in the specified market.

Motivation

BitShares is the longest running decentralised cryptocurrency exchange and one of the pioneers of collateralised stablecoins. While the BitShares DEX makes it easy to trade in an environment where users have custody of their own keys, there are opportunities to be made to improve liquidity, onboard new users and affect great trading activity on the BitShares DEX.

The highest volume and most liquid exchanges in the world to date like Bitmex and Bitfinex who rose to dominance due to their usage of leverage in catalysing greater liquidity for their customers.

With this in mind, some of the key inhibitors to growth right now for the BitShares DEX include:

Incentive for Smartcoin creation / holding: The growth in liquidity of Smartcoins like bitUSD, BitCNY, BitEUR and others depends on users locking up BTS collateral to create these assets. For users engaged in creating these assets they must often manage exposure to a highly volatile collateral asset and are not paid for taking on the risk which could reduce potential new issuance.

Smartcoin Liquidity: The most liquid BitShares markets are often the smart coin markets, however the liquidity of Smartcoins in circulation on the orderbook is not yet comparable to larger teir centralised exchanges thereby reducing potential usage of the BitShares DEX.

Counterparty risk of crypto lending: Currently one of the only ways with market traction to earn passive income on cryptocurrency holdings is to trust a centralised counterparty and give up ownership of your money to another entity. This is highly risky with users no longer in control of their funds and at risk of hacking or confiscation.

BTS Price growth: The Bitshares token (BTS) is the underlying collateral required for committee issued assets and therefore a higher Bitshares price incentivises greater Smartcoin creation. Growing demand for BitShares assets promotes higher collateralisation of BTS which requires more BTS being removed from circulation which over time reduces supply and can increase positive price pressure.

The motivation behind this BSIP is to address these concerns and increase user demand, liquidity and passive income opportunities for users of the BitShares DEX.

Rationale

This BSIP seeks to address the inhibitors to growth in the BitShares DEX by introducing P2P Lending, Borrowing and Margin trading markets on the BitShares DEX. This new functionality would address the above concerns as follows:

Passive risk adjusted income: Any user may choose to lend any BitShares asset for a user defined rate of return over a specified time period. This not only provides an added incentive to hold an asset that can return a yield but also ensures existing liquidity of BitShares assets is deployed to the trading orderbook.

On-chain lending and borrowing reduces risk: Users seeking a return would not need to trust third party intermediaries with their funds and can engage in lending and borrowing contracts on the BitShares DEX. This reduces risk compared to competing centralised non-custodial competitors.

Increased DEX liquidity: With the ability for users to lend new or existing liquidity directly to the orderbooks, it provides greater order book depth than exists currently. This reduces risk for margin traders who rely on ample orderbook depth to ensure their positions can be adequately executed at a desired price or in the case of margin calls greater depth reduces collateral losses.

Long / Short any asset on the DEX: A user could borrow or lend any asset on the DEX adding new opportunities to make money from market movements especially in bear markets. This also enables smartcoin issuers to hedge their BTS (or other) exposure which could assist these users maintain adequate MCR ratios thereby reducing global settlement risk.

Added volume and usage of BTS: Every operation on the BitShares DEX requires a fee to be paid which returns BTS to the reserve pool. Greater usage of the BitShares DEX increases fees paid, reduces supply which can result in a positive price pressure on BTS. Additionally new smartcoin issuance for committee assets and some private assets requires BTS as collateral and therefore increased issuance also requires the purchase and lock up of BTS, increasing demand of BTS.

The BitShares DAC is well situated to capture a market opportunity in this space with the core intent of this BSIP to increase the viability of the BitShares DEX as a high volume, non-custodial, transparent and liquid trading exchange.

Specifications

The process flow for margin trading is depicted below. The process consists of seven stages with some stages containing parallel processes.

Process Flow

  1. Stage 1a: Prior to any loan being offered or matched, the asset issuer must authorize the loan asset for lending for margin trading against sets of tradable assets.
  2. Stage 1b: Prior to any loan being offered or matched, it must be possible to look up a valid reference price between the tradable asset and the the loan asset on the internal DEX market.
  3. Stage 2: Lenders and potential Borrowers can place offers on the Lending Order Book. The offers by lenders ("loan offers") and the offers by borrowers ("borrow offers") shall remain on the books until they either expire or are matched by counter-offers.
  4. Stage 3: Compatible offers are matched to create a loan.
  5. Stage 4a: A borrower/ may hold the borrowed asset and/or trade against the agreed-upon tradable asset for the duration of the loan. Stage 4b: The smart contract will transfer interest payments from the borrower's loan portfolio to the lender on a daily basis. Stage 4c The smart contract shall appraise the loan to check whether sufficient collateral backs the loan. Stage 4d: A borrower may update the amount of collateral in their loan.
  6. Stage 5a: A borrower may initiate a loan closure any time prior to the loan expiry. Stage 5b: The smart contract may initiate a margin call when the loan expires. Stage 5c: The smart contract may initiate a loan closure if it is unable to pay the daily interest on behalf of the borrower. Stage 5d: The smart contract may initiate a loan closure by margin call if it appraises the loan's collateral as being too low.
  7. Stage 6: During a margin call process the smart contract attempts to liquidate a loan portfolio to obtain a sufficient balance of the borrowed asset to repay the lender. This might require selling the balance of the tradable asset on the market.
  8. Stage 7a: During a loan closure, the lender is repaid what is owed and any balance of assets that remain in the loan portfolio are transferred to the borrower's regular set of balances. Stage 7b: Alternatively, if a margin call is initiated that does not complete within a certain amount of time, the entire loan portfolio shall be confiscated from the borrower and transferred to the lender as a substitute payment for what is owed.

Stage 1a: Authorized Leveraged Trading Pairs

The asset issuer of the loan asset must authorize the loan asset to be used for lending for margin trading ("leveraged trading") against a set of tradable assets. This set of authorized tradable asset may be updated by the asset issuer at any time. These restrictions shall affect the creation of new loan and borrow offers.

Stage 1b: Reference Price

Knowledge of the exchange rate between the loan asset and the tradable asset is essential for the smart contract to automatically appraise a portfolio during the loan appraissal and to evaluate the need for a possible margin call. This price shall be determined by the smart contract from data on the decentralized exchange and not from any external price feeds. The reference price shall be validated under specific rules, and prohibitions shall be imposed while the reference price is invalid.

Determination of Reference Price

The reference price for the tradable asset that is denominated in terms of the loan asset shall be updated every block that has any activity (new orders, canceled orders, and matched orders) in that market pair's trading book. The reference price of the tradable asset shall be calculated according to the following rules.

Asset Reference Price Validity of Reference Price
Tradable asset is a bitAsset that is not in global settlement The highest offer price for the tradable asset. If there are no offers, the last traded price. Valid if (a) there any offers for the tradable asset, and (b) if there has ever been any trade activity.
Tradable asset is a bitAsset that is in global settlement Global settlement price Always valid
All other assets The highest offer price for the tradable asset. If there are no offers, the last traded price. Valid if (a) there any offers for the tradable asset, and (b) if there has ever been any trade activity.

If the validity conditions are not satisfied for the asset pair, the reference price shall be considered invalid and certain activities shall be prohibited.

Prohibited Activity under Invalid Reference Price

A valid reference price permits the tradable asset components of the portfolio (Tliquid and Torders) to be appraised in terms of the loan asset. This allows the entire loan portfolio to be appraised which further allows a check of the minimum collateral requirements for an existing loan.

Therefore with a valid reference price

However an invalid reference price prevents a portfolio appraisal (except for the trivial case where the portfolio only consists of the borrowed asset components (Bliquid and Borders). Without the ability to appraise the tradable asset portion of the portfolio, collateral requirements cannot be evaluated. Therefore,

Stage 2: Offers to Lend and Borrow

Both potential lenders and potential borrowers can place offers on the Loan Order Book. Potential lenders place "loan offers" and potential borrowers place "borrow offers". Loan offers contain the following parameters:

Lending Offer Parameter Description
Asset type to lend
 The asset type that the lender is offering to lend
Minimum amount to lend
 The minimum amount of the loan asset type that will be lent into a matched loan.
Maximum amount to lend
 The maximum amount of the loan asset type that the lender is offering. This amount is deducted from the lender's balances when the offer is created.
Asset type of collateral
 The asset type that the borrower must provide as collateral. For this initial version of margin trading, this shall be the same asset type as the asset type to lend.
Maintenance collateral ratio (MCR)
 The minimum collateral ratio that the lender is expecting at the beginning of a loan. MCR ≥ MCCR ≥ 1
Margin call collateral ratio (MCCR)
 The minimum collateral ratio below which a margin call of the loan is initiated. MCR ≥ MCCR ≥ 1
Maximum duration of margin call
 The maximum duration of a margin call, if one is necessary, after which a portfolio confiscation will be triggered.
Asset type to trade against (Tradable asset)
 The asset type that the lender permits the borrower to trade against. This restriction protects the lender from exit scam trading.
Minimum duration of loan
 The minimum duration of the loan that the lender is willing to accept
Maximum duration of loan
 The maximum duration of the loan that the lender is willing to accept
Minimum interest rate
 The minimum daily interest rate that the lender is willing to accept
Expiration date Expiration date of the offer

Borrow offers contain the following parameters:

Borrowing Offer Parameter Description
Asset type to borrow
 The asset type that the borrower is seeking
Minimum amount to borrow
 The minimum amount of the loan asset type that will be borrowed into a matched loan.
Maximum amount to borrow
 The maximum amount of the loan asset type that the borrower is willing to borrow.
Asset type as collateral The asset type that the borrower must provide for collateral. For this initial version of margin trading, this shall be the same asset type as the asset type to lend.
Amount of collateral The amount of collateral the borrower has put into the offer. This amount is deducted from the borrower's balances when the offer is created.
Maintenance collateral ratio (MCR)
 The maximum collateral ratio that the borrower is willing to offer at the beginning of a loan. MCR ≥ MCCR ≥ 1
Margin call collateral ratio (MCCR)
 The maximum collateral ratio below which a margin call of the loan is initiated. MCR ≥ MCCR ≥ 1
Minimum duration of margin call protection
 The minimum duration of a margin call, if one is necessary, after which a portfolio confiscation will be triggered.
Asset type to trade against (Tradable asset)
 The asset type that the borrower can trade against.
Minimum duration of loan
 The minimum duration of the loan that the borrower is willing to accept
Maximum duration of loan
 The maximum duration of the loan that the borrower is willing to accept
Maximum interest rate
 The maximum daily interest rate that the borrower is willing to accept
Expiration date Expiration date of the offer

After an offer is created, all users shall be able to identify:

Users shall have the ability to filter offers either by type (loan offer or borrow offer), asset type to loan, tradable asset type, amounts, interest rate, loan duration, maintenance collateral ratio, and margin call collateral ratio. This capability shall either be done at the Core RPC-API node and/or at the user interface. Offers to lend and offers to borrow shall have unique identifiers which can be referenced for loan matching.

The creation of offers, their partial and complete matches, their expiration, and their closures, shall be recorded as part of the account history of the lender and the borrower.

Offers to lend and borrow shall remain on the Loan Order Book until they either are canceled by the offeror, expire, or are completely matched and filled.

Stage 3: Loan Offer Matching

New offers shall be automatically compared to existing counter-offers on the book. This matchmaking investigation shall:

  1. identify compatible offers
  2. match compatible offers
  3. create a loan from the matched offers

Compatibility Filtering

This matchmaking process shall only match a loan offer (L) with a borrow offer (B) if those offers have the following compatible conditions.

Offer Parameter Compatibility Conditions
Loan amount (P) LPmin ≤ BPmax and BPmin ≤ LPmax
Loan duration (D) LDmin ≤ BDmax and BDmin ≤ LDmax
Interest rate (I) LI ≤ BI
Minimum collateral ratio (MCR) LMCR ≤ BMCR
Margin call collateral ratio (MCCR) LMCCR ≤ BMCCR
Margin call duration (MCD) BMCD ≤ LMCD

Therefore when a new loan offer or borrow offer is received, it shall be checked against the existing offers. This new offer will become the "taker" to the existing "maker" offers. The outcome of this investigation may identify multiple "maker" offers to be compatible with the new "taker" offer.

If no compatible offers are found for the new offer, the new offer shall be added to the offer order book and retained until it is canceled, expires, or is completely matched and filled.

Offer Matching

When multiple loan offers (L) are found to be compatible with multiple borrow offers (B), they shall be prioritized in a deterministic manner to identify which of the compatible offers will be matched to each other.

As the definition of most offer parameters are not exact values (e.g. a lender might offer a loan for exactly 6 months) but are rather bounded values (e.g. a lender might offer a loan for a duration between 3 months and 12 months), and the compatibility conditions permit a range of overlap between a loan offer and a borrow offer, there may mathematically be an infinite number of loan definitions that could be created from even a single loan offer and borrow offer. (Technically the number of loan offers are finite because they will only be characterized by finite-precision integer parameters.) Matches shall be made to favor the existing offers on the loan offer books (the "makers").

If the new offer (the "taker") is a borrow offer, the compatible loan offers shall be sorted in favor of the lenders (the "makers"). These compatible offers shall be sorted in favor of the lender offers as described in the following table.

Loan Parameter Loan Parameter Selection Loan Parameter Value Prioritization Order
Interest rate (I) Highest compatible interest rate BI 1
Loan duration (D) Longest compatible loan duration min(LDmax, BDmax) 2
Loan amount (P) Largest compatible amount min(LPmax, BPmax) 3
Margin call collateral ratio (MCCR) Highest compatible MCCR BMCCR 4
Minimum collateral ratio (MCR) Highest compatible MCR BMCR 5
Margin call duration (MCD) Shortest MCD BMCD 6

If the new offer (the "taker") is a loan offer, the compatible offers shall be sorted in favor of the borrowers (the "makers"). These compatible offers shall be prioritized favor of the borrower offers as described in the following table.

Loan Parameter Loan Parameter Selection Loan Parameter Value Prioritization Order
Interest rate (I) Lowest compatible interest rate LI 1
Loan amount (P) Largest compatible amount min(LPmax, BPmax) 2
Loan duration (D) Longest compatible loan duration min(LDmax, BDmax) 3
Margin call collateral ratio (MCCR) Lowest compatible MCCR LMCCR 4
Minimum collateral ratio (MCR) Lowest compatible MCR LMCR 5
Margin call duration (MCD) Longest MCD LMCD 6

The highest prioritized maker offer shall be paired to the new offer and a new loan shall be created in accordance with the loan parameter values in the corresponding table.

Loan Creation

The matching of a loan offer with a borrow offer shall result in the creation of a loan.

This new loan portfolio shall receive the loan amount (P) from the lending offer and an amount of collateral asset (K) from the borrowing offer equal to

K = (MCR - 1) × P

A loan shall be created from a single lending offer and a single borrowing offer.

This loan portfolio shall then become available for margin trading by the borrower.

Effective Dates of the Loan

The start date of the loan shall be when the loan is matched. The end date of the loan shall be calculated by adding the loan duration to the start date. The loan may be closed:

Filling of Loan Offer

The matching of a loan offer with a borrow offer will result in one or both of the offers being completely consumed. If an offer is not completely filled, the offer shall be "partially filled" by having the loan amount (P) deducted from the offer's "available balance".

Effects of Partial Fills on a Loan Offer

The reduction to a loan offer reduces the amount that has been offered by the prospective lender.

(BPmax)new = (BPmax)old - P

If this remainder exceeds the loan offer's minimum amount (BPmin), the loan offer shall be retained on the offer books. Otherwise the offer shall be cancelled by the smart contract.

Effects of Partial Fills on a Borrow Offer

The reduction to a borrow offer reduces the amount of collateral (K) that is being offered by the prospective borrower.

Knew = Kold - P

This effectively reduces the maximum loan amount of the borrow offer.

(LPmax)new = Knew ÷ (MCR - 1) = (Kold - P) ÷ (MCR - 1)

If this remainder exceeds the borrow offer's minimum amount (LPmin), the loan offer shall be retained on the offer books. Otherwise the offer shall be cancelled by the smart contract.

Re-evaluation of a New Offer

If the partially-filled offer is retained and if the partially filled offer is the new offer, it shall be re-evaluated for loan matching against the remaining counter-offers.

Stage 4a: Margin Trading within Loan Portfolio

Assets that are borrowed shall be placed into the borrower's margin trading "loan portfolio". This portfolio shall only be used for trading on the decentralized exchange in the market pair consisting of the "Asset type to lend/borrow" and the "Asset type to trade against". It shall not be possible to transfer funds to any account, nor use any of the assets as collateral to create another pegged asset on BitShares.

Any assets obtained from trading shall by placed into the loan portfolio and shall also be restricted to trading between the pair of asset types defined in the loan agreement. Conditional withdrawals of the tradable asset by the borrower shall be permitted. Deposit of the lent asset by the borrower shall also be permitted.

Trading Limits

A borrower shall be able to use the borrowed asset type in the loan portfolio to trade against the tradable asset on the order book of the market pair. The amount of the borrowed asset type (B) that may be used for placing new orders shall be limited to ensure that the loan portfolio's balance of the borrowed asset exceeds the minimum collateral (K). Before a trade the liquid balance of the asset type is Bliquidbefore. The liquid balance of the asset type after a new order (Btradenew) can be calculated as

Bliquidafter = Bliquidbefore - Btradenew

The new liquid balance must satisfy the following condition and definition for collateral

Bliquidafter ≥ K = (MCR - 1) × B0

which can be re-arranged as

Btradenew ≤ Bliquidbefore - (MCR - 1) × B0

This expresses a maximum amount for any new limit orders where the borrowed asset is offered to trade. If this amount is negative, no new trades shall be permitted.

Multiple Loan Portfolios

A borrower may have multiple outstanding loans each with their own distinct loan portfolio. Trading of assets from each loan portfolio shall be independent of other loan portfolios that are controlled by the borrower. Trade orders shall only draw from assets within a single loan portfolio.

The distinction of loan portfolios from each other are intended to segregate the risk of each loan which can have separate loan durations, margin collateral ratios, and tradable assets. This segregation should better secure the lenders than a single co-mingled loan portfolio.

User interfaces that facilitate trading for a borrower may optionally aggregate multiple loan portfolios into a single "margin trading wallet" to disguise the fact that multiple loan portfolios are being tracked.

Stage 4b: Daily Interest Payment

The daily interest due (Idaily) on the prinicipal (B0) shall be calculated as

Idaily = B0 × Rdaily

where Rdaily is daily interest rate. This daily interest shall be calculated in terms of the lent asset type.

The daily interest that is due shall be deducted from the borrower's balance of the borrowed asset type in the loan portfolio and deposited into the lender's account. If the borrower's loan portfolio holds insufficient balance of the lent asset type to pay the daily interest then a margin call shall be initiated.

When a loan is closed the interest for that last day shall be paid at that time. If a margin call requires multiple days to complete in accordance with the agreed duration of the margin call's loan, no additional interest shall be owed by the lender beyond payment for the last day of interest.

Stage 4c: Appraisal of Loan Portfolio

Debt Owed

The debt owed by a borrower for a particular loan is the amount lent by the lender. Interest is due on a daily basis.

Portfolio Appraisal

A borrower may have many outstanding loans which are owed to different borrowers. Each loan portfolio will initially consist of the principal that is lent by the lender plus the initial collateral that is provided by the borrower. The borrowed asset and the collateral asset shall initially be the same asset type (B).

After the loan is initiated, the borrower may use that asset type to trade against the tradable asset type (T) that is permitted by the loan, and/or may hold the borrowed asset. Therefore this loan-related portfolio may consist of balances of two asset types: the borrowed asset type, and the tradable asset type.

PA = B + T

Portfolio Components

While a loan is outstanding the balance of the borrowed asset and tradable asset may consist as either liquid balances in the loan portfolio or as open orders on the order book. Therefore the entire loan portfolio may be decomposed into four parts:

PA = Bliquid + Tliquid + Borders + Tliquid

The valuation of the portfolio shall also be denominated in terms of the borrowed asset type for purposes of appraisal by the smart contract. The valuation of the borrower's loan-related portfolio shall consist of the valuation of the two assets in the portfolio at the time of interest.

Example of Portfolio Appraisal

Bob borrowed 70 bitUSD 203.3 days ago while supplying by supplying 30.03 bitUSD as collateral. Bob has been margin trading with this loan portfolio against bitBTC and currently has a balance of 45 bitUSD and 0.025 bitBTC. The current reference price indicates that bitBTC is priced at 5000 bitUSD per bitBTC. This loan portfolio will be appraised (PA) at:

PA = (45 bitUSD) + (0.025 bitBTC × 5000 bitUSD ÷ bitBTC)

... = (45 bitUSD) + (125 bitUSD)

... = 170 bitUSD

Collateral Ratio

After the calculation of a portfolio appraisal (PA) and the debt owed (B0), the collateral ratio (CR) shall be calculated as

CR = PA ÷ B0

At the beginning of the loan, the collateral ratio will satisfy the following conditions.

CR ≥ MCR ≥ MCCR ≥ 1

Derived Valuations

The maintenance collateral valuation (MCV) of the loan portfolio is denominated in the borrowed asset and equals

MCV = MCR × B0

where B0 is the debt owed.

Similarly, the margin call collateral valuation (MCCV) of the loan portfolio is denominated in the lent asset and equals

MCCV = MCCR × B0

It is desired for the appraised valuation of the portfolio (PA) to be greater than or equal this value

PA ≥ MCV ≥ MCCV ≥ B0

but it is possible for this valuation to fall below the MCV. If

PA < MCCV

a margin call shall be initiated.

Triggering of Appraisal

Portfolio appraisals shall be triggered at multiple times. A portfolio appraisal shall be triggered:

Stage 4d: Loan Portfolio Updates

Status of Loan Portfolio

The "recent" appraisal value, debt owed, collateral ratio, and derived valuations, and of the portfolio shall be able to be queried by the lender and borrower at any time.

Deposits

A borrower shall be able to deposit additional amounts of the borrowed asset into the loan portfolio. A borrower may choose to deposit additional collateral to avoid having the loan be margin called.

Withdrawals

A borrower shall be able to withdraw only the tradable asset as long as the market valuation of the portfolio (PA) after the withdrawal is greater than or equal to the maintenance collateral valuation. The withdrawal limit (Wlimit) is defined as

Wlimit = PA - MCV

where MCV is maintenance collateral valuation and PA is portfolio appraisal.

Example of Withdrawal

Bob borrowed 70 bitUSD 203 days ago at a daily interest rate of 0.0261% while supplying by supplying 30.03 bitUSD as collateral to satisfy the offer's 142.9% maintainance collateral ratio.

The debt owed is still 70 bitUSD. The maintenance collateral valuation (MCV) of the portfolio is

MCV = MCR × B0

... = 1.429 × 73.8276 bitUSD

... = 105.4996 bitUSD

During this time Bob has been margin trading with this loan portfolio against bitBTC and currently has a balance of 45 bitUSD and 0.025 bitBTC. The current reference price indicate that bitBTC is priced at 5000 bitUSD per bitBTC. This loan portfolio will be appraised at:

PA = (45 bitUSD) + (0.025 bitBTC × 5000 bitUSD ÷ bitBTC)

... = (45 bitUSD) + (125 bitUSD)

... = 170 bitUSD

The borrower may withdraw up to the equivalent (Wlimit) of

Wlimit = PA - MCV

... = 170 bitUSD equivalent - 105.4996 bitUSD equivalent

... = 64.5004 bitUSD equivalent

The withdrawal limit denominated in bitBTC is

Wlimit = (64.5004 bitUSD ÷ (5000 bitUSD ÷ bitBTC))

... = 0.01291 bitBTC

Bob may withdraw bitBTC up to this limit because the balance of bitBTC, 0.025, exceeds this amount. If the balance of the tradable asset were, for example, only 0.1 bitBTC then Bob would only be able to withdraw 0.1 bitBTC.

Stage 5a: Initiation of Loan Closure by Borrower

A borrower may close an outstanding loan position by having a sufficient balance of the borrowed asset type in the loan portfolio and then initiating a loan closure with the appropriate parameters.

Initiation of Loan Closure Parameter Description
Lending Offer ID Identifier of an existing and open loan offer

The initiation of a loan closure shall close any and all open trade orders that are related to this loan. If the balance of the borrowed asset type is insufficient to repay what is owed then the initiation of the loan closure shall be rejected. It is the responsibility of the borrower to ensure a sufficient balance in the borrowed asset type to repay the loan.

Stage 5b: Expiration of Loan

The smart contract shall initiate a margin call if an outstanding loan expires.

A future BSIP may consider opening a new loan from any existing offers on the Loan Order Book.

Stage 5c: Initiation of Loan Closure because of Insufficient Funds

A loan portfolio may categorized as consisting of four components of balances of which one is the balance of borrowed asset that is liquid (Bliquid). This balance is drawn from to pay the daily interest. If this balance is insufficient to pay the interest then a loan closure shall be initiated.

Stage 5d: Initiation of Loan Closure by Margin Call

If the collateral ratio ever drops below the margin call collateral ratio,

CR < MCCR

the smart contract shall initiate a margin call.

Stage 6: Margin Call

Restriction of Loan Portfolio

When a margin call is initiated on a specific loan portfolio, no new market orders may be initiated that make use of any balance in the loan portfolio. Any other loan portfolios that the borrower might have shall not be affected by margin calls on other loans.

Any open market orders that are related to that specific loan portfolio shall be cancelled.

After all open orders are cancelled, the portfolio will consist of some amount in the borrowed asset type and some amount in the tradable asset type.

PA = Bliquid + Tliquid

Liquidation Plan

The smart contract shall determine whether the balance of the borrowed asset (Bliquid) is sufficient to pay the necessary balance (Bclosure). The difference between the two is the excess borrowed asset (Bexcess)

Bexcess = Bliquid - Bclosure

If the balance is sufficient (Bexcess > 0), the process shall transition to a conventional loan closure.

If the balance is insufficient (Bexcess < 0), the smart contract shall create a limit order that offers the entire balance of the tradable asset (T) while asking for the difference between what is owed and the liquid balance(-Bexcess). This limit order shall have a limited lifetime defined by the maximum margin call duration that was agreed to in the original loan terms.

If the margin call's limit order is filled, then by definition of the limit order there shall be sufficient balance of the borrowed asset type to transition to a conventional loan closure.

Portfolio Confiscation

If the margin call's limit order expires without being completely filled, a portfolio confiscation shall be automatically initiated to permit the prompt completion of the margin call. The smart contract shall confiscate the entire loan portfolio from the borrower for ultimate transfer to the lender.

Monitoring of Liquidation Plan

It shall be possible to monitor the status of the liquidation plan associated with any margin call. An inquiry into the status of the liquidation plan shall return:

Stage 7a: Conventional Loan Closure

A standard loan closure is possible if and only if the loan portfolio's balance of the borrowed asset type (Bliquid) is sufficient to repay the principal plus interest for the last day of the loan.

Bclosure = B0 + Idaily

If that condition is satisfied, a standard loan closure can be:

Any balances that remain in the loan portfolio after repaying the lender shall be transferred to the borrower's regular set of balances and shall no longer be encumbered by any restrictions.

A future BSIP may consider re-lending a lenders balance by automatically creating a new offer on the Loan Order Book on behalf of the lender.

The loan shall be closed.

Stage 7b: Unconventional Loan Closure

If a margin call's liquidation plan expires without obtaining a sufficient balance of the borrowed asset to repay the lender, the confiscated loan portfolio shall be transferred to the lender as a substitute payment for the debt.

The loan shall be closed.

Definable Loan Constraints

The BitShares Committee shall be able to define parameters that can constrain new loans; changes to these values shall not affect loans that were offered before the change:

Term Description
Maximum loan durations The maximum duration for a new loan offer
Minimum MCR The minimum maintenance collateral ratio (MCR) that may be agreed upon
Minimum MCCR The minimum margin call collateral ratio (MCCR) that may be agreed upon
Maximum interest rates The maximum interest rate that may be agreed upon
Maximum duration of margin call
 The duration during which a borrower's loan portfolio shall be protected from confiscation.

Fees

Fees shall be defined for each of the operations:

The standard fee for canceling a trade order shall apply.

Voting Stake

Voting stake shall be calculated per account as before this proposal and with the following additions to account for any core tokens (BTS) that are associated with lending.

Software Specifications

Note 1: Interest is paid every 24 hours, regardless of local calendar. E. g. Daylight Savings Time is ignored.

Note 2: Percentage-based calculations (interest, CR) are always rounded up to the next possible value (aka "satoshi").

Note 3: MCR and MCCR are expressed in the same way as in the existing price feed logic, i. e. only the part above 100%, and as a scaled percentage value. E. g. a value of 4200 would mean 142%.

Note 4: "Implementation hints" are not to be considered part of the formal specification, but merely as a possible implementation.

Database Objects

lending_offer_object (new)

Fields:

Implementation hints:

borrowing_offer_object (new)

Fields:

Implementation hints:

loan_portfolio_object (new)

Fields:

Implementation hints:

Chain parameters

The chain_parameters (configurable by committee) will receive a new extension field margin_lending with these members:

This extension must not be present in proposals before the hardfork time.

Miscellaneous

Implementation hints:

Operations

All new operations have a simple flat fee. New operations must not be allowed before the hardfork time, neither in proposals nor directly. New fees must not be allowed in chain parameter update proposals before the hardfork.

lending_offer_create_operation (new)

Fields:

Validation checks:

Evaluation:

borrowing_offer_create_operation (new)

Fields:

Validation checks:

Evaluation:

lending_cancel_operation (new)

This operation can be used to cancel lending and borrowing offers.

Fields:

Validation checks:

Evaluation:

lending_accepted_operation (new, virtual)

Fields:

loan_interest_operation (new, virtual)

Fields:

loan_closed_operation (new, virtual)

Fields:

loan_close_operation (new)

Fields:

Validation checks:

Evaluation:

loan_update_operation (new)

Fields:

Validation checks:

Evaluation:

Loan trading

Note: trading from a loan portfolio happens on the same markets as trading from an account. Trading is therefore not implemented separately, but through modifications to the existing trade mechanisms.

Fields:

The existing limit_order_create_operation and fill_order_operation receive one optional extension field:

The loan field is not allowed before the hardfork time, neither directly nor in proposals.

Validation checks:

If the loan extension is present in a limit_order_create_operation, the following checks replace the existing checks against the seller's account balance:

Evaluation:

Database API Calls

The following methods will be added to the database_api:

All result lists are ordered by ascending object id. Server-side limits are configurable.

Processing Logic Changes

Automatic Matching of Offers

Similar to database::apply_order(). Triggered when a new offer is evaluated.

Margin calls

Notes:

Interest payments

Similar to database::clear_expired_proposals, in each block

Expire open offers

Similar to database::clear_expired_orders, in each block

Expire open loans

Similar to database::clear_expired_orders, in each block

Handle margin calls

In each block, for each loan that is in margin call state,

Confiscate expired margin calls

Similar to database::clear_expired_orders, in each block

Vote tallying

Calculate reference price

Portfolio appraisal

Changes to cli_wallet

The following commands will be added to cli_wallet:

Discussion

Risks

Financial: Price of a market pair on the DEX

A stagnant, nascent, or illiquid order book on the DEX for a particular market pair might not reflect the valuation of the collateral according to external market pairs. That will affect the appraisal value of the loan collateral which then affects margin calculations. Margin calculations affect both future loan offers on the books and matched loans.

Potential lenders and borrowers should carefully review any internal market pair and compare it with the external market pair to determine (a) whether internal market reflects a reasonable exchange ratio/price, and (b) whether the internal market could be easily manipulated to either overvalue or undervalue collateral.

Financial: Margin Calls at Market Price

If a margin call is initiated and if a liquidation plan requires selling the tradable asset to repay the lender in lent asset type, borrowers should be aware that it will be sold as an effective market order. The resulting sale on the DEX order book may return much less than if the offer were made on an external market.

Financial: Repayment of a Margin Called Loan

Loans that are margin called might require a liquidation plan that involves placing an limit order to buy enough of the lent asset to repay the loan.

If the market order remains unfilled on the DEX order book in excess of maximum margin call duration, the borrower's entire loan portfolio shall be confiscated thereby leaving the borrower with nothing after the loan closure.

Financial: Avalanche effect of Margin Calls

A margin call on a loan portfolio will immediately try to buy large amounts of the borrowed asset from the market. This can lead to a sudden spike in the trade price. This in turn can affect the reference price, which could lead to additional margin calls in other portfolios.

Powers of Asset Issuers

Asset issuers have extensive control over how their asset is used on BitShares including the ability to whitelist the trading of an asset against other assets), to restrict the transfers of an asset, and to seize any issued asset from an account if the asset is defined with the appropriate flags. These interaction of these powers with lending for margin trading are described.

Market Restrictions

The power to whitelist and blacklist trading pairs for an issuer's asset, which has the appropriate flags enabled, shall be unaffected by this proposal. This lending proposal makes use of the existing trading mechanisms therefore all rules shall continue to apply.

For example, if an issuer's asset is blacklisted from trading against any other asset, no trading of the Asset will be possible either from an account's regular set of balances or from their loan portfolio.

Alternatively, an issuer's asset (X) might initially be whitelisted to trade against any other asset, which permits the creation of a loan portfolio to trade against another asset (Y). Trading by the borrower ensues and the borrower obtains some quantity of Asset Y in their portfolio. If the asset issuer then blacklists trading between X and Y, the borrower shall no longer be able to trade the asset from anywhere including their loan portfolio. Another effect will be that margin calls shall no longer be able to be liquidated by means of buying back the borrowed asset on the DEX. Consequently if a margin call is initiated after a blacklisting and the loan portfolio's balance of the borrowed asset was insufficient to repay the lender, the margin call shall eventually result in an unconventional loan closure.

Transfer Restrictions

The existing power to restrict the direct transfer of an issuer's asset, which has the appropriate flags enabled, from one account to another shall be unaffected by this proposal.

Interest payment involves the transfer of the [borrowed asset-type](#borrow-asset] from the borrower to the lender. Therefore the creation of loan and borrow offers, and the matching of offers shall only be permitted if (a) if the borrow asset is not transfer restricted, and (b) if both the lender and the borrower are whitelisted or are not blacklisted for the borrow asset.

An unconventional loan closure transfers all balances of the borrow asset type and the tradable asset type to the lender. Therefore the creation of loan and borrow offers, and the matching of offers shall only be permitted if (a) if the tradable asset is not transfer restricted, and (b) both the lender and the borrower are whitelisted or are not blacklisted for the tradable asset.

Asset Seizure

The power to seize an issuer's asset, which has the appropriate flags enabled, shall remain possible if the asset is held in the account's regular set of balances. This power does not currently extend to assets held in open orders. Similarly, it shall not be possible to seize an asset that is held inside of a loan offer, borrow offer, or loan portfolio. An asset issuer may instead first impose a transfer restriction on the account, and then wait for the loan to be closed with appropriate balances being distributed to the regular balances of the borrower and lender at which time the conventional asset seizure may be invoked.

Summary for Shareholders

This BSIP defines a protocol upgrade to support peer-to-peer lending, borrowing and margin trading markets on the BitShares DEX. The motivation behind this BSIP is to increase the user demand for smartcoins on BitShares by offering on-chain peer-to-peer lending and borrowing to augment the existing trading. The multiple stage process between borrowers and lenders is supported with software specifications and a discussion of risks to lenders, borrowers, and asset holders, and asset issuers.

Copyright

This document is placed in the public domain.

See Also

ryanRfox commented 5 years ago

Original post by @MichelSantos in the paragraphs below. I inserted the draft BSIP text above so we may continue discussion in the comments section of this Issue before advancing it as a PR.

A working draft of a "Lending for Margin Trading" BSIP is [above]. We are seeking feedback about financial concepts from potential users and software concepts from developers. Certain aspects that still need to be determined are labeled with "TBD" (for "to be determined").

This BSIP variant has selectively restricted the features that are anticipated to be useful for users of the blockchain while still being something that might be deployed within an earlier consensus release. More advanced features are labeled with "future BSIP" and are expected to augment this feature set. Developers who might implement this feature set might make design decisions that are future-compatible with these potential features.

liondani commented 5 years ago

5plus

pmconrad commented 5 years ago
  1. IMO the restriction on a single trading pair is not sufficient to prevent an exit scam.

For example, someone who has an open call order on CNY with a CR of 1.6 may borrow CNY at a lower CR and sell the borrowed CNY to himself in order to free up his locked collateral. He has then offloaded part of the risk from his call order to the lender. (Arguably on conditions that the lender has accepted, so calling this a scam is debatable.)

Much worse than that is the fact that even the most liquid markets are operating with a spread, and that spread can become significant (i. e. > 1%) for a short period of time. A spread allows the borrower to round-trip trade with himself, transferring value out of the loan portfolio. Many such roundtrips can be squeezed into a single transaction, so even with a tiny spread a significant amount of value can be siphoned off per block.

  1. I think the reference price should be determined not only by looking at past trades, but also depending on the current state of the order book. The order book is what matters when a loan portfolio is margin called. Such a margin call executes only against one side of the order book, and a large loan can have significant effect on the market when margin called, meaning that past trades are not a good measure for the appraisal of the loan portfolio.

  2. The suggested method for margin calls, which is effectively a market order to sell everything, is dangerous. Its effect is comparable to a stop-loss order, which is known to be dangerous if publicly known in advance.

I have more detailed remarks, but I will wait for the PR.

CryptoKong commented 5 years ago

This is probably one of the best upgrades BitShares could get, really hope we can make this happen.

ryanRfox commented 5 years ago

@pmconrad and other reviewers: My desire is to see sufficient discussion/refactoring of the draft BSIP text in this Issue prior to making the PR from the outcome thereof. @MichelSantos as the author will moderate this discussion and incorporate changes. The Description text should be the most recent and used as the initial PR when deemed complete and ready for posting.

Mugendian commented 5 years ago

This needs to pass. Agree with kong, all hands on deck to make this happen.

matle85 commented 5 years ago

Great stuff - hits so many of our trouble spots!

Quite a few of the CEXs have insurance funds they build up through fees - would we do something similar?

The layman in me wants to know how close would this bring us to a BitMEX 50x 100x etc trading platform type functionality? My understanding is this will mainly get us the bones of the functionality - I'd be keen to see the UI stuff bundled in or a separate worker put forward for a really clean BitMEX type interface for it that everyone coming in will just see and know how to use.

bitcrab commented 5 years ago

haven't gone through all the details, but I believe this is what Bitshares need, let's move it forward.

matle85 commented 5 years ago

Just thinking about businesses building atop this - can we make sure we include some facility / approach to them making money?

For example, apart from the margin trading this will also make us a peer to peer decentralised lending platform... There needs to a mechanism in place allowing a business that decides to leverage this to make a profit (i.e. justify investing in the interface, publicity, business costs etc).

This is also a consideration for the trading - how does a company launching and promoting BitDEX make its money?

I guess it needs to be through the fee structure or allowing some third party to take a % mark up on values by facilitating...?

CryptoKong commented 5 years ago 
1. IMO the restriction on a single trading pair is not sufficient to prevent an exit scam.

For example, someone who has an open call order on CNY with a CR of 1.6 may borrow CNY at a lower CR and sell the borrowed CNY to himself in order to free up his locked collateral. He has then offloaded part of the risk from his call order to the lender. (Arguably on conditions that the lender has accepted, so calling this a scam is debatable.)

Would it be possible to create a new order type, so borrowed funds can only be used to open a position that has to be closed, rather than just selling borrowed funds and them being added to users balance where they can do whatever they want with it. Perhaps it could be part of the borrowing function, so when a user borrows funds they also have to input their desired position, eg: long/short, position size, collateral, margin ratio. The borrowed funds would then be put straight into an open position and once closed, whether by choice of forced, borrowed funds are repaid.

matle85 commented 5 years ago

I don't see any issue with them doing what they like with it to be honest - what they are doing in that example is reducing their risk of having their smartcoin margin position forcibly closed by agreeing to pay interest on a loan. The person lending should be aware of the risks around loaning and set their rates to suit.

Best to leave it to the market to find the acceptable rates during different market conditions - i.e. during a bear market if loads of people want to borrow to try and protect their position then people with large stacks to lend can get really good returns (noting those really good returns are in part because of the market risk!)

pmconrad commented 5 years ago

My desire is to see sufficient discussion/refactoring of the draft BSIP text in this Issue prior to making the PR from the outcome thereof.

Agree that concept and mechanics should be agreed upon before the PR. PR is better for in-detail discussion of the text, e. g. typos, wording etc. .

MichelSantos commented 5 years ago

Quite a few of the CEXs have insurance funds they build up through fees - would we do something similar?

The the operations for creating and matching loan positions would be new so they would have their own distinct fees. Because of the new computational and memory load that loan positions would impose on block producer nodes, these fees should be enough to at least compensate the block producers.

Whether the loan fees should be even higher to build an insurance fund is interesting. No risk is being taken on by the blockchain with this proposed lending loan because the main risk is being taken on by the lenders. But if the idea is to use fees from loans to pay for insuring some other activity on the blockchain, that could technically be done. However the real-world issue is do you want to have one activity's users insure another activity's users?

If that idea is desirable I think that two things need to be identified:

MichelSantos commented 5 years ago

The layman in me wants to know how close would this bring us to a BitMEX 50x 100x etc trading platform type functionality? My understanding is this will mainly get us the bones of the functionality - I'd be keen to see the UI stuff bundled in or a separate worker put forward for a really clean BitMEX type interface for it that everyone coming in will just see and know how to use.

I agree that we should discuss with at least the reference wallet team if for no other reason than this: there will potentially be numerous small loans in their own loan portfolio as this BSIP is currently conceived. This is done to better protect the lenders by uniquely tracking collateral ratios for each loan.

But the consequence is that there will potentially be numerous loans held by borrower, and also by lenders. Each loan portfolio will be traded separately from the others at the discretion of the borrower. This probably needs to be simplified and consolidated for regular users by default. We need to identify useful API calls for client software that will make handling the numerous loan portfolios/margin wallets that are held by a borrower to be fast, efficient, and not cumbersome.

But the next consequence is that it may increase the memory requirements on API nodes.

MichelSantos commented 5 years ago

Just thinking about businesses building atop this - can we make sure we include some facility / approach to them making money?

For example, apart from the margin trading this will also make us a peer to peer decentralised lending platform... There needs to a mechanism in place allowing a business that decides to leverage this to make a profit (i.e. justify investing in the interface, publicity, business costs etc).

I think that this largely depends on the imagination of the business. Businesses like individuals can use the platform now. If we had something more concrete we could evaluate what might need to be baked into the blockchain that isn't already there.

MichelSantos commented 5 years ago

Would it be possible to create a new order type, so borrowed funds can only be used to open a position that has to be closed, rather than just selling borrowed funds and them being added to users balance where they can do whatever they want with it. Perhaps it could be part of the borrowing function, so when a user borrows funds they also have to input their desired position, eg: long/short, position size, collateral, margin ratio. The borrowed funds would then be put straight into an open position and once closed, whether by choice of forced, borrowed funds are repaid.

Let's take an example: a Borrower is lent 70 bitUSD (the lent asset) to trade against bitBTC (the tradeable asset). The Borrower is limited in the following ways:

The point is that the Borrower cannot short with any funds that are inside of the "margin wallet". Does this address your main concern? Is this too limiting for the use cases that you had in mind?

The idea of lending that instantly creates a limit order against the tradeable asset is a technical possibility but I wonder if it might be too restrictive.

christophersanborn commented 5 years ago

Minor: Assuming typo in section 4b, formula for daily interest rate. (Ddaily should not exceed principle P.)

christophersanborn commented 5 years ago

This seems like a great idea and the mechanism is extremely well articulated.

froooze commented 5 years ago
  1. I am against a restriction, what the lender can do with the asset, because he pays interest and potential use cases are too much limited.
  2. The UI needs to show metrics from past borrows, to allow the market a fair risk management. If the borrower has no track record, he has to pay higher interest rates.
  3. Interest rates are calculated in percentage of borrowed bitAsset, but should be paid in BTS?
christophersanborn commented 5 years ago
  • I am against a restriction, what the lender can do with the asset, because he pays interest and potential use cases are too much limited.

A restricted use case though is what makes this whole thing work. Without the restriction, the lender would need the ability to assess the credit-worthiness of individual borrowers, and then this becomes a much more complicated endeavor. As it stands, a "loan ask" can be taken up by any borrower precisely because the usage of the principle is narrowly defined. The lender can set the interest rate based on the risk profile of the activity, NOT the risk profile of the borrower.

froooze commented 5 years ago

@christophersanborn: The intention was to have a MCR of under 1? We should not exclude the case for risk profile of the borrower, because we need only to increase MCR and Interest rate, for this case.

MichelSantos commented 5 years ago

@christophersanborn: The intention was to have a MCR of under 1?

@froooze the intention is to have MCR ≥ 1

We should not exclude the case for risk profile of the borrower, because we need only to increase MCR and Interest rate, for this case.

The lender and the borrower can agree to any MCR ≥ 1, and any interest rate

The data about each borrower will be on blockchain. If that is very important then the client interface can show the credit history of the borrower while a lender is reviewing "borrow offers" from lender.

Remember that this proposal matches loans in a three step-process.

  1. A makes an offer to borrow or lend
  2. B reviews offers
  3. If B agrees to offer and can satisfy the initial collateral requirements in that offer, then B can accept the offer and the loan offer is matched

If borrower posts a "borrow offer", potential lenders can review credit history of borrower, and choose whether to accept the offer. If lender posts a "lend offer", then any borrower who is willing to agree to the lender's terms can select it.

More conservative lenders may prefer to select "borrow offers" instead of posting "lend offers".

MichelSantos commented 5 years ago 
1. I am against a restriction, what the lender can do with the asset, because he pays interest and potential use cases are too much limited.

This proposal is limited to lending for margin trading purposes. To use borrowed assets for another purpose will require a different BSIP.

2. The UI needs to show metrics from past borrows, to allow the market a fair risk management.
   If the borrower has no track record, he has to pay higher interest rates.

This is possible for the case when borrowers make the initial "borrow offer" because past borrow history is on blockchain. It will be helpful to estimate how much is the demand by lenders to show this data in the UI.

3. Interest rates are calculated in percentage of borrowed bitAsset, but should be paid in BTS?

Payment of principal and interest must be paid in the original asset type that was borrowed.

CryptoKong commented 5 years ago

Let's take an example: a Borrower is lent 70 bitUSD (the lent asset) to trade against bitBTC (the tradeable asset). The Borrower is limited in the following ways:

* the Borrower can hold the bitUSD in the "margin wallet"

* the Borrower can optionally trade back and forth against bitBTC but all balances are contained within that specific "margin wallet"

* the Borrower can [only withdraw any "excess" bitBTC](https://github.com/bitshares/bsips/issues/170#withdrawals) (excess is that amount of bitBTC that ensures enough collateral to satisfy the minimum collateral ratio that is agreed with the lender) from the "margin wallet" into his/her regular balances

The point is that the Borrower cannot short with any funds that are inside of the "margin wallet". Does this address your main concern? Is this too limiting for the use cases that you had in mind?

The idea of lending that instantly creates a limit order against the tradeable asset is a technical possibility but I wonder if it might be too restrictive.

This adresses my concern and sounds like a much better idea, it offers control and more freedom. I like it.

froooze commented 5 years ago

This proposal is limited to lending for margin trading purposes. To use borrowed assets for another purpose will require a different BSIP.

Why do we need a different BSIP? Would be this BSIP not the same, except the market limitation? If a borrower has less limitations, the market will price in the extra risk.
It makes sense to have some limitations available, but should not forced on everyone.

pmconrad commented 5 years ago

@froooze the use-case in this BSIP is extremely limited because it allows the chain to use the complete loan portfolio, including the borrowed funds as well as any gains from trading, as collateral for the loan. This in turn is what makes margin trading possible at all.

If we allow the user to transfer value out of the loan portfolio, the chain has no means to ensure that the loan will be paid back. Note that a CEX has means of going after the borrower off-chain, and thus has a different risk profile than a smart contract between more or less anonymous participants.

cloud-8 commented 5 years ago

The borrower must be restricted otherwise they can exploit it fairly easily by taking loans and extracting money or pumping other coins the lender didnt specify in order for them to exit scam. A restriction is how every other implementation of margin trade / lending works too so this is normal. Have seen from great feedback so far.

Has the core team any major concerns on a technical level for this implementation?

pmconrad commented 5 years ago

Has the core team any major concerns on a technical level for this implementation?

The details are not sufficiently spec'd out to answer that at this time.

I believe that in order to prevent exit scams, the load portfolio must be appraised for every operation instead of just once per maintenance interval. This could have a significant impact on performance.

cloud-8 commented 5 years ago

The details are not sufficiently spec'd out to answer that at this time.

Thanks, what needs more specification ?

I believe that in order to prevent exit scams, the load portfolio must be appraised for every operation instead of just once per maintenance interval. This could have a significant impact on performance.

That seems excessive. It is up to the lender to specify the markets they enable the borrower to margin trade on, they take on the risk. If the Borrower uses the loan for buying illiquid coins and exiting a position they hold outside of this contract then that is a risk the lender must evaluate- doesnt need any intervention outside of that.

MichelSantos commented 5 years ago

If we allow the user to transfer value out of the loan portfolio, the chain has no means to ensure that the loan will be paid back. Note that a CEX has means of going after the borrower off-chain, and thus has a different risk profile than a smart contract between more or less anonymous participants.

@pmconrad I agree that this would be ideal. In fact, one could argue that it even needs to be evaluated even more frequently to quickly act on collateral ratios that are below MCCR.

Alternatively, if loan portfolios will not be appraised every block in a deterministic manner, we have a UX problem where what the borrower and lender view for the loan appraisal inside of their client interface (which influences margin calls, withdrawal limits, and trading limits) might differ from what the blockchain is acting on. In other words, if the portfolios are only appraised once every 24 hours, but the user is calculating the loan in between or the reference wallet is calculating it in between, then the users may be upset unless it is very clear when the appraisals will be performed. Even then, we might consider logging in a virtual operation the price of the loan portfolio that was appraised by the blockchain.

MichelSantos commented 5 years ago

The details are not sufficiently spec'd out to answer that at this time.

Thanks, what needs more specification ?

@cloud-8: pmconrad mentioned what I also think is a computationally expensive task that may occur relatively frequently for BitShares standards: appraising the loan portfolio. This must be done to determine withdrawal limits, trading limits, calculate collateral ratios, and to properly execute loan closures.

Other specifications that are pending are listed at https://github.com/bitshares/bsips/issues/170#software-specs

I believe that in order to prevent exit scams, the load portfolio must be appraised for every operation instead of just once per maintenance interval. This could have a significant impact on performance.

That seems excessive. It is up to the lender to specify the markets they enable the borrower to margin trade on, they take on the risk. If the Borrower uses the loan for buying illiquid coins and exiting a position they hold outside of this contract then that is a risk the lender must evaluate- doesnt need any intervention outside of that.

It might be that a periodic appraisal is a practical implementation however this appraisal schedule should be clearly known both before the loan is initiated and while the loan is open.

MichelSantos commented 5 years ago

Much worse than that is the fact that even the most liquid markets are operating with a spread, and that spread can become significant (i. e. > 1%) for a short period of time. A spread allows the borrower to round-trip trade with himself, transferring value out of the loan portfolio. Many such roundtrips can be squeezed into a single transaction, so even with a tiny spread a significant amount of value can be siphoned off per block.

@pmconrad Assuming for the moment that the reference price is "valid", I think that this scenario is prevented by the conditional withdrawal limits and conditional trading limits.

Let's consider an example where:

As I understand your scenario, the following would be attempted.

  1. Borrower trades Bliquid for Tliquid but is limited by the restriction on new trades by Btradenew. Let this first trade value equal B1. Because of the aforementioned spread the value of T1 is worth less than B1 when measured in B.

  2. Borrower withdraws as much Tliquid as is permitted by the withdraw limit (Wlimit which ensure that the PA ≥ MCP at the time of the withdrawal). Let this first withdraw amount be defined as T1W where T1W ≤ T1 because of the withdraw limit.

  3. Borrower uses T1W in his regular balances to go back on the market and trade back into B2 at the reverse spread thus losing more value.

  4. Borrower deposits B2 from his regular balances into the loan portfolio.

  5. Return to Step 1

This repetition appears to me to be a financial loss for the Borrower because of losses due to loan fees, losses due to trading fees, and losses due to two trades on a market with spreads during one cycle. The two limits appear to protect the Lender's equity by limiting a Borrower's ability to perform new trades and withdrawals.

But returning to the assumption that the reference price is "valid". Can this cyclical process alone affect that reference price over a single block? I don't currently see how it be more than any regular trading.

MichelSantos commented 5 years ago
  1. I think the reference price should be determined not only by looking at past trades, but also depending on the current state of the order book. The order book is what matters when a loan portfolio is margin called. Such a margin call executes only against one side of the order book, and a large loan can have significant effect on the market when margin called, meaning that past trades are not a good measure for the appraisal of the loan portfolio.

@pmconrad I share your concern but it's not clear to me that alternatives are better. One alternative might be to use external feeds but then we get into the debate about what is a true price and what is an acceptable "adjustment" of the price feed.

pmconrad commented 5 years ago

Let's consider an example

Initially, Bliquid = K + P, Tliquid = 0. Btrade = Bliquid - K = P. Suppose the market price is R and the spread is S, i. e. there are orders on the book at R±S. Borrower has sufficient Tsock in his other wallet or sockpuppet account.

  1. Borrower sells Btrade at price (R-S) to his sockpuppet account. Borrower now has Bliquid' = K and Tliquid' = Btrade*(R-S), Sockpuppet has Bsock' = Btrade and Tsock' = Tsock - Tliquid'.
  2. Sockpuppet sells an amount of B at price (R+S) back to borrower. Borrower pays Tliquid' and receives Tliquid' / (R+S) in B. Borrower now has Tliquid'' = 0 and Bliquid'' = K + Btrade (R-S)/(R+S), i. e. Btrade'' = Btrade (R-S)/(R+S).
  3. Rinse, repeat.

In one such cycle, an amount of Btrade (1 - (R-S)/(R+S)) = Btrade 2 S / (R+S) is transferred from borrower to sockpuppet. This is profitable as long as that amount is worth more than (4 limit_order_create_fee + 2 market_feeT + 2 market_feeB).

Problem 1: Multiple such cycles can be packed into a single block, so it is possible to drain the loan portfolio far below MCR very quickly, which damages the lender.

Problem 2: If the total transferred value minus fees can be made greater than K, borrower can make a profit from ripping off the lender. The only limiting factors here are the spread in relation to the market price, and the fees. Fees are typically far below the spread, which makes the attack highly likely.

use external feeds but then we get into the debate about what is a true price and what is an acceptable "adjustment" of the price feed.

We should avoid that at all costs. :-)

MichelSantos commented 5 years ago

Let's consider an example

Initially, Bliquid = K + P, Tliquid = 0. Btrade = Bliquid - K = P. Problem 1: Multiple such cycles can be packed into a single block, so it is possible to drain the loan portfolio far below MCR very quickly, which damages the lender.

Problem 2: If the total transferred value minus fees can be made greater than K, borrower can make a profit from ripping off the lender. The only limiting factors here are the spread in relation to the market price, and the fees. Fees are typically far below the spread, which makes the attack highly likely.

@pmconrad Thank you for the detailed steps.

This scenario can happen but the loan portfolio's CR will remain above MCCR. If it reaches MCCR a margin call will be initiated.

The trading mechanism as currently described does permit the borrower to trade when the collateral ratio of the loan portfolio (CR) trades anywhere above MCCR subject to the minimum Bliquid. The loan agreement stipulates that MCCR be close to or far from MCR.

Do you recommend that the difference between the MCCR and MCR be limited such that K is enough to cover that gap? Or should the lender and the borrower be permitted to agree to other terms?

pmconrad commented 5 years ago

This scenario can happen but the loan portfolio's CR will remain above MCCR.

Yes, if appraisal happens before each single trade instead of just once per day.

MichelSantos commented 5 years ago

This scenario can happen but the loan portfolio's CR will remain above MCCR.

Yes, if appraisal happens before each single trade instead of just once per day.

@pmconrad The triggering of loan appraisals and the fees section has been updated to reflect your recommendation.

pmconrad commented 5 years ago

If the balance is insufficient, the smart contract shall place an "effective" market order of the entire balance of the tradeable asset. The effective market order shall be performed by creating a limit order asking for one satoshi of the borrowed asset type in exchange for the entire balance of the tradeable asset.

Like I said, the "effective market order" is dangerous. Possible alternatives:

MichelSantos commented 5 years ago

Like I said, the "effective market order" is dangerous. Possible alternatives:

  • place an order with min_to_receive = outstanding debt (or percentage thereof)

  • return collateral to lender directly and let him handle it manually

  • let the lender specify one of these options in the loan offer

@pmconrad These recommendations are better than what was written because they do not assume a liquid market and can therefore better protect the value of the loan portfolio from plummeting which protects the lender, and because they reduce the order's influence on that market pair's order book.

This does leave open the possibility that the margin call may not be filled and remain on the order books. Therefore, we are making use of the limit order's expiration such that it that is a term of the loan. If the margin call's limit order expires, a loan confiscation will be automatically triggered to repay the lender. For contrast the prior version of the text only had loan confiscation as an optional action.

We have also clarified that a margin call will only sell off the tradeable asset if and only if the balance of the borrowed asset type is insufficient to pay back what is owed which is the principal plus the last day of interest.

bitcrab commented 5 years ago 
1. I am against a restriction, what the lender can do with the asset, because he pays interest and potential use cases are too much limited.

This proposal is limited to lending for margin trading purposes. To use borrowed assets for another purpose will require a different BSIP.

I don't see the necessity for this restriction, with restriction the feature should be named "leverage trading", not "lending margin call", why not do a general "lending margin call" feature without restriction on how the borrower will use the borrowed assets? I feel this has much bigger market demand.

CryptoKong commented 5 years ago 
1. I am against a restriction, what the lender can do with the asset, because he pays interest and potential use cases are too much limited.

This proposal is limited to lending for margin trading purposes. To use borrowed assets for another purpose will require a different BSIP.

I don't see the necessity for this restriction, with restriction the feature should be named "leverage trading", not "lending margin call", why not do a general "lending margin call" feature without restriction on how the borrower will use the borrowed assets? I feel this has much bigger market demand.

The two types of lending should absolutely be separated in my opinion, I am not against a lending system where the borrower can do as they please but it should be separate from margin trading loans.

We should not create a generalised lending system with the intention of it being used in the markets for leveraged trading (although they could), the markets should have their own systems with restrictions.

A lending system without restrictions will inevitably have higher rates as there will be more risk for the lender, separating the systems removes that risk from the markets with restrictions and lowers the lending rates.

Having separate systems would also perhaps help users price their loans as they could look at restricted loans and see they should price there generalised loans more expensive.

Either way, margin trading loans should be restricted.

MichelSantos commented 5 years ago 
1. I am against a restriction, what the lender can do with the asset, because he pays interest and potential use cases are too much limited.

This proposal is limited to lending for margin trading purposes. To use borrowed assets for another purpose will require a different BSIP.

I don't see the necessity for this restriction, with restriction the feature should be named "leverage trading", not "lending margin call", why not do a general "lending margin call" feature without restriction on how the borrower will use the borrowed assets? I feel this has much bigger market demand.

@bitcrab Having lending without restrictions or different restrictions is certainly an option. And I agree that it is even a larger market. However I think that it should be a separate BSIP for two reasons.

The first reason is that lending without restriction is a type of lending with different risks for the lender, and with different risks for the stability of smart assets.

The second reason is for practicality. Several features of "lending for margin trading" have already been removed such that what remains is a minimum viable product that can be used on BitShares as soon as possible. The more advanced features, which appear in draft text with the words "future BSIP", may be proposed for implementation in the future.

If "leveraged trading" is more intuitive to users then I have no objection. The current label of "lending for margin trading" is intended to distinguish itself from alternative lending mechanisms that have different restrictions and use cases like the one that you and @froooze are advocating. Multiple lending mechanisms can co-exist on BitShares.

MichelSantos commented 5 years ago

Having separate systems would also perhaps help users price their loans as they could look at restricted loans and see they should price there generalised loans more expensive.

@CryptoKong I think that it will be fascinating to see how different interest rates appear under different lending mechanisms. Even within a single lending mechanism like the one described here, I expect to see a variety of interest rates and durations between different pairs of assets, and even different "directions" such as borrowing BTC to trade against USD versus borrowing USD to trade against BTC.

manikey123 commented 5 years ago

Following peer to peer lending issue occurred for Poloniex. How do u plan to handle such situation for dramatic price crash observed in CLAM token ? https://medium.com/circle-trader/overview-of-btc-margin-lending-pool-losses-a2f0905aaa56 @MichelSantos

pmconrad commented 5 years ago

@manikey123 see Stage 6 - Margin Calls.

A price crash in collateral can lead to some loan positions being margin called, and if market liquidity is insufficient some loan portfolios may be confiscated and returned to the lender. It is possible that the lender suffers a monetary loss from this procedure. By offering the loan, the lender accepts that risk, and he can choose the terms of loan to offset this risk.

Note that other than Poloniex, each loan portfolio stands for itself. The loss of one loan position is not covered by all other open loans.

pmconrad commented 5 years ago

While working on the specification section I have run into the following questions:

  1. IMO the "Reference Price" is not just an implementation detail, it is absolutely crucial for the success of this mechanism. I feel I'm lacking the financial background to come up with a reasonable suggestion. Please discuss here.

  2. Please add a section to "Discussion" where asset flags and black/whitelists are considered. E. g. an "override_transfer" cannot be applied to funds inside a loan portfolio.

  3. Please add a section to "Discussion" where the consequences for voting of core asset in loan portfolios are discussed. (IMO it is clear the core in lending offers and borrowing offers should vote for the owner of the offer. For core in loans it is not clear, and perhaps should be different of the portfolio is margin called.)

pmconrad commented 5 years ago

Please consider rewording certain uses of "price". A price is a ratio of two denominations. E. g. "Maintenance collateral price" is not a price but rather a valuation expressed as an amount of one asset.

Special cases for reference price:

The liquidation plan should include settlement if the tradable asset is in global settlement. If the tradable asset is an MPA and has a valid feed price at the time of confiscation, should the lender receive only enough of it (in terms of feed price and settlement offset) to cover the missing debt?

pmconrad commented 5 years ago

Here's one for the "Risks" section:

Financial: Avalanche effect of Margin Calls

A margin call on a loan portfolio will immediately try to buy large amounts of the borrowed asset from the market. This can lead to a sudden spike in the trade price. This in turn can affect the reference price, which could lead to additional margin calls in other portfolios.

pmconrad commented 5 years ago

Below is my current draft version of the "Specification" section.

I have slightly expanded on the operation definitions in the OP. E. g. the offers contain min and max amount, and the acceptor can choose how big the loan will be. I have also specified that an offer stays if it partially accepted and the remaining part exceeds the min value.

I'm unsure whether it would be easier to replace the explicit accept operation with an offer matching algorithm. Probably yes - leaving it out doesn't save us very much in terms of complexity whereas adding it later will require a new and slightly more complicated BSIP.

Lending for Margin Trading

Specification

Note 1: Interest is paid every 24 hours, regardless of local calendar. E. g. Daylight Savings Time is ignored.

Note 2: Percentage-based calculations (interest, CR) are always rounded up to the next possible value (aka "satoshi").

Note 3: MCR and MCCR are expressed in the same way as in the existing price feed logic, i. e. only the part above 100%, and as a scaled percentage value. E. g. a value of 4200 would mean 142%.

Note 4: "Implementation hints" are not to be considered part of the formal specification, but merely as a possible implementation.

Database Objects

lending_offer_object (new)

Fields:

Implementation hints:

borrowing_offer_object (new)

Fields:

Implementation hints:

loan_portfolio_object (new)

Fields:

Implementation hints:

Chain parameters

The chain_parameters (configurable by committee) will receive a new extension field margin_lending with these members:

This extension must not be present in proposals before the hardfork time.

Miscellaneous

Implementation hints:

Operations

All new operations have a simple flat fee. New operations must not be allowed before the hardfork time, neither in proposals nor directly. New fees must not be allowed in chain parameter update proposals before the hardfork.

lending_offer_create_operation (new)

Fields:

Validation checks:

Evaluation:

borrowing_offer_create_operation (new)

Fields:

Validation checks:

Evaluation:

lending_cancel_operation (new)

Fields:

Validation checks:

Evaluation:

lending_accepted_operation (new, virtual)

Fields:

lending_accept_operation (new)

Fields:

Validation checks:

Evaluation:

loan_interest_operation (new, virtual)

Fields:

loan_closed_operation (new, virtual)

Fields:

loan_close_operation (new)

Fields:

Validation checks:

Evaluation:

loan_update_operation (new)

Fields:

Validation checks:

Evaluation:

Loan trading

Note: trading from a loan portfolio happens on the same markets as trading from an account. Trading is therefore not implemented separately, but through modifications to the existing trade mechanisms.

Fields:

The existing limit_order_create_operation and fill_order_operation receive one optional extension field:

The loan field is not allowed before the hardfork time, neither directly nor in proposals.

Validation checks:

If the loan extension is present in a limit_order_create_operation, the following checks replace the existing checks against the seller's account balance:

Evaluation:

Database API Calls

The following methods will be added to the database_api:

All result lists are ordered by ascending object id. Server-side limits are configurable.

Processing Logic Changes

Margin calls

Notes:

Interest payments

Similar to database::clear_expired_proposals, in each block

Expire open offers

Similar to database::clear_expired_orders, in each block

Expire open loans

Similar to database::clear_expired_orders, in each block

Handle margin calls

In each block, for each loan that is in margin call state,

Confiscate expired margin calls

Similar to database::clear_expired_orders, in each block

Vote tallying

Calculate reference price

Portfolio appraisal

Changes to cli_wallet

The following commands will be added to cli_wallet:

cloud-8 commented 5 years ago

Please consider rewording certain uses of "price". A price is a ratio of two denominations. E. g. "Maintenance collateral price" is not a price but rather a valuation expressed as an amount of one asset.

Special cases for reference price:

  • If the tradable asset is a bitasset in global settlement, use the settlement price as the reference price
  • If the tradable asset is an MPA and has a valid feed price, use the feed price (minus settlement offset) as the reference price)

The liquidation plan should include settlement if the tradable asset is in global settlement. If the tradable asset is an MPA and has a valid feed price at the time of confiscation, should the lender receive only enough of it (in terms of feed price and settlement offset) to cover the missing debt?

Regarding your last point on confiscation, yes in the case of a margin call of the borrower:

1: is an order with amount to fill is placed on the DEX at the margin price, in the case where that doesnt fill every order in the entire orderbook and does meet the amount required to payback the loan then everything is fine.

  1. In the case it take every order in the orderbook and still has remaining amount to be filled, then an order is place in the orderbook at that price. This order has an expiration (adjustable via committee IMO).

  2. After expiration period, the outstanding tokens should be confiscated from the borrower and returned to the lender. This is an acceptable risk for the lender as it is known this can happen at creation. I would say the lender only receive enough of it to fulfil the order.

Regarding what the 'Price' is yes this is something to consider. In the case of an MPA, the collateral is often BTS, however if lending is taking place involving a UIA or a smartcoin that doesnt have BTS as collateral then using the pricefeed as a reference is not possible. In the case of Bitfinex and others, the price comes from the last price on the exchange. I think the only issue that some may have with this is in illiquid markets it can open things up for exploitation and negative feedback loops fairly easily. Therefore a dampening affect should be in force in cases where there is a drastic drop in prices, perhaps a an average of last price over a period of X blocks would provide a safer mechanism?