How is liquidity provision incentivized?

This is an assumption. We just don’t have the required skill set available and need to compromise.
Fixed cost will be more expensive or at least as complicated as fixed reward to make it work. I’m thinking of keeping my pools a bit longer on the Dutch action model as it is a lot cheaper for Nu overall. Unfortunately I’m lacking time to compile all the logs with the proof. If someone is interested I’m happy to share after anonymising it.

I doubt fixed cost is going to solve the gaps on 1 exchange because some major trades are happening. That will most likely require the intervention of a T1-T3 custodian anyway. Before those deals are made a few will be paid a premium for almost no liquidity.

CRFC can be used to reduce the costs if FC doesn’t have the desired effect on the liquidity situation:

You’re going to compare nbt/cny on bter to nbt/usd on ccedk?

If you switched to fixed cost and started pulling twice as much liquidity, but having no rollover, would the Dutch auction model still be preferred? What if you cut the cost in half and still pulled 10k combined on the nbt/usd pool? Gotta compare apples to apples here, and the nbt/usd pool has been at target for some time now.

Sounds interesting on paper, so the rewards will be shared amongst all participants on an equal bases? Can everyone compete or is it first in, first paid? I think I have to see this working first.

Not comparing a particular pair. If anythin the EUR/NBT pair is far more interesting as this has been under- and over performing (competition). From what I’ve seen that worked very well. At some stage the pool was just paying 0.9% as it was oversubscribed, at other days it was just paying the liquidity provided when it was under subscribed, nothing less nothing more.

How can you deduce that from the info mentioned on http://nupond.net/ ?

In any case, it seems to me that in FR, you can specify a minimum return if your funds are actually used. You can also make sure that you will get something out of your funds if you are willing to accept the minimum rate but that something is how much?
In FC, is it possible to specify a minimum return rate if your funds are actually used?

In any case, as a potential pool participant, I think it is crucial to be able to guarantee the fact that you will get at least a certain rate on your funds regardless of the liquidity provided.

Is it the case of current pools?

The interest parameter still works on both FC and FR, your bot will delete funds if the rate is < the interest.

No, nupond does not fully explain FC, in the same way that other pools aren’t really fully describing the Dutch auction mechanism on their websites. I would love to do API stuff and announce the rates of my pool on the website, but I just don’t have the technical knowhow to do that. When Nu bot comes out with FC, we’ll definitely see more development in this area. I can try to make a quick section on FC on my website, but it’s almost guaranteed to disappoint.

@Cybnate we can do CRFC from FC by feeding the cost with a number proportional to the liquidity provided (up to a maximum target). It’s not hard to implement (at least in theory, from what Sam’s been saying I don’t think it should be a problem). It would give back the fixed reward - like behaviors of the pool (like reducing cost when the pool isn’t at or above target) while still maintaining a lot of fixed cost benefits (like asymmetric buy:sell rewards that adjust based on which way and how much the pool is out of balance).

I’m all for CRFC, I think it’s a nice and simple blend of FR and FC that gets the best of both worlds.

1 Like

all for CRFC too. I think it will save Nu costs in the long run.

Hard to tell as it is not clear how it works to me. What model would be followed when it is oversubscribed. Would everyone get less fixed reward according to their liquidity stake in the CRFC model. That would defy fixed reward and sounds almost like Dutch auction. I can see a hybrid model working fairly for all LPs without adding a lot of complexity. The same complexity as a Dutch auction? I hope I will be surprised positively.

When over target it operates exactly like fixed cost. There is no dutch auction. The only difficult part as far as coding is concerned is adding buy and sell together instead of treating them completely separately.

Just so I’ve got the CRFC idea straight.

  1. Pool operator sets an amount of NBT to payout per day.
  2. Liquidity providers get credited a percentage of the daily NBT dependant on what percentage of the buy or sell liquidity they provide
    (this is how ALP v2 currently works.)
  3. Pool operator also sets a target liquidity, similar to the current method.
  4. If the total liquidity provided is less than the target specified, the amount of the daily payout is scaled by the percentage of the total being provided. So each liquidity provider still gets their percentage of the daily payout but the amount payed out is less because the tragetted liquidity hasn’t been met.

If the above is right, I like it. It incentives providers to provide a targeted out of liquidity. It means that Nu can still benefit from under paying when targets aren’t hit. Its very easy logic to add to ALP v2. And lastly, it removes the potential for one of the attack vectors I had thought of where a bad actor blocks other providers while only providing a small amount of liquidity themselves, but claiming 100 percent of the reward.
I’ll have a look at including it in the new code later on.

Sounds like you got it. Basically, it’s like fixed reward except the ‘fixed rate’ is actually the weighted average of buy and sell, and it uses fixed cost when over target.

There is also one more input, the ideal ratio. Let’s call it 50:50 for now. Note that this is instead of individually stated targets and rates for buy and sell. You state the target, the cost, and the ideal ratio as 3 floats, and that’s it.

If the operator puts up 20 nbt with a 10,000 target, that’s a 0.2% expected rate. So now let’s say there’s only 100 nbt in buy and 400 nbt in sell. That’s 500 total liquidity, which is 5% of target, so only 20*.05=1 nbt is given out. That 1 nbt is split 50:50 between buy and sell, so the buy side earns 0.5/100=0.5% and sell earns 0.5/400=0.125%.

With the same operator but 10,000 buy and 2,500 sell:
Now the combined liquidity is over target, so we cap out at our 20 nbt. Split 50:50 that’s 10 nbt buy and 10 nbt sell. So buy side gets 0.1% and sell gets 0.4%.

In the above cases I used daily nbt numbers, but this would actually be implemented by the minute, like we’ve done in the past.

We could use a 75:25 buy:sell split and so that the 20 nbt at target are paid out as 15 to buy and 5 to sell and the system should still reach equilibrium (theoretically with 3x more buy than sell) with the network even if other pools are using 50:50 splits.

ALP v2 already has this to a certain extent. The operator can set the rewards per side to be off balance (https://alp-server.herokuapp.com/exchanges). All that would be needed is for the pool to dynamically alter the balance based on the amount of liquidity provided. The pool already reloads the config after each credit round (every minute) so it should be very easy to add the logic to do the maths based on the supplied liquidity.

So the next logical step is, what algorithm so we use to decide on the target balance of the sides? As mentioned previously, I aim to hook into external services (Alix). Do we have a feel for what balance would be best for Nu in certain circumstances?if we can start collecting data on this we can start adding it as logic to the server itself so that the balance rewards can pre-empt market moves in liquidity.

I’d like to see CRFC without asymmetric sides at first (i.e. the 50:50 split). However, in general the solution should have some asymptotic extrema (like no more asymmetric that 99:1 or something, never 100:0). The perfect solution is hard to find because it represents a complete understanding of the liquidity operations by shareholders. For example, @masterOfDisaster has spoken about how we want more buy liquidity in general than sell liquidity. That seems to point at a solution that leans toward buy side, but doesn’t quite specify how. This is something we’ll have to think about and discuss.

I actually have more to say on the split, but I’d really like to get the CRFC concept down with people here. I’ll make another thread for the split.

1 Like