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

[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.

[mhps]

Is there any other fixed cost pool besides nupond nbt/btc?

[woolly_sammoth]

Not to my knowledge. The new ALP server software that is currently being worked on will use this model though.

inuitwallet/ALP-Server

I’ve been working on getting automated test coverage for the software, little way to go yet. The work on NuBot to integrate this into the web UI is taking place.

[mhps]

With buyside reduced to 0 for 1.5% spread, why don’'t we deploy fixed cost (FC) scheme on the buy side?

Suppose the existing spread is 5.5% (0.75 on the sell and 4.75 on the buy) and our target is 1.5% (0.75% on both sides).

If we offer 100 NBt per day FC reward on the buy side, then how much liquidity we will attract to make it even? This :

Every time $N on the buy side BTC get bought, the LP will buy it back from the 4.75% buy wall and put it back at 0.75% buy side in order to get reward, incurring 4% loss. 100NBT will sustain 100/4% = 2500 NBT trade volume a day. Whoever makes the balancing will get to split the reward so I expect competition will bring more volume. (In a deleted version of this post I try to assume how many balances could happen a day. I think it is too unreliable.)

Is this worth to try? I think so because We are paying 140NBT a day for 0 buy side at 1.5% spread!

@woolly_sammoth @Cybnate @Nagalim and other pool runners please let me know if I explaned it clearly.

[masterOfDisaster]

That is what we need now!
FC with an increased offset for starters is a good way to revive the liquidity provision.

[Passed] 1% Maximum Spread for ALP/MLP, Above 1% Allowed for Nu Funded Liquidity Operations (e.g. Gateways)

The economically improved approach is market awareness, or more precisely: market aware offsets combined with parametric order books for all pairs, except NBT/USD.

It’s following that road - the 3% need to be replaced, though:

Current Liquidity

To revive the liquidity provision it would make sense to close the spread with ALP, by letting them start liquidity provision at a buyside offset of say 3% and letting them tighten the offset until the trade volume is on the level you want to have while still being able to support both sides.Jumping in at 0.5% offset is not the best idea. Testing the waters, reducing the offset in steps would be a way to recover.