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

Liquidity Pools
#61

Is there any reason to know your restart time precisely? If not I can implement that when I implement the fill factor stuff from that other thread.

#62

No.
It’s unlikely that even two people have the same restart period and it should be expected that way more than two LPs are active at an ALP.
Orders are up within seconds after a bot restart (depending on the synchronization time).
To have one LP alone on the pool, it’s required that all other LPs are restarting their bots simultaneously.
While their orders aren’t up, one LP did get all the reward.
If we are still thinking about capping the reward (in percent), this wouldn’t even be a big deal in case it happened - which is highly unlikely.

#63

Why do you say unlikely? If everyone uses defaults and the server syncs the clients up it can be almost a certainty.

#64

The server doesn’t know at what point of time the bot was started, right?
And the restart is a setting in the bot’s “pool conf”.
With a restart period of 0.25 (=15 minutes) in the conf file the chance to have two bots restart at the same time is 1/15 (if you consider only full minutes).
To have 3 bots restart at the same time (restart period of 0.25 for all), it’s 1/152, or in general for a number n of bots: 1/15n-1.
For n bots and a restart period of x minutes it’s a chance of 1/xn-1 to have them restart at the same time.
If the bots don’t have the same restart period it gets even more fun :slight_smile:
That’s why I called it unlikely :wink:

#65

Pybot runs self.sync() before setting the reset_timer=curtime. That means first all the clients sync up, then they start their reset timers.

Edit: But that should only sync within the minute. I think you should still be correct about it being 1/15 to have 2 bots restart at the same time. Maybe it’s not a big deal.

What is the maximum rate you think I should impose? We can take the 750% for 1 NBT and divide by an ideal minimum LP, like say 10 NBT. Then, the maximum rate should be 75%.

#66

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.

#67

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.

#68

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.

1 Like
#69

It’s surely a step to the right direction.

#70

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.

#71

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.

1 Like
#72

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.

#73

@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)

Three roles that need to be filled by shareholders
#74

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

#75

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.

#76

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.

#77

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.

Got it now. :sweat_smile:

#78

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.

1 Like
#79

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 :slight_smile:

#80

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.

2 Likes