Multiple Withdraw Intents Not Supported in "Pool" Contract

[florian-bellotti]

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]

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]

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]

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.

[byteZorvin]

users could potentially exit the pool while retaining their LST.

I guess this can be solved by deploying a new contract for each user and make this contract the pool member. When the user tries to exit the pool they call this middleware contract first where one could burn the lst as well.

But this poses another issue that if the user wants to transfer the lst tokens(partially/fully), how would the pool membership be transferred then, as that requires exit_pool intent flow followed by add_to_pool which will take at least 21 days.