Quote from: BitBits on October 12, 2014, 01:30:09 AM

Quote from: pgp on October 11, 2014, 03:05:58 PM

Quote from: DoubleSwapper on October 10, 2014, 09:59:39 PM

Quote from: noggin-scratcher on October 10, 2014, 11:29:19 AM

I've come to really dislike the Flash Return Rate. I'll try and be articulate about why...

The problem as I see it, is that it's currently the only option for offering swaps at a variable rate, and the only option to offer automatically at a rate that adjusts (somewhat) to market conditions. If you want to be fairly hands-off and automated about things, it's kind of the only game in town. It's normally nowhere near an optimal rate to be offering at - being either too high when rates are decreasing and everyone jumps in front of it, or far too low when rates have headed back up (see also: right now), but without any other auto-rate options it gets heavily used.

So we get, most of the time, an enormous wall of offers all placed at the single FRR, making it very difficult for the rate to rise higher - the FRR keeps slipping down as the average diminishes, until there's enough pressure to chew through it all at once (or possibly by 30-day swaps being taken over the head of the FRR-wall) and the rate suddenly spikes upwards, dragging the FRR reluctantly upward with it.

So that's my thesis - FRR is a magnet for a giant heap of offers from those who don't have the free time required for manual management, or who want to avoid being stuck in a poorly placed fixed-rate swap, and its effect on the market is to produce that weird sawtooth pattern in swap rates, with sharp increases followed by slow deteriorations. I really wish there were better options for an automated rate. Or even just more options so as to spread the pile out a bit more. If we could set offers at a fixed offset away from the FRR, or have fixed-rate offers that are automatically placed at a certain 'depth' into the book of offers, or have a tracker rate that's slightly more responsive (a weighted moving average of recent fixed-rate swaps rather than a simple average rate?)... then I would be so happy.

Completely agree. I've wrote about that as well. The swap order book is so thin that these out of the blue 200 k to 500 k offers churn through the order book completely because nobody bothers to put in any offers above a +1 mio sometimes +3 mio wall that the FFR inevitably creates as soon as long demand decreases. When the rate is high then the lagging FFR comes up and puts offers far, far below the lost offer at that time which doesn't make sense at all.

Hi, All,

My name is Phil and I am also associated with Bitfinex, and though I never post on btctalk, I wanted to address this issue and get more feedback. FRR is calculated as the volume weighted rate of all the open fixed rate swaps, so naturally it will lag the inside market and this, of course creates problems for liquidity as it's the only real mechanism we have for auto renewing swaps. We have spent some time thinking about how to improve this, but frankly haven't arrived at anything that we like better. I will say, though, that we can certainly make it better by offering various embedded algos with user specified parameters, the problem is that we don't want to make it overly complicated, either. So, the right solution has to be one that is simple and easy to understand. So I will ask all of you. Specifically, how would you improve it? We recognize the need for improvement - so your suggestions are welcome!

Hello Phil,

I've personally seen good use of FRR feature in the past, but these days I would agree with noggin-scratcher regarding the issue of "an enormous wall of offers all placed at the single FRR" and the resulting huge spikes (like today, to 0.7%!!!) when this wall is gone. I do not think however that FRR feature needs to be eliminated entirely.

To your list of simpler solution suggestions, I would propose to limit the total volume of FRR offers to a certain percentage of total offers on the order book. I don't know what percentage allocated to FRR will be optimal, but I guess you could start from some high value and go down over time, to ensure smooth transition.

It basically comes to the (optional) requirement for users to specify the rate when they are placing FRR offer. We already have a box for this entry, but currently it gets ignored by the system, if user clicks on FRR option, so perhaps we should try to enable that.
Under simplest implementation of this feature, user's offer will be placed at FRR, or at specified by him/her rate if FRR quote is already taken.

Slight modification of the above will be the availability of additional options, when placing the swap offer, such as the following:
1. Place offer at FRR, or if not available - at user specified rate (this is the same as described above)
2. Place offer at FRR, or if not available - at equal to then current FRR rate (this can be useful, for those using auto-renewal option)
3. Place offer at FRR, or if not available - do NOT place any fixed rate offer, wait until FRR offer CAN be placed.

Note that the option 3 above is very similar to what we have right now (meaning that your offer will "stand in line" for placement at FRR). For this reason, option 3 can be made a default setting. Options 1 and 2 will create much thicker order book and prevent big spikes.

Other than the above, availability of some algos would be ideal and by the way, if you do not want to make the whole platform "overly complicated" (this is of course understandable), perhaps you can make algos available only to those who wants to use them, leaving simpler solution for the rest. I guess BFX will run into problem when people would just "enable" the algos and then annoy the hell out of support team asking basic question instead of reading some sort of a "how to" . To avoid this, a comprehensive "How to" section can be created and users wishing to use the "algo system" would have to pass a simple quiz, before it is enabled on their account for them.

What do you (and all) think?

None of these ideas will solve the problem, all they will do is hide it. If a lender is allowed to queue up for the FFR, the wall is still there, but now it is hidden.

Take scenario 1. If the FRR is full and a lender puts an offer in below the current FFR, his offer will be taken before the FRR and drive the FRR down until it is equal to his offer. Other lower offers will probably pull the FRR down to or below his offer. If his offer is not fully taken, we will now effectively have scenario 2 or 3.

If a lender has an offer equal to the FFR, we are right back where we started, if the offer is greater, we have a worse situation. As the FRR offers are taken and the FRR limit is depleted, the waiting offers will be converted to FRR to fill it back to the limit. This will continue until all waiting FRR offers are exhausted. Since other lenders will not know how much is waiting to be converted to FRR, the wall will still be there but they will not be able to see it.

As an example, let the FRR limit be 100k and be currently filled. A lender or group of lenders put 1m in the FRR queue. All we can see in the swap book is 100k at FRR. If a swap of 50k is taken, the system now has space to add 50k from the queue and does so. The swap book still shows the same, 100k at FRR. This will continue until all 1.1m in offers is exhausted. The 1.1m wall is still there but it is now invisible. To make matters worse, if the FRR engine is fast enough, a lender will not even be able to tell that FRR offers are being taken and it will just appear that the no offers are being taken at FRR.