Author Topic: Bitasset yield to market makers, a safe way to remove pricefeeds?  (Read 2135 times)

0 Members and 1 Guest are viewing this topic.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
but it would be pretty advanced and complicated

I don't think it would be much more advanced than what we've already got going here :) Though, I admittedly have no idea.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I'm suggesting that yield accumulates variably, and then is dished out when it is executed. For example, let's say the yield very close to the peg is 5%. If I had a bid 100% higher than the peg price at 0.1% yield, it (for the sake of this example) stays like that for a year, and then over a short period of time the price doubles and the order is matched, then the yield I will collect is still very close to 0.1%, not 5%.

Unless I'm not understanding what you're saying?

Having yield accumulate over time would require it getting paid out in periodic conditional transactions that can only be redeemed if the order is matched. I guess it could be done if dividends are ever implemented, but it would be pretty advanced and complicated.

Maybe it should be considered. Having yield paid out that way would give other benefits too.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I'm suggesting that yield accumulates variably, and then is dished out when it is executed. For example, let's say the yield very close to the peg is 5%. If I had a bid 100% higher than the peg price at 0.1% yield, it (for the sake of this example) stays like that for a year, and then over a short period of time the price doubles and the order is matched, then the yield I will collect is still very close to 0.1%, not 5%.

Unless I'm not understanding what you're saying?
« Last Edit: December 30, 2014, 05:53:21 pm by fluxer555 »

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Then the blockchain will need pricefeeds or trust ratings (like BM described) to determine what a given peg should be.

It wouldn't, you could just use the price range of the spread.

But when an order executes then the market considers that order to be in the peg, so it will give 100%. We'd need an external source of information to determine if a given peg is "deviating".

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
Then the blockchain will need pricefeeds or trust ratings (like BM described) to determine what a given peg should be.

It wouldn't, you could just use the price range of the spread.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
Quote
I was thinking the rate of yield should be higher the closer you are to the peg, and diminish as you move out. The thinking is:

Then the blockchain will need pricefeeds or trust ratings (like BM described) to determine what a given peg should be.

I think if you only institute yield-to-successful-orders once you already have a lot of old walls, and thus a lot of inertia, you won't need an extra system to encourage traders to set their orders close to the peg. If they observe huge walls that have accumulated a lot of yield, they know these walls will never be cancelled. If the walls are far enough off the peg, they might never go down. So someone who isn't planning to hold their money for several years will want to put their orders closer to the peg than the older orders.

Regarding yield, I think it should be possible to pay it out based on trade volume. If the algorithm is set so the yield fund on average always increases, then there shouldn't be big risks of it getting emptied out over time. Knowing that the yield fund always gets bigger, market makers will also be further incentivized to keep having massive old walls that never move.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
I've been thinking about this idea a lot over the past couple days, and it's very exciting to me.

Would this implementation affect the amount of yield that is able to be given to users? If so, how? My worry is if we start handing out yield like this, it will run too thin and won't be worth anyone's time.

I was thinking the rate of yield should be higher the closer you are to the peg, and diminish as you move out. The thinking is:

1. This incentivizes a tight peg
2. Bids close to the peg are more likely to be matched quickly, so the increased trading maintenance needs to be worth their time.
3. Only traders with massive amounts of BTS would be able to profit from yield close to the peg, as the yield accumulated in those short periods would have to compensate for the transaction fees. This means there will always be big players very near to the peg.
4. More casual traders will stay farther away from the peg, bringing in less yield, however with much less maintenance.

This means that yield would vary per bid depending on where the price feed is, block to block. I have a feeling this may have a large processing overhead.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I actually like your ideas here.   

Lets try something else on for size:  if we have a set of "gateways" each of which is issuing IOUUSD then we have a set of markets in chain for IOUUSD vs BTS which can serve as internal price discovery.  The challenge is knowing how to weight these internal markets.   We can solve this by having delegates publish trust ratings for each IOUUSD issuer.  They are implicitly doing this today in their price feed scripts.   We would merely be standardizing the feed script and moving the source of the feed to actual on-chain market data.

I like this idea too. That way we can have the shorting price feed be calculated every block (using the published trust rates from the delegates and the last internal market price) and thus still have shorting be relatively flexible. I'm actually a big fan of price feeds and this was my preferred solution for how they could eventually evolve.

But if price feeds are going to be updated anyway, I think it's worth it to experiment with ideas that remove them entirely since that makes everything so much more flexible. In addition to (maybe) securely allowing the removal of price feeds, the other advantage of paying interest to market makers is the boost in liquidity and decrease in volatility from the many "old walls" that will come up on every order book, and I think internal liquidity is really the only thing our system lacks at the moment.

No matter what changes are done to price feeds, I don't think they should be until our system is more mature. Right now the price feeds work and our market pegged assets look good, and no competitors have anything similar working yet.
« Last Edit: December 29, 2014, 03:53:06 pm by Rune »

Offline theoretical

I actually like your ideas here.   

Lets try something else on for size:  if we have a set of "gateways" each of which is issuing IOUUSD then we have a set of markets in chain for IOUUSD vs BTS which can serve as internal price discovery.  The challenge is knowing how to weight these internal markets.   We can solve this by having delegates publish trust ratings for each IOUUSD issuer.  They are implicitly doing this today in their price feed scripts.   We would merely be standardizing the feed script and moving the source of the feed to actual on-chain market data.

I like this.  But we'd want to use an outlier-robust method and some sort of time-domain filter as well.  I.e., if you see price data of 50, 49.95, 999999999.75, 50.07, 49.87 then it is pretty clear that one of these data points should be totally disregarded by whatever algorithm you choose.  Regardless of whether these are samples of five different BTS / IOUUSD markets at a single point in time, or samples of the effective exchange rate in consecutive blocks.  In other words, a large price change should not cause shorts to be margin called unless the high price persists for some time.  (Some amount of time-domain filtering currently happens implicitly because delegates rate limit their feed publishing since updating the feed requires a third-party API call and a transaction fee.)
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline bytemaster

I actually like your ideas here.   

Lets try something else on for size:  if we have a set of "gateways" each of which is issuing IOUUSD then we have a set of markets in chain for IOUUSD vs BTS which can serve as internal price discovery.  The challenge is knowing how to weight these internal markets.   We can solve this by having delegates publish trust ratings for each IOUUSD issuer.  They are implicitly doing this today in their price feed scripts.   We would merely be standardizing the feed script and moving the source of the feed to actual on-chain market data.



For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Rune

  • Hero Member
  • *****
  • Posts: 1120
    • View Profile
I had this idea when thinking about how to improve liquidity and make the DEX easier to use. If we want to make exchanges seamless we have to either have really long confirmation times (to get limit orders) or use the current "auto-frontrunning" order to force people to place their orders carefully.

Long confirmation times isn't feasible for obvious reasons, and the problem with the second solution is that it can be really annoying if liquidity is low. So I was thinking instead of trying to fix frontrunning we could instead incentivize liquidity.

What if yield was only paid to successfully matched bitasset orders?

So if you want to earn yield, you have to put it as an order on the exchange, and you will only get the yield if someone buys into your order. (If you cancel your order, you get nothing). This way you can also get yield for bitasset bids (so you can earn bitUSD yield on your BTS if you have an old bitUSD/BTS bid that is successfully matched). This would first of all make the order books much bigger. It would also make them "older". Most investors/traders would always have their money sitting around as orders, just in case they get hit and they can earn some yield.

But I think this could also work to eliminate the need for price feeds, because it would create so much inertia in the market that once a critical mass of orders have been reached on a given bitasset market, the peg will be forced to hold.

Imagine if there was a high volume USD gateway on the blockchain. Most inexperienced traders who have bought into bitUSD and want to try to earn some yield will put all their bitUSD as asks on the bitUSD/IOU market at slightly above the peg. People holding IOUUSD will put them all as bids at slightly below the peg. Over time we'd see the emergence of gargantuan buy and sell walls. The older these walls are, the more yield they will have accumulated, BUT this yield will only be paid out if they are actually matched. This means you can generally count on walls as being real, and with enough bitasset volume you can begin to fully trust the market peg even if it isn't backed by price feeds, because of the massive inertia from the old walls.

To give an example with numbers: Someone bids 99 IOUUSD for 100 bitUSD (1bitUSD=0.99USD). After one month, another person sells 1000bitUSD into this buywall. The market maker now ALSO gets 100 bitUSD*1 month worth of yield. If a bitasset seller got their order matched, then they would get the IOU or BTS they bought, AND get the yield on the bitasset they sold as a bonus. Because people will be reluctant to give up their yield, they will rarely cancel orders and will try to set them "right" the first time. With bitassets this will include always setting the price near the peg if they see other orders near the peg too, and everyone are highly incentivized to always market make because that's how you earn yield, meaning the peg will reinforce itself.

For simplicity I said that all bitasset yield should go to market makers. The yield calculation would have to based on average bitasset volume instead of market cap. If this is unfair to those who just want to hold their bitassets and don't want to deal with market making, there could still be a normal yield to them as well, as long as there is an extra incentive to be a market maker.

In the end I think ordinary bitasset holders will prefer having high liquidity rather than yield. Investors who buy bitassets to invest/speculate are also willing to market make. Ordinary people who hold bitassets to spend are most concerned with being able to get in and out of the bitasset as quickly and easily as possible, so they will much prefer the extra market making. So I don't think there would be anything wrong with simply giving all yield to market makers.