Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - George_Bitspark

Pages: [1] 2 3 4 5
1
Yes we want sparkdex.ETH to be included in this. Thanks.

2
Appreciate the support we have so far.

3
Introduction:

Today I am presenting to the Bitshares community our proposal for your consideration as a block producer (witness). As you may know, Bitspark (Bitshares account: bitspark-delegate) is also a current member of the Committee (https://bitsharestalk.org/index.php?topic=28395.0) and we operate the Sparkdex gateway at https://dex.bitspark.io. We have also have a custodial web and mobile app which includes fiat deposits and withdrawals in a number of currencies and countries at https://www.bitspark.io/.

We have demonstrated a commitment to the Bitshares ecosystem for a while now and started running our API node SparkHK last year for Sparkdex users. We own all of our own infrastructure as dedicated servers and as a for-profit company we have a vested interest in making sure uptime is as close to 100% as possible. We have a dedicated tech team available to maintain and update our infrastructure as necessary and we do this on a daily basis as part of our business operations anyway.

We recently were voted as block producer on testnet and currently have 5 missed block so far, you can check here: https://testnet.bitshares.eu/explorer/witnesses.

We will focus on block production only at the moment. Regarding price feeding, we may look to provide price feeds in future for committee assets but all formulas to derive prices will be public via our github: https://github.com/Bitsparkltd/bitshares-pricefeed-ruby just like our existing price feeding for Stable.PHP. There will be no manipulation of price feeds by bitspark-delegate, we do not care what some people say should be ‘consensus’ as the whole point of price feeds is to have a diverse set of witnesses providing a diverse set of prices converging on the true value of an asset. Prices fed should reflect the real value of BTS relative to that asset and we use the common principle used in institutional markets for pricing assets as using the ‘most liquid market’ principle when pricing BTS. 

We therefore hope you will consider voting for bitspark-delegate as a witness and we will provide updates to this post.

Current Server setup:
 
Block Production:
Type: Dedicated
Processor: Intel Core i7-6700
CPU Cores: 4
RAM: 64GB DDR4
Disk Space: 2x 512 GB NVMe SSD
Connection: 1 Gbit/s port
Location: Germany

Type: Dedicated
Processor: Intel Core i7-6700
CPU Cores: 4
RAM: 64GB DDR4
Disk Space: 2x 512 GB NVMe SSD
Connection: 1 Gbit/s port
Location: Finland

API Node:
Processor: Intel Xeon E5-2650 v4
CPU Cores: 12
RAM: 128GB DDR4
Disk Space: 4x480 GB SSD
Connection: 1 Gbit/s port
Location: Hong Kong
wss://ws-dex.bitspark.io

Value add to Bitshares community:

* Dedicated infrastructure
* Professional tech team maintaining infrastructure
* Track record and involvement in Bitshares on testnet
* Engaged in on-chain governance of Bitshares

4
By what standard will new price feeders, which will need to be approved by the committee need to meet? What standards on price will the committee set? I am happy to consider any formulas for price feeding. This is very important to understand

5
bitspark-delegate has been voted back into the committee, we look forward to continuing where we left off. First step is ensuring we wind down active positions held by the committee as we believe the committee should not be involved in making markets as the potential for vested interests co-opting that position is too high and MM activities should be left to the market.

6
General Discussion / Re: suggestion on new OMO fund
« on: September 06, 2019, 01:43:56 am »
No, this is a terrible idea, the OMO was already a failure and doubling down on failure is not a recipe for success. Focus less on trying to control the price (and being bad at that) and more on bringing new business and users to Bitshares- thats how you grow the price. With workers de-funded, no core or UI team why would anyone buy bitshares right now? There is a choice of many tokens to buy, many have active development, Bitshares does not, nobody would want to buy a token with no future.

Committee is not a slush fund, they exist only to adjust on chain parameters.

7

* One option would be that the *committee* is the sole authority to enable lending on specific asset pairs


I disagree and this should be entirely off the table. The committee is not a centralised exchange, it also constantly changes and is outside their initial scope. Then there would be lobbying, politics of the committee, easy for existing businesses to screw over new businesses on bitshares by denying making only 1 or 2 gateways able to supply lending in their pairs etc. Really terrible. The competitor here is Ethereum DeFi smart contracts which are totally open to all and MKRDAO has attracted over $1bn in collateral because it is free and open to use. If some company wants to use MKR in their product somehow thats up for them to set for their particular customers.

Quote
* Another option would be to allow the asset holders to enable assets for pairing and specify which pairs could be opened in case the pair has lending enabled too

Yeh this is reasonable. So like an additional flag adjustable by asset issue? "Open to lending/margin" which can enabled/disabled by the issuer. Good idea!

Quote
* Also, i highly recommend to limit the amount of tokens that can be used for lending. This should also prevent a side of the orderbook from being wiped

We already have a good mechanism to deal with cases of catastrophic margin calls.
If the borrower is in default, his position will execute a limit order on the dex fill_or_kill to buyback the necessary coins to payback the lender. If there is not enough liquidity on the orderbook then the order will sit there until expiration (can be set by lender), maybe someone else comes along and buys into his order. If nobody comes then the remaining tokens are returned to the lender, in this case the lender has received a different asset to what he lent but this is the risk he takes when he lends, he defines what assets he is comfortable with the borrower buying so therefore he has assumed the risk he may get those assets in return in the case of a margin call. 


 

8
we can see that now although BTS/bitEUR pair is in poor liquidity, but user can still borrow bitEUR with little difference comparing to borrowing bitCNY. why? because the reference price is fed, not the last price, if the margin call rules reference the last price, easy to expect that the debt position will be margin called in minutes via manipulation, no doubt.
/quote]

Very easy to set a price to buy bitEUR at 10% below market price expecting margin calls, then get cheap bitEUR. This incentivises market making because the cheap bitEUR I can go sell elsewhere for 10% profit. Everyone would do this and if that is the case then the margin calls dont affect much anymore because the orderbook is more deeper.

I agree maybe last price is not ideal, perhaps there is a better solution? I think witness price feed is just not viable though because its very limiting and also easily manipulated but in a different way (like how some witnesses not providing right price for bitCNY).

Quote
another question, who can decide to add such a feature to one pair? I don't think it's good to just add this feature to all the pairs, maybe committee should have the right to decide to include which pair. and  the precondition  is that the asset issuer agree to add.

Disagree, the committee is meant to adjust blockchain parameters to ensure bitshares DAC is profitable, not decide who gets to trade what like an exchange otherwise might aswell just go trade on Bitfinex or Binance, the whole idea about DeFi is that is 'decentralised finance'. The biggest value add Bitshares has is its open to everyone so lets keep it like that so if some new coins wants to start on bitshares its very easy to advertise lending returns and get started immediately, more coins = more fees paid in bts = more demand for BTS = higher price of BTS.

9
And P2P Lending is not so unknown to Authorities btw:

https://en.wikipedia.org/wiki/Peer-to-peer_lending#Government_protection

So, let's do it properly and introduce really big boom to the world without any risk to the future of BitShares.

This is not related to the topic which is about price discovery for a protocol upgrade. Things relevant to your particular circumstances as a company or who you choose to service or not is outside the scope of this discussion.

10
To clarify, the "bombastic" was really rather meant as "fantastic" .. just a little more .. the desired meaning got lost in translation.

Secondly, I do share some of DL's concerns but also don't see why this should become an issue for either BBF, or MOVE insitute. None of them technically "operate" the BitShares blockchain (and fact, it's unclear who really does). Similar to how the UI should IMHO be blocked to US IPs, the feature for lending should also be blocked from IPs of countries that prohibit lending. That at least should be clear to anyone hosting a frontend that allows using that particular feature of bitshares - but again, this is new territory from legal point of view and we simply don't know what regulators and law enforcement will think.
To me, it is quite easy to logically claim neither the owner of bitshares.org, nor of bitshares.foundation has anything to do with the offers of the bitshares blockchain (which runs entirely independent). It's like laming Mozilla for providing software to browse the dark net. Not their fault, really.
It is different though for those that "host" a wallet/ui. At least I can see problems come up to them for providing an "entrance".

Ultimately, we need to distinguish service offerings of bitshares.org from services offered by the BitShares Blockchain.
Also, the owner of bitshares.org has not sole authority over the BitShares Blockchain and couldn't even prevent them from doing things that bitshares.org might disagree with, like offering a lending market. Something similar could be said about CFDs which are to my knowledge prohibited in the U.S. too.

(not a lawyer)

Yes, as I said the Bitshares protocol is entirely separate to random companies that have the name 'Bitshares' or brand their services to customers using that name. This discussion relates to a protocol change, other discussions or actions taken by other companies should be kept separate to this discussion.

11
Hi all,

BSIP70 "Lending for Margin Trading" is getting closer and there remains a few key points to address. One is important and warrants a thorough discussion is about how to determine 'the price' of the asset being lent relative to the collateral held and market price of the collateral vs the lent asset.

Firstly a lender defines the markets in which he is willing for the borrower to use his lent asset. Therefore the lender assumes risk and takes responsibility for the liquidity, pricing and legitimacy of those markets. The risk for the lender is he may not get back the amount lent in the case of a catastrophic collapse in price of the the lent asset vs the asset the borrower buys. Discussion on margin call mechanics aside (which I think was covered well in Github) the main point for community input now is on 'the price'- what is it, where is referenced to and the best method for insuring a robust pricing for these margin loans.

A price is required for many of the key operations required for BSIP70. You need a price to determine the collateral ratio of the borrowers collateral vs the the size of the loan. You need to monitor the price for a margin call event and you need to execute a limit order in the case of a margin call at some price in order buy back enough of the loan to repay the lender. An accurate price is needed in all these cases, we will call this a 'reference price'. Lets examine how similar lending and margin markets have existed on other platforms:

Bitfinex: Bitfinex has the most similar proposed margin trading and lending system to BSIP70. Bitfinex choose what markets can be used for lending so they limit the issue of exposure to illiquid markets. The Bitfinex price they use for the loans is based on the 'Last price' in that market. That means that the last executed trade represents the pricing of that asset pair. This is a simple and direct method of determining the price.

Bitmex: Bitmex, while not employing the same P2P CFD style of margin trading as BSIP70 still needs a price for their margin mechanisms. Bitmex use an external price feed of the bitcoin price relative to their self selected set of coins they list. They use multiple datapoints to ensure the robustness of their pricing feed based off the prices of several exchanges.

Other solutions: Perhaps a Middle price could be used which is = ((highest bid + lowest ask) / 2). However we would need to carefully think of the implications of this and how to game it. I have some initial thoughts but open to ideas here.

I think the best solution is just to use the last price for that particular market pairing, yes it is open to someone dumping price and forcing margin calls but the lender takes that into consideration when he allows his asset to be traded on that market knowing the risk is that he might not receive  what he lent in return. A conservative lender might only be willing to lend to high volume and liquidity markets to limit his risk of a giant margin call killing the last price. Also, even if this were the case, if I knew there was a market with a high chance of this happen this is an excellent opportunity for market makers. If there was alot of margin calls on one market I as a market maker would place bids 10% below market price knowing ill be able to scoop up cheap coins in the event of the margincall and sell them on another exchange for a price 10% higher using a cross exchange arb like via DEXbot.

What are the best methods in order to establish a reference price that is robust that you would like to see? Did I miss any potential implementations?

Logic/Concept - Support.

 3 things I might add/define better to this above, before it goes to reality:

1) Markets with no liquidity are a big no-no. Currently only liquid market on the entire blockchain seems to by BTS:BitCNY if we are to compare liquidity with Bitfinex, Bitmex or even Poloniex and take them as fine working example (they do provide these services for quite a while without problems).
2) For UIA price should still be determined by 3rd source and witnesses should be doing minimum 2 feeds for that contract. Marketplace gives Lender opportunity to rig the debt over the period of time since amount of return is in the same contract not related to any pair of it. If for example open.USDT or Spark.HKD, by 2 fiat sources against contracts used for lending.
3) bitshares-core software should determine on its base level of asset are markets liquid enough or not, not the Lender. e.g. bsip70_enable_marketminimum_volume = 500,000.00000 BTS


Anything else would be potential manipulation.

Chee®s

1. Firstly its up to the lender to set the markets you want to lend to, Bitshares is decentralised and everyone should be free to lend to whatever they want its not up to someone to decide what people can and cant do, in this case the lender assumes the risk if they allow a borrower to take their money.

Secondly "Liquidity" is only important when referenced to how much you are loaning. For example if the market cap of a particular coin is $10000 and you are loaning $1, just because the market cap is not high relative to Bitcoin, the fact you are lending a small amount does not present any high risk to that market and because the market cap is low it can actually be difficult to find lenders/traders willing to engage in that market. So I dont see this as a concern TBH.

2. Not sure what you mean here but lets address additional price feeds. If we require additional price feeds there are a few concerns:

A ) Whos going to provide them and for what coins?
B ) This is additional computational burden on the network and we dont have a large number of witnesses as it is
C ) Whos feed is correct? Will we use median values for a number of witnesses? Then we will also need to design new voting principles for price feeders for lending.
D ) Last but most importantly it limits who and what you can lend and trade. If there is no price feed its no longer possible to margin on that market. People should be free to lend some small cap coin for some other small cap coin without being dictated to what they can and cant do because a small set of 10 random people in the world dont want to provide feeds for their coin. This massively limits this BSIP to probably only 0.001% of Bitshares markets. We want to make this BSIP for anyone to be able to get leverage and earn a return on anything.

3. Volume is not a good indicator and easily faked. Also, for UIA markets one can easily trade 1 BTS for 1S**TCOIN @ price of $100000. Then execute 2 trades daily in order to get a volume of $200000 which magically enables them go margin on whatever. Whereas maybe there is a small cap coin with a real market but is below some artificial threshold which is honest, but is not able to get margin access because its not above some arbitrary value. Also it should not be up to core or some individuals to determine what you can trade or not. Also for UIA/UIA makets there is no BTS reference so not possible to get a BTS volume as benchmark even if there was it would not be representative of real BTS because UIA/UIA are easily faked whereas BTS/UIA actually requires someone to pay real value to exchange them.

1. BitShares is a brand and technology that has LEGAL reponsibility in the real world. Regarding blockchain, BBF, regarding bitshares.org Move Institute. If Authorities are to knock someone's doors for BitShares, that would be first 2 to knock on. You ? Just a 3rd party company utilizing free and decentralized BitShares blockchain platform without written agreement that you bare no responsibility towards actions that you're doing on BitShares blockchain. For a Money Remittance business, you're far off the grid with your comments if you want real main-stream.

In some countries you know that Lending is against the law ? Shall we disable API access to those countries just so anyone can become a Lender and start making profits from the blockchain without any concern on the consequences that may happen ? "Decentralized" you can look up in dictionary, same as you did for "bombastic" and come back here to tell me what decentralized has to do with lawless.

2.
A) Concern who will do price feed ? Up to the lender who was interest on return to employee more witnesses and even pay them privately for price feed if needed.
B) Nothing computational is happening, apart from regular price feed added to another token through a 3rd party independent script between blockchain and 3rd party (as now).
C) If you wanna Lend Spark.HKD and re-claim it in real HKD at your offices, wouldn't be fair at local currency/exchange (fiat) to be borrowed ?
D) Yes, ofcourse it is, otherwise everybody would be having bad debts and everything would go to shit, how here that in real world. Limits are nothing bad IMO. (look what BSIP42 did with no limits)

3.

Creating a volume and price feed combined would be exactly too hard to maintain and Lender would not be diving it into it, if he is not up for a real business. Borrower would not dive inside to unstable/unknown conditions.

Such markets/assets should be always and only issued with multi-sig on committee, otherwise we will move in from gray to very black area of crypto industry.

Chee®s

P.S. I said, support fully just in terms that lending should have limits by the blockchain not by the lender. If you think that's not fair, then you're far from decentralized. Lender dictating rules is very centralized process with no legal process or responsibility to it. Better to compute and calculate rather than trust, hence we are still looking for trustless gateways/solutions.

Firstly this is about the price discovery mechanism, most of your concerns are unrelated to this, please stay on topic.

1. I dont think you understand the difference between a gateway and Bitshares. Bitshares is an open source protocol and is not based in or operates from or services any jurisdiction. It is decentralised. Gateways are companies that operate in and service customers from various jurisdictions. The Bitshares protocol doesnt care about the legislation in any particular jurisdiction, its irrelevant. If you want to make a company and call it 'Bitshares' thats cool thats on you and you undertake responsibility servicing customers in that jurisdiction but thats entirely different to the protocol. We are discussing the Bitshares protocol not any companies that bear the name or Gateways associated with Bitshares, thats their prerogative.

2.
A. No its not actually, the existing proposal doesnt mention anything about price feeds, so its not necessary, therefore it is incumbent on you to define why it is necessary. Just saying someone should do it is not a reasonable response.

B. Incorrect, there is more computational load on the blockchain with more feeds and additional operations required to service that.

C. This sentence doesnt make any sense, not sure what redemption of a stablecoin has to do with a lending feed. We are talking about the proposed feed and a median price for it. As I said I find this approach to not be reasonable given the concerns in 2.

D. "otherwise everybody would be having bad debts and everything would go to shit, how here that in real world"

This seems like an arbitrary offhand statement based on hand waving and conjecture. As stated previously it is the responsibility of the lender to assume the risk of the borrower- just the same as it is when we rely on the debt positions for BitCNY/BitUSD. This proposal of price discovery is a voluntary interaction between two consenting parties to agree on a mutually beneficial price between those parties. You dont know what the interest rate or price should be, neither do i, but the market will establish that.

3. Not sure what your response has to do with Volume as an easily exploitable metric. As I said, if something can be exploited, as I just laid out, it should not be part of the protocol, period.

Quote
P.S. I said, support fully just in terms that lending should have limits by the blockchain not by the lender. If you think that's not fair, then you're far from decentralized. Lender dictating rules is very centralized process with no legal process or responsibility to it. Better to compute and calculate rather than trust, hence we are still looking for trustless gateways/solutions.

So you advocate for a smaller number of specifically defined people to arbitrarily decide what you can and cant lend. Then you say it is more decentralised than an infinite number of lenders can decide on any parameter at any time. Thats literally the opposite of what youre advocating, an infinite amount of lenders is more decentralised than say, 10. Confirmed. An infinite number of parameter combinations is more decentralised than a specified number set by a few people. Confirmed. Therefore this statement doesnt hold up.

12
Hi all,

BSIP70 "Lending for Margin Trading" is getting closer and there remains a few key points to address. One is important and warrants a thorough discussion is about how to determine 'the price' of the asset being lent relative to the collateral held and market price of the collateral vs the lent asset.

Firstly a lender defines the markets in which he is willing for the borrower to use his lent asset. Therefore the lender assumes risk and takes responsibility for the liquidity, pricing and legitimacy of those markets. The risk for the lender is he may not get back the amount lent in the case of a catastrophic collapse in price of the the lent asset vs the asset the borrower buys. Discussion on margin call mechanics aside (which I think was covered well in Github) the main point for community input now is on 'the price'- what is it, where is referenced to and the best method for insuring a robust pricing for these margin loans.

A price is required for many of the key operations required for BSIP70. You need a price to determine the collateral ratio of the borrowers collateral vs the the size of the loan. You need to monitor the price for a margin call event and you need to execute a limit order in the case of a margin call at some price in order buy back enough of the loan to repay the lender. An accurate price is needed in all these cases, we will call this a 'reference price'. Lets examine how similar lending and margin markets have existed on other platforms:

Bitfinex: Bitfinex has the most similar proposed margin trading and lending system to BSIP70. Bitfinex choose what markets can be used for lending so they limit the issue of exposure to illiquid markets. The Bitfinex price they use for the loans is based on the 'Last price' in that market. That means that the last executed trade represents the pricing of that asset pair. This is a simple and direct method of determining the price.

Bitmex: Bitmex, while not employing the same P2P CFD style of margin trading as BSIP70 still needs a price for their margin mechanisms. Bitmex use an external price feed of the bitcoin price relative to their self selected set of coins they list. They use multiple datapoints to ensure the robustness of their pricing feed based off the prices of several exchanges.

Other solutions: Perhaps a Middle price could be used which is = ((highest bid + lowest ask) / 2). However we would need to carefully think of the implications of this and how to game it. I have some initial thoughts but open to ideas here.

I think the best solution is just to use the last price for that particular market pairing, yes it is open to someone dumping price and forcing margin calls but the lender takes that into consideration when he allows his asset to be traded on that market knowing the risk is that he might not receive  what he lent in return. A conservative lender might only be willing to lend to high volume and liquidity markets to limit his risk of a giant margin call killing the last price. Also, even if this were the case, if I knew there was a market with a high chance of this happen this is an excellent opportunity for market makers. If there was alot of margin calls on one market I as a market maker would place bids 10% below market price knowing ill be able to scoop up cheap coins in the event of the margincall and sell them on another exchange for a price 10% higher using a cross exchange arb like via DEXbot.

What are the best methods in order to establish a reference price that is robust that you would like to see? Did I miss any potential implementations?

Logic/Concept - Support.

 3 things I might add/define better to this above, before it goes to reality:

1) Markets with no liquidity are a big no-no. Currently only liquid market on the entire blockchain seems to by BTS:BitCNY if we are to compare liquidity with Bitfinex, Bitmex or even Poloniex and take them as fine working example (they do provide these services for quite a while without problems).
2) For UIA price should still be determined by 3rd source and witnesses should be doing minimum 2 feeds for that contract. Marketplace gives Lender opportunity to rig the debt over the period of time since amount of return is in the same contract not related to any pair of it. If for example open.USDT or Spark.HKD, by 2 fiat sources against contracts used for lending.
3) bitshares-core software should determine on its base level of asset are markets liquid enough or not, not the Lender. e.g. bsip70_enable_marketminimum_volume = 500,000.00000 BTS


Anything else would be potential manipulation.

Chee®s

1. Firstly its up to the lender to set the markets you want to lend to, Bitshares is decentralised and everyone should be free to lend to whatever they want its not up to someone to decide what people can and cant do, in this case the lender assumes the risk if they allow a borrower to take their money.

Secondly "Liquidity" is only important when referenced to how much you are loaning. For example if the market cap of a particular coin is $10000 and you are loaning $1, just because the market cap is not high relative to Bitcoin, the fact you are lending a small amount does not present any high risk to that market and because the market cap is low it can actually be difficult to find lenders/traders willing to engage in that market. So I dont see this as a concern TBH.

2. Not sure what you mean here but lets address additional price feeds. If we require additional price feeds there are a few concerns:

A ) Whos going to provide them and for what coins?
B ) This is additional computational burden on the network and we dont have a large number of witnesses as it is
C ) Whos feed is correct? Will we use median values for a number of witnesses? Then we will also need to design new voting principles for price feeders for lending.
D ) Last but most importantly it limits who and what you can lend and trade. If there is no price feed its no longer possible to margin on that market. People should be free to lend some small cap coin for some other small cap coin without being dictated to what they can and cant do because a small set of 10 random people in the world dont want to provide feeds for their coin. This massively limits this BSIP to probably only 0.001% of Bitshares markets. We want to make this BSIP for anyone to be able to get leverage and earn a return on anything.

3. Volume is not a good indicator and easily faked. Also, for UIA markets one can easily trade 1 BTS for 1S**TCOIN @ price of $100000. Then execute 2 trades daily in order to get a volume of $200000 which magically enables them go margin on whatever. Whereas maybe there is a small cap coin with a real market but is below some artificial threshold which is honest, but is not able to get margin access because its not above some arbitrary value. Also it should not be up to core or some individuals to determine what you can trade or not. Also for UIA/UIA makets there is no BTS reference so not possible to get a BTS volume as benchmark even if there was it would not be representative of real BTS because UIA/UIA are easily faked whereas BTS/UIA actually requires someone to pay real value to exchange them.

13
wow ... bombastic proposal

??

Definition Bombastic: marked by or given to speech or writing that is given exaggerated importance by artificial or empty means

You think BSIP70 is exaggerated or lacking? Please let us know so we can improve it ;) 

14
Hi all,

BSIP70 "Lending for Margin Trading" is getting closer and there remains a few key points to address. One is important and warrants a thorough discussion is about how to determine 'the price' of the asset being lent relative to the collateral held and market price of the collateral vs the lent asset.

Firstly a lender defines the markets in which he is willing for the borrower to use his lent asset. Therefore the lender assumes risk and takes responsibility for the liquidity, pricing and legitimacy of those markets. The risk for the lender is he may not get back the amount lent in the case of a catastrophic collapse in price of the the lent asset vs the asset the borrower buys. Discussion on margin call mechanics aside (which I think was covered well in Github) the main point for community input now is on 'the price'- what is it, where is referenced to and the best method for insuring a robust pricing for these margin loans.

A price is required for many of the key operations required for BSIP70. You need a price to determine the collateral ratio of the borrowers collateral vs the the size of the loan. You need to monitor the price for a margin call event and you need to execute a limit order in the case of a margin call at some price in order buy back enough of the loan to repay the lender. An accurate price is needed in all these cases, we will call this a 'reference price'. Lets examine how similar lending and margin markets have existed on other platforms:

Bitfinex: Bitfinex has the most similar proposed margin trading and lending system to BSIP70. Bitfinex choose what markets can be used for lending so they limit the issue of exposure to illiquid markets. The Bitfinex price they use for the loans is based on the 'Last price' in that market. That means that the last executed trade represents the pricing of that asset pair. This is a simple and direct method of determining the price.

Bitmex: Bitmex, while not employing the same P2P CFD style of margin trading as BSIP70 still needs a price for their margin mechanisms. Bitmex use an external price feed of the bitcoin price relative to their self selected set of coins they list. They use multiple datapoints to ensure the robustness of their pricing feed based off the prices of several exchanges.

Other solutions: Perhaps a Middle price could be used which is = ((highest bid + lowest ask) / 2). However we would need to carefully think of the implications of this and how to game it. I have some initial thoughts but open to ideas here.

I think the best solution is just to use the last price for that particular market pairing, yes it is open to someone dumping price and forcing margin calls but the lender takes that into consideration when he allows his asset to be traded on that market knowing the risk is that he might not receive  what he lent in return. A conservative lender might only be willing to lend to high volume and liquidity markets to limit his risk of a giant margin call killing the last price. Also, even if this were the case, if I knew there was a market with a high chance of this happen this is an excellent opportunity for market makers. If there was alot of margin calls on one market I as a market maker would place bids 10% below market price knowing ill be able to scoop up cheap coins in the event of the margincall and sell them on another exchange for a price 10% higher using a cross exchange arb like via DEXbot.

What are the best methods in order to establish a reference price that is robust that you would like to see? Did I miss any potential implementations?

15
There is an upcoming BSIP70 proposal (Margin lending and Trading on the DEX) which I have been working with the Core Team on in order to get into the next major Bitshares Protocol Upgrade release as soon as possible. Part of that BSIP involves some Committee adjusted parameters, I will be happy to make some recommendations on these parameters when the final spec for BSIP70 is approved for the community to review.

Pages: [1] 2 3 4 5