Putting in more liquidity decreases your total payout for fixed cost, this is always true. With infinite steps, putting in liquidity proportionally on both sides while the pool is under target will actually keep the reward rate exactly the same, like a fixed reward pool. How would this cause oscillation?
Use the example above and double the LP on both sides. The reward is now 8 nbt/day and the rewards rates (%) all stay the same.
Infinite steps are rather a theoretical model than practically possible.
You will have a limited number of steps.
LPs that target a minimum compensation rate might create and cancel orders based on the current situation in between steps.
If future ALP clients have configuration parameters to adjust the liquidity volume to the current compensation rate, I fear this will lead to oscillation.
This is already an issue with fixed cost and is actually somewhat mitigated by the model I’m proposing here. This model helps this problem, it doesn’t make it worse.
If you say so, I tend to believe it
I should have spent more thoughts about it instead of creating uncertainty.
I will digest this topic a bit more before writing more nonsense.
Nah, thought and discussion is vital, you know that better than most.
Let’s focus on one side. There’s 10 nbt/day (fixed) and 750 nbt in the pool. You have your bot set to put up 500 nbt if the rate is >1% and take down 500 if the rate is <1%. As you can see, the bot begins oscillating.
Yes, of course there are ways to help with this. However, doing the combined-reward-fixed-cost (CRFC, I just made that up) model does not make this problem worse. This problem is generated because a change in liquidity provided causes a change in reward percentage. CRFC actually reduces this effect (the same change in LP would cause a smaller change in % reward because the fixed-cost amount changes some).
FR - Fixed Reward. Uses a constant % up to a target, then uses dutch auction.
FC - Fixed Cost. Uses a constant NBT/day with no target. % can be calculated from cost and liquidity provided.
CRFC - Combined Reward Fixed Cost. Uses a NBT/day proportional to the combined liquidity on both sides, maxing out at a target. If sides are held proportional (i.e. 50:50 or 75:25) this is identical to FR but using FC at the target instead of dutch auction.
Asymmetric Pool - varying the key constants separately for buy vrs sell side
Flex - varying the asymmetry of the pool based on the liquidity in the network.
I feel FR is suited to a situation in which you want a certain minimal return on your money against a certain risk. And I think this risk is the risk of exchange default.
Ex: You re willing to get at least x% a day in Polo from your funds but not less, otherwise you asses that it is not worth the risk of Polo.
I fee FR is well suite to centralized exchanges.
Conversely, I feel FC is suited to a situation in which you really do not care so much about a certain minimal return (you are willing to see how it goes and see in practice how many participants are competing for the reward) but you know that you will get some. Of course you can walk away if your bot detects that you do not get a certain minimuml but I interpret that in FC you do not specify a rate, do you?
In any case, I feel FC is well suited to a decentralized exchange in which the default risk is in practice 0.
In other words, I think a pool running at a decentralized exchange will offer much less rewards and providers will be fine with that and as long as they get something out of their money, they will be willing to leave it in the pool, and FC deals well with that since it will give your some rewards regardless of the competition.
For FR you say that they only participate if the pool is under target. If you assume a similar concept on FC pools, that the person walks away if the pool isn’t below a target, you can get similar results. For example, if there is less than 5000 nbt on a side in either NuPond pool, you know the rate will be >0.2%. So you can walk away if the liquidity exceeds this in a similar manner. That the FC pool causes more movement amongst custodians can be considered a boon, as it benefits pro-peg gaming of the pools to try to balance inter-exchange as best you can.
I’d like to see CRFC implemented. Sam’s stuff allows for all possible dynamics near as I can tell.
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.
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.
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.
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.
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.