You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Liquidity providers get turbo fusions sometimes and may want to rate limit.
If they rate limit by turning off fusion entirely then liquidity is unfortunately lower. Whether this happens manually or automatically, it sucks.
We want liquidity providers to be always available to help make big fusions even bigger. Yet also make them happy by having rate limiting.
If clients can specify to the server 'I only want to participate in fusions txes with at least N tx components' (or pools with N fusion components), then they can vary this limit over time to rate limit the fusions they are involved in. When a fusion happens they bump up the limit, and if they are waiting a long time without action they can lower the limit.
This ought to lead to a critical mass effect amongst any liquidity providers. They can set their minimum to a pretty high point, corresponding to, say, 400 fusion components. If there are multiple liquidity providers then the server can notice this and bring them in. For example let's say there are 8 such liquidity providers who would altogether bring 200 fusion components if included. Then only 200 fusion components from regular folks would be needed to trigger this.
This also gives a natural repulsion effect if there are too many liquidity providers -- if they start to fuse constantly with each other then they will dynamically back off. But if organic demand comes in, there will be a ton of them in waiting, ready to make giant fusions.
The text was updated successfully, but these errors were encountered:
Provided it's 1 dimensional minimum, it's not hard for the server to calculate the critical massing effect. Just calculate cumulative sum "if I have at least N components then I have N available to be picked from".
Note also that clients ought to indicate a second lower minimum "please kick me out of the fusion round if less than M fusion components". While they can leave voluntarily, it is better for privacy reasons if the server itself can do this automatically. Again, this hopefully can lead to a critical mass effect for shutting down fusion that have gone rotten, without the server having to leak tx component info.
Right now we have a few problems:
If clients can specify to the server 'I only want to participate in fusions txes with at least N tx components' (or pools with N fusion components), then they can vary this limit over time to rate limit the fusions they are involved in. When a fusion happens they bump up the limit, and if they are waiting a long time without action they can lower the limit.
This ought to lead to a critical mass effect amongst any liquidity providers. They can set their minimum to a pretty high point, corresponding to, say, 400 fusion components. If there are multiple liquidity providers then the server can notice this and bring them in. For example let's say there are 8 such liquidity providers who would altogether bring 200 fusion components if included. Then only 200 fusion components from regular folks would be needed to trigger this.
This also gives a natural repulsion effect if there are too many liquidity providers -- if they start to fuse constantly with each other then they will dynamically back off. But if organic demand comes in, there will be a ton of them in waiting, ready to make giant fusions.
The text was updated successfully, but these errors were encountered: