Lending for Margin Trading (Variant B) #184
Comments
|
This variant replaces the explicit matching of offers by account holders in Variant A with automatic matching. This variant also includes a draft of the software specs for automatic matching. |
The smart contract should also have an option to pay the interest in BTS (default?) and not in the borrowed asset. |
These variants are premised on the lender loaning in one asset, and getting paid back in that asset. If the loan asset happens to be BTS then the loan and interest will be paid back in BTS. In principle, the idea of paying interest in BTS could be possible but it introduces the complexity of potentially a third asset (1. loanable asset, 2. tradable asset, and 3. BTS) which the smart contract must also track and appraise to possibly trigger margin calls. We want to avoid that complexity in this initial version. |
Mathematically the number may be infinite, but technically we're dealing with a set of limited-precision integral values, which results in less than infinite possibilities. :-) I wonder about the order of selection criteria - will people be interested in a longer running loan or in a bigger loan? The differences to variant A in the technical spec look good to me. |
Those are helpful catches, Peter. I have updated the graphic and text for this Variant. The Overlap function is indeed simpler in your proposed form.
You're correct. I added "technical" footnote :)
You're probably correct that borrower/traders will prefer longer-running loans to minimize the number of portfolios that they need to manage. I adjusted the sort order for when borrower are makers.
My minor concern with this change is whether it might prove to be more work to the few people who will be attempting to verify how offers are matched: but such verifiers needed to keep separate set of rules anyway so I don't think that this difference will be an excessive complication for them. Another minor counter-argument towards keeping them the same is that the prospective lenders and borrowers can always limit what is matched by their selection of offer parameters. Those who are concerned about the automatic matching may always select loan amounts and durations to be narrowly defined.
I think that because the lenders want to earn as much interest as possible, and because they cannot intervene after a loan is matched, that longer duration are more preferable than are loan amounts.
Thanks for the review |
|
I don't see the use case to borrow BTS, when I have to maintain the collateral and pay the interest rate? Can not the BTS I borrowed and the assets I bought, be seen as a collateral? |
Of course, anyone can choose to lend in whichever asset they prefer
If you choose to borrow BTS then the BTS balance and the tradable asset balance both compose the dynamically calculated portfolio valuation. |
|
I encourage future discussions to be held in the original issue (#170) which is hosting Variant B |
|
Closing this in order to keep the discussion focused in #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.
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.
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.
The process flow for margin trading is depicted below. The process consists of seven stages with some stages containing parallel processes.
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.
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.
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.
If the validity conditions are not satisfied for the asset pair, the reference price shall be considered invalid and certain activities shall be prohibited.
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,
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:
Borrow offers contain the following parameters:
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.
New offers shall be automatically compared to existing counter-offers on the book. This matchmaking investigation shall:
This matchmaking process shall only match a loan offer (L) with a borrow offer (B) if those offers have the following compatible conditions.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
The debt owed by a borrower for a particular loan is the amount lent by the lender. Interest is due on a daily basis.
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
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
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
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.
Portfolio appraisals shall be triggered at multiple times. A portfolio appraisal shall be triggered:
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.
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.
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.
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.
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.
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.
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.
If the collateral ratio ever drops below the margin call collateral ratio,
CR < MCCR
the smart contract shall initiate a 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
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.
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:
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.
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.
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:
Fees shall be defined for each of the operations:
The standard fee for canceling a trade order shall apply.
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.
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
4200would mean142%.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:
lending_offer_id_type id- The object IDaccount_id_type owner- The lending account IDasset_id_type loan_asset- The asset type that the lender is offering to lendshare_type min_amount- The minimum amount of the asset type that the borrower must borrowshare_type max_amount- The maximum amount of the asset type that the lender is offeringunsigned_int mcr- The minimum collateral ratio that the lender is expecting at the beginning of a loan, as a scaled percentageunsigned_int mccr- The collateral ratio below which a margin call of the loan is initiated, as a scaled percentageunsigned_int max_call_duration- The maximum duration of a margin call in seconds, if one is necessary, after which a portfolio confiscation will be triggeredasset_id_type tradable_asset- The asset type that the lender permits the borrower to trade againstunsigned_int min_duration- The minimum duration of the loan that the lender is willing to accept, in daysunsigned_int max_duration- The maximum duration of the loan that the lender is willing to accept, in daysunsigned_int min_interest_rate- The minimum daily interest rate that the lender is willing to accept, as a scaled percentagetime_point_sec expiration- Expiration date of the offerextension_type ext- reserved for future extensionsImplementation hints:
by_owner,by_asset,by_expirationborrowing_offer_object(new)Fields:
borrowing_offer_id_type id- The object IDaccount_id_type owner- The borrowing account IDasset_id_type loan_asset- The asset type that the borrower is offering to borrowshare_type min_amount- The minimum amount of the asset type that the lender must lendshare_type max_amount- The maximum amount of the asset type that the borrower wants to borrowshare_type available_collateral- The amount of collateral the borrower has put into the offerunsigned_int mcr- The maximum collateral ratio that the borrower is willing to provide at the beginning of the loan, as a scaled percentageunsigned_int mccr- The maximum collateral ratio the borrower will accept, below which a margin call of the loan is initiated, as a scaled percentageunsigned_int min_call_duration- The minimum duration of a margin call in seconds, if one is necessary, after which a portfolio confiscation will be triggeredasset_id_type tradable_asset- The asset type that the borrower wants to trade againstunsigned_int min_duration- The minimum duration of the loan that the borrower is willing to accept, in daysunsigned_int max_duration- The maximum duration of the loan that the borrower is willing to accept, in daysunsigned_int max_interest_rate- The maximum daily interest rate that the borrower is willing to accept, as a scaled percentagetime_point_sec expiration- Expiration date of the offerextension_type ext- reserved for future extensionsImplementation hints:
by_owner,by_asset,by_expirationloan_portfolio_object(new)Fields:
account_id_type owner- The borrowing account IDaccount_id_type lender- The lending account IDasset_id_type principal_asset- The ID of the borrowed assetshare_type principal_borrowed- The amount that was originally borrowedshare_type minimum_collateral- The minimum amount of collateral that must be maintainedshare_type principal_balance- The amount of the borrowed asset currently held in the portfolioshare_type principal_in_orders- The amount of the borrowed asset currently held in market ordersasset_id_type trade_asset- The ID of the asset that can be traded againstshare_type trade_balance- The amount of the tradable asset currently held in the portfolioshare_type trade_in_orders- The amount of the tradable asset currently held in market ordersshare_type mccv- The portfolio value below which a margin call of the loan is initiated, in terms ofprincipal_assetunsigned_int call_duration- The duration of a margin call in seconds, if one is necessary, after which a portfolio confiscation will be triggeredoptional<time_point_sec> confiscation_time- After a margin call has been initiated, this contains the time when the portfolio will be confiscatedshare_type daily_interest- The daily interest amount to be paidtime_point_sec interest_due_at- Date at which the next interest payment is dueshare_type cumulative_interest- The cumulative interest paid for this loan so fartime_point_sec earliest_end- Date after which the portfolio can be closed by the borrowertime_point_sec latest_end- Date after which the portfolio will be closed automaticallyoptional<price> call_price- If present, contains the price (in terms of principal/trade) below which the portfolio is margin calledImplementation hints:
by_owner,by_lender,by_interest_due,by_expiration(i. e.latest_end)Chain parameters
The
chain_parameters(configurable by committee) will receive a new extension fieldmargin_lendingwith these members:unsigned_int max_duration- maximum allowed loan duration in daysunsigned_int minimum_mcr- minimum allowed mcr for loans, as a scaled percentageunsigned_int minimum_mccr- minimum allowed mccr for loans, as a scaled percentageunsigned_int max_interest- maximum allowed daily interest rate, as a scaled percentageunsigned_int max_call_duration- maximum allowed call duration in secondsThis extension must not be present in proposals before the hardfork time.
Miscellaneous
limit_order_objectreceives a new fieldoptional<loan_portfolio_id_type> loanImplementation hints:
limit_order_objectfor trackingby_loanOperations
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:
account_id_type lender- The lending account IDasset_id_type asset_to_lend- The asset type that the lender is offering to lendshare_type min_to_lend- The minimum amount of the asset type that the borrower must borrowshare_type max_to_lend- The maximum amount of the asset type that the lender is offeringunsigned_int mcr- The minimum collateral ratio that the lender is expecting at the beginning of a loan, as a scaled percentageunsigned_int mccr- The collateral ratio below which a margin call of the loan is initiated, as a scaled percentageunsigned_int max_call_duration- The maximum duration of a margin call in seconds, if one is necessary, after which a portfolio confiscation will be triggeredasset_id_type tradable_asset- The asset type that the lender permits the borrower to trade againstunsigned_int min_duration- The minimum duration of the loan that the lender is willing to accept, in daysunsigned_int max_duration- The maximum duration of the loan that the lender is willing to accept, in daysunsigned_int min_interest_rate- The minimum daily interest rate that the lender is willing to accept, as a scaled percentagetime_point_sec expiration- Expiration date of the offerextension_type ext- reserved for future extensionsValidation checks:
lendermust be a valid account ID, must exist, must authorize the operation, must pay feeasset_to_lendandtradable_assetmust be valid asset IDs, must not be equal, and both assets must existmin_to_lend > 0max_to_lend >= min_to_lendmcr >= mccrmax_duration >= min_durationexpiration > head_block_timemin_duration <= chain_parameters.max_durationmcr >= chain_parameters.min_mcrmccr >= chain_parameters.min_mccrmin_interest_rate <= chain_parameters.max_interest_ratemax_call_duration <= chain_parameters.max_call_durationlendermust have at leastmax_to_lendofasset_to_lendin his balanceasset_to_lendmust be authorized for margin lending againsttradable_assetasset_to_lendand thetradable_assetmust not be transfer restrictedlendermust be whitelisted or must not be blacklisted for theasset_to_lendand thetradable_assetdue to transfer restrictionsEvaluation:
max_to_lendofasset_to_lendfromlenderbalancelending_offer_objectand populate object fields from operation fieldsborrowing_offer_create_operation(new)Fields:
account_id_type borrower- The borrowing account IDasset_id_type asset_to_borrow- The asset type that the borrower is offering to borrowshare_type min_to_borrow- The minimum amount of the asset type that the lender must lendshare_type max_to_borrow- The maximum amount of the asset type that the borrower wants to borrowunsigned_int mcr- The maximum collateral ratio that the borrower is willing to provide at the beginning of the loan, as a scaled percentageunsigned_int mccr- The maximum collateral ratio the borrower will accept, below which a margin call of the loan is initiated, as a scaled percentageunsigned_int min_call_duration- The minimum duration of a margin call in seconds, if one is necessary, after which a portfolio confiscation will be triggeredasset_id_type tradable_asset- The asset type that the borrower wants to trade againstunsigned_int min_duration- The minimum duration of the loan that the borrower is willing to accept, in daysunsigned_int max_duration- The maximum duration of the loan that the borrower is willing to accept, in daysunsigned_int max_interest_rate- The maximum daily interest rate that the borrower is willing to accept, as a scaled percentagetime_point_sec expiration- Expiration date of the offerextension_type ext- reserved for future extensionsValidation checks:
borrowermust be a valid account ID, must exist, must authorize the operation, must pay feeasset_to_borrowandtradable_assetmust be valid asset IDs, must not be equal, and both assets must existmin_to_borrow > 0max_to_borrow >= min_to_borrowmcr >= mccrmax_duration >= min_durationexpiration > head_block_timemin_duration <= chain_parameters.max_durationmcr >= chain_parameters.min_mcrmccr >= chain_parameters.min_mccrmin_interest_rate <= chain_parameters.max_interest_ratemin_call_duration <= chain_parameters.max_call_durationborrowermust have at leastmax_to_borrow * mcrofasset_to_borrowin his balanceasset_to_borrowmust be authorized for margin lending againsttradable_assetasset_to_borrowand thetradable_assetmust not be transfer restrictedborrowermust be whitelisted or must not be blacklisted for theasset_to_lendand thetradable_assetdue to transfer restrictionsEvaluation:
max_to_borrow * mcrofasset_to_borrowfromborrowerbalanceborrowing_offer_objectand populate object fields from operation fieldslending_cancel_operation(new)This operation can be used to cancel lending and borrowing offers.
Fields:
account_id_type owner- Creator of the operation (fee paying account), must equal owner of the offeroffer_id_type offer- Either alending_offer_id_typeor aborrowing_offer_id_typeextension_type ext- reserved for future extensionsValidation checks:
ownermust be a valid account ID, must exist, must authorize the operation, must pay feeoffermust be a valid lending offer ID or borrowing offer ID and must existoffer.owner == ownerEvaluation:
offeris a lending offer:offer.max_amountofoffer.loan_assettoownerbalanceofferis a borrowing offer:offer.available_collateralofoffer.loan_assettoownerbalanceofferfrom databaseownerlending_accepted_operation(new, virtual)Fields:
account_id_type offerer- must equal owner of the offeroffer_id_type offer- id of the accepted offer,lending_offer_id_typeor aborrowing_offer_id_typeloan_portfolio_id_type loan- id of the resulting loan portfolioloan_interest_operation(new, virtual)Fields:
account_id_type lender- the lender's account idaccount_id_type borrower- the borrower's account idloan_id_type loan- ID of the loan portfolio to adjustasset interest_amount- Amount of interest paid toloan.lenderloan_closed_operation(new, virtual)Fields:
account_id_type lender- the lender's account idaccount_id_type borrower- the borrower's account idloan_id_type loan- ID of the loan portfolio to adjustasset principal_paid_back- Amount of principal paid back to lenderasset trade_confiscated- Amount of trade asset paid to lenderasset principal_turned_out- Amount of principal paid out to borrowerasset trade_turned_out- Amount of trade asset paid out to borrowerloan_close_operation(new)Fields:
account_id_type borrower- the borrower's account idloan_id_type loan- ID of the loan portfolio to adjustValidation checks:
borrowermust be a valid account ID, must exist, must authorize the operation, must pay feeloanmust be a valid loan portfolio ID and must existloan.owner == borrowerhead_block_time >= loan.earliest_endloan.principal_in_orders == 0 && loan.trade_in_orders == 0loan.principal_balance >= loan.principal_borrowed + loan.daily_interestEvaluation:
loan.principal_borrowedofloan.principal_assettoloan.lenderloan.principal_balance - loan.principal_borrowedofloan.principal_assettoloan.borrowerloan.trade_balanceofloan.trade_assettoloan.borrowerloan_closed_operationloanloan_update_operation(new)Fields:
account_id_type owner- Creator of the operation (fee paying account), must equal owner of the loan portfolioloan_id_type loan- ID of the loan portfolio to adjustasset principal_delta- Amount of principal asset to add / withdrawasset trade_delta- Amount of trade asset to add / withdrawextension_type ext- reserved for future extensionsValidation checks:
ownermust be a valid account ID, must exist, must authorize the operation, must pay feeloanmust be a valid loan portfolio ID and must existloan.owner == ownerprincipal_delta != 0 || trade_delta != 0principal_delta >= 0!confiscation_time.valid || trade_delta >= 0principal_delta > 0ortrade_delta > 0,ownermust have sufficient balancetrade_delta < 0loan.trade_balance >= -trade_deltamcv = loan.principal_borrowed + loan.minimum_collateralis_reference_price_validloan.principal_balance + loan.principal_in_orders < mcvmin_trade = reference_price * (mcv - loan.principal_balance - loan.principal_in_orders)loan.trade_balance + loan.trade_in_orders + trade_delta >= min_trade!is_reference_price_valid)mcv <= loan.principal_balanceEvaluation:
principal_delta > 0:principal_deltafromloan.owner's balanceprincipal_delta.amounttoloan.principal_balancetrade_delta != 0:trade_deltafromloan.owner's balancetrade_delta.amounttoloan.trade_balanceLoan 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_operationandfill_order_operationreceive one optional extension field:loan_id_type loan- ID of the loan portfolio from which the trade is executedThe
loanfield is not allowed before the hardfork time, neither directly nor in proposals.Validation checks:
If the
loanextension is present in alimit_order_create_operation, the following checks replace the existing checks against the seller's account balance:loanis valid and refers to an existingloan_portfolio_objectseller == loan.owner!loan.confiscation_time.valid(no trades after margin call)amount_to_sell.asset_id == loan.principal_asset || amount_to_sell.asset_id == loan.trade_assetamount_to_sell.asset_id == loan.principal_asset:loan.principal_balance - amount_to_sell.amount >= loan.minimum_collateralmin_to_receive.asset_id == loan.trade_asset!is_reference_price_valid0 < amount_to_sell.amount <= loan.principal_balance - mcvamount_to_sell.asset_id == loan.trade_asset:loan.trade_balance >= amount_to_sell.amountmin_to_receive.asset_id == loan.principal_asset!is_reference_price_valid0 < min_to_receive.amount <= loan.principal_balance - mcvEvaluation:
loanextension will be recorded in the newlimit_order_objectloanfield is present,amount_to_sellwill be deducted from theloanbalance and recorded inloan's..._in_orderfields, not the account'sfill_orderwill be modified to pay trade proceeds intoloanportfolio and adjustloan's..._in_orderfieldsfill_ordermust re-appraise the portfoliocancel_orderwill be modified to return funds intoloanportfolio and adjustloan's..._in_orderfieldsDatabase API Calls
The following methods will be added to the
database_api:vector<lending_offer_object> get_lending_offers_by_asset <loan-asset> <trade-asset> <optional limit> <optional start>vector<borrowing_offer_object> get_borrowing_offers_by_asset <loan-asset> <trade-asset> <optional limit> <optional start>vector<lending_offer_object> get_lending_offers_by_account <account> <optional limit> <optional start>vector<borrowing_offer_object> get_borrowing_offers_by_account <account> <optional limit> <optional start>vector<loan_portfolio_object> get_loans_by_lender <account> <optional limit> <optional start>vector<loan_portfolio_object> get_loans_by_borrower <account> <optional limit> <optional start>vector<limit_order_object> get_orders_by_loan <loan-id> <optional limit> <optional start>All result lists are ordered by ascending object id. Server-side limits are configurable.
Processing Logic Changes
Similar to database::apply_order(). Triggered when a new offer is evaluated.
taker_offer=new_offernew_offeris loan offerprioritization_policy= Favor Borrowers policycounter_offers= existing borrow offersprioritization_policy= Favor Lenders policycounter_offers= existing loan offerscompatible_offers=find_compatible_offers(new_offer,counter_offers,prioritization_policy)compatible_offersmaker_offer= highest-prioritized counter offerloan_object_id,taker_offer_filled] = create_loan(taker_offer,maker_offer,prioritization_policy)taker_offer_filledMargin calls
loan.confiscation_time = head_block_time + loan.call_durationloan.principal_balance >= loan.principal_borrowed + loan.daily_interest: close loan as described abovegap = loan.principal_borrowed + loan.daily_interest - loan.principal_balancelimit_order_createforloanwithamount_to_sell = loan.trade_balanceandmin_to_receive = gapgapis smaller or perhaps closed)Notes:
gap, possibly at a price far away from the usual market price. Thus, the borrower should avoid being margin called.gap. It may then be impossible to create a new order for the remaining gap, because that would be considered "dust". The consequence would be that the loan stays in margin call state until it is confiscated. For practical purposes this shouldn't make much of a difference because rounding issues are a few "satoshis" only.Interest payments
Similar to
database::clear_expired_proposals, in each blockloan_portfolio_object.interest_due_atagainsthead_block_time!loan_portfolio_object.confiscation_time.valid,loan.daily_interest > loan.principal_balance: initiate margin_callloan.daily_interestfromloan.principal_balanceloan.daily_interestofloan.principal_assettoloan.lender's balanceloan.daily_interesttoloan.cumulative_interestloan_interest_operationloan.interest_due_atExpire open offers
Similar to
database::clear_expired_orders, in each blocklending_offer_object.expirationandborrowing_offer_object.expirationagainsthead_block_timelending_cancel_operationand execute as describe aboveExpire open loans
Similar to
database::clear_expired_orders, in each blockloan_portfolio_object.latest_endagainsthead_block_timelimit_order_canceloperationsloan.principal_balance < loan.principal_borrowed + loan.daily_interest: initiate margin callHandle margin calls
In each block, for each loan that is in margin call state,
loan.principal_balance >= loan.principal_borrowed + loan.daily_interestConfiscate expired margin calls
Similar to
database::clear_expired_orders, in each blockloan_portfolio_object.confiscation_timeagainsthead_block_timeloan.principal_balanceofloan.principal_assettoloan.lender's balanceloan.trade_balanceofloan.trade_assettoloan.lender's balanceloan_closed_operationloanVote tallying
vote_tally_helpercomputesvoting_stakeper account as before, plus core intrade_assetin a loan_portfoliolender_stake = 0borrower_stake = trade_balanceprincipal_assetin a loan_portfoliolender_stake = min(principal_balance, principal_borrowed)borrower_stake = principal_balance - lender_stakeCalculate reference price
is_reference_price_valid = trueandreference_price = global_settlement_priceis_reference_price_valid = trueandreference_price = highest_offeris_reference_price_valid = trueandreference_price = last_exchange_priceis_reference_price_valid = falsePortfolio appraisal
principal = loan.principal_balance + loan.principal_in_ordersprincipal >= loan.mccv, clearloan.call_price(loan.trade_balance + loan.trade_in_orders) > 0loan.call_price = (loan.mccv - principal) / (loan.trade_balance + loan.trade_in_orders)reference_priceis valid andreference_price < loan.call_price: trigger margin callChanges to
cli_walletThe following commands will be added to
cli_wallet:list_lending_offers <account>list_borrowing_offers <account>get_lending_offers <loan-asset> <trade-asset>get_borrowing_offers <loan-asset> <trade-asset>lending_offer_createwith operation parametersborrowing_offer_createwith operation parameterslending_offer_cancel <id>lending_offer_accept <id> <amount> <duration>loan_update <id> <delta-principal> <delta-trade>get_loan_valuation <id>get_loan_call_price <id>loan_close <id>sell_assetcommand will receive an additional optional parameter, the loan portfolio idFinancial: 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.
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.
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.
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.
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
The text was updated successfully, but these errors were encountered: