Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

idea: client dynamic choosiness #17

Open
markblundeberg opened this issue Feb 26, 2020 · 1 comment
Open

idea: client dynamic choosiness #17

markblundeberg opened this issue Feb 26, 2020 · 1 comment

Comments

@markblundeberg
Copy link
Owner

Right now we have a few problems:

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

@markblundeberg
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant