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

Multiple Withdraw Intents Not Supported in "Pool" Contract #5

Open
florian-bellotti opened this issue Sep 11, 2024 · 3 comments
Open

Comments

@florian-bellotti
Copy link

The current pool contract only allows the creation of a single withdraw intent at a time per pool member. This is problematic for many staking protocols that require handling multiple staking requests or withdrawals concurrently, such as LST.

When a new exit_delegation_pool_intent is created, it automatically replaces any existing intent for that member, which limits the flexibility of interacting with the pool and makes it impossible to withdraw fund from a contract that manages staking. This limitation hinders protocols where members may need to initiate multiple withdrawal intents simultaneously for different stakes or in different contexts.

In contrast, the remove_from_delegation_pool_intent function in the staking contract allows managing multiple intents per staker by associating each intent with a unique identifier. The pool contract could benefit from implementing a similar mechanism, enabling multiple intents per pool member and enhancing usability for more advanced staking operations.

@natan-granit
Copy link

Your statement is correct per pool member, but as an LST you can have multiple pool members for the same Staker or even for different Stakers. Would this work as a work-around?

@florian-bellotti
Copy link
Author

The LST would act as a member of the pool, and all user assets held by the LST would be managed through this single membership. If the LST were to use the user's address instead of its own, users could potentially exit the pool while retaining their LST.

@natan-granit
Copy link

I understand, and still the LST can manage several addresses as part of the liquidity management. There is also 21 days delay to manage.
Additionally, this override mechanism actually helps in if after a period when lots of users asked to get STRK for LST changed to a period when lots of users want LST for STRK.
I would love to have a call and discuss workarounds.

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

2 participants