Fixed total payout for liquidity providers to enhance liquidity security and pool operation

[masterOfDisaster]

Ok, so if all bots use the same timers they have the same restart period and are down and up at the same time, right?
that would mean with different timers those who have the longer intervals receive a little bit more compensation, because their bot is up while others are restarting.

[Nagalim]

Sorry, the edit confused this thread. I think you’re correct that syncing isn’t a big deal because the sync only happens within the minute and setting a long enough reset timer should make simultaneous restarts very rare.

[Nagalim]

With nud getliquiditydetails I can pretty easily tie liquidity in the network into compensation. Because of the possibility for the reported liquidity to be invalid, we would want to breakdown the liquidity more like this:
5 nbt/month sell side
5 nbt/month buy side
5 nbt/month flexible
The flexible portion would be used such that if the network is in total 80% sell and 20% buy, we would award a total of 6 nbt buy and 9 nbt sell out of our 15 nbt/month.

This should be controversial. Paying more to sell side when the network is in trouble? Am I nuts? Well, we are currently doing that to an extreme with fixed reward. This is a hybrid fixed reward/fixed cost model that I am proposing here.

[mhps]

It’s surely a step to the right direction.

[cryptog]

There are no targets or % rates. Competition is forced by the very concept of fixed cost in a much more aggressive way than on fixed reward pools.

What is the difference between fixed cost and fixed reward? Is it from the perspective of the network?
To me ALPPs provide liquidity with a fixed cost from the perspective of the network already.

[Nagalim]

Fixed cost fixes how much an operation costs shareholders. Fixed reward fixes how much an operation rewards participants. With fixed cost the operator specifies an nbt/day amount. With fixed reward the operator specifies rates and targets.

[Nagalim]

I have moved this server over to the BTC pool on Bter. It seems to be working well. It still kills itself every 24 hours because I don’t have Nud up. I also have not added the flex funds yet, I’m still considering the best approach for that.

[Nagalim]

@willy The way this would look for parametric order book (POB) is that instead of asking people to place orders at certain prices to get certain rates, the operator would state that it’s giving out a certain amount of NBT at a certain rate to anyone willing to put an order up at a certain price, letting all participants share the NBT proportionally to how much they participated. (I might not fully get POB though)

[cryptog]

Just to clarify things, in a fixed total payout scheme, as a liquidity provider participant, I will have a guaranteed fixed reward per day.

[Nagalim]

Noooope. That would be the ‘fixed reward’ system that already exists. Your reward will be based on how many other people are providing with you. The cost to shareholders is the thing that is fixed, which is not something you see directly as an LP. As an LP, you should expect higher reward when you are providing the bulk of the liquidity on a single side, despite the actual total liquidity that is being provided.

[masterOfDisaster]

Think of fixed cost compensation like PoW mining BTC - there’s a constant (PoW: coinbase tx; here: compensation per time) reward for which all participants fight for. They get rewarded based on the resources they verifiably invest.

If the fixed cost model proves successful it might end up with different “pools” (1 ALP, 2 NuBots…) fighting for a compensation that Nu pays for liquidity on a particular exchange.

[cryptog]

The comparison with BTC’s mining is very useful.
In fact, FC ALP’s compensation scheme could be the exact equivalent of it in the world of Nu’s liquidity provision competition.

Your reward will be based on how many other people are providing with you

Got it now.

[Nagalim]

There are 2 improvements that we should seriously consider. Both of these ‘improvements’ are actually a way of blending fixed cost with fixed reward:

1. Tiered costs. If a side has <100 NBT, pay x/day, if <1000 NBT pay y/day, otherwise pay the full amount z/day. This will decrease incentives to fix a broken peg, but they will also reduce shareholder costs when a peg is broken. We might also consider applying the tiers if either side has a broken peg, rather than just one side. That would make it a cooperative model.

2. Split pay. Pay (x+y)/day buy and (x+z)/day sell, where y+z=constant and y/z=ratio of sell:buy liquidity reported to the network for tier 1.

[zoro]

by ‘broken peg’ you mean a very thin wall, i assume.
i would porpose to make it a little more complex, to pay more for a tighter spread,
but the code could be hell

[Nagalim]

Broken peg could be thin wall or no wall. The argument is that if there is no buy side liquidity we should not be paying sell side as much.

Spread dependence would have to come after parametric orderbook.

[Nagalim]

@zoro You seem interested, what are your thoughts on this:

If LP on one or both sides is < 100 NBT, payout 1/10 rates.
If LP is <1,000 NBT on either or both sides, payout 1/2 rates.

[masterOfDisaster]

These steps make it very attractive to provide at least a little bit more funds than the threshold of taking the next step.
Providing 10 NBT liquidity is so much better than providing 99.
And providing 1000 NBT is waaaaay better than providing 999.
Nice!

[Nagalim]

This also motivates someone with a lot of sellside liquidity to make sure there is buy side liquidity. For example, someone has 10,000 sell NBT and there is only 999 buy NBT; they can double their daily rate just by making sure there is 1 more NBT of buy side. It doesn’t even have to be theirs and they would profit off of it. This gives them incentive to, say, post on the forum that the peg is broken.

[zoro]

i was thinking of an analogous payment proportional to the wall size, following the simple function f(x)=x

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcR2oUuM5NR1LOgCtThKX0pXoGMwBryRViPwhqlQVo9tduQ0_6qV

but threshold may work good as well.

[Nagalim]

simple f(x)=x is fixed reward if all participants are in cooperation. We would be forced to impose targets with dutch auction again to generate competition and we’d be right back where we started.

By applying tiers we can still make the statement that as long as at least 1,000 NBT is on both buy and sell walls the pool will pay a fixed total cost to participants of y NBT/day.