Yes Flash-Loan-Pool would be a type of public Pool that would have weighted fee voting shares. I just used it as an example because it was the first hing that came to mind, will have to think about how this applies to protocol based amms

Another shared governance scenario that I was thinking about for a longer time would be a type of Pool where users can lock up assets up to a specific date and after that date if at least 50% of LP-token holders and 50% of LP-tokens agree the funds will be released to a beneficiary. If a quorum is not reached until an end date the assets can be reclaimed by their original holders. This would allow some type of shared community investment/funding (I am not sure about the legal side of this). You could then also do some type of release rounds where x% of assets get released. I have done no research yet if the community would even be interested in something like that. For example a community could fund the development of a video game using that and their next round of fund/ will only be released if milestones are reached and agreed on in a quorum.

I think a lot of what i think about lately can be solved using hooks but not sure if those ever come to main :D

I think flash loans would only be useful if aams have experienced single side deposits and you can then use this imbalance to balance out all of the aams that have related pairs.

For example:

XRP-Flash-Loan-Pool

XRP/USDX
USDX/KUI
KUI/XRP

For example a lot of KUI are single side deposited into the USDX/KUI pair, you could then flash-loan and get XRP to trade for USDX and put those USDX back into the USDX/KUI pair while taking out KUI to swap it back to XRP.

I hope I didn't miss something there... :D

Thanks @xVet !

The idea is that a PoolDelegate is the pool's owner, and thus, the PoolDelegateID is not changeable. However, now that I think about it, there is no "delegacy" in this case.

Do you think it would be better to have a separate PoolOwner and PoolDelegate where the PoolOwner has all permissions of the Delegate, including deleting the pool and changing the PoolDelegate. Whereas the PoolDelegate may only perform protocol specific operations?

Exactly! I think it makes sense to change the name to PoolOwner and give the owner AccountID the ability to do a AccountSet Flag asfPoolDelegate for delegating functionality to a delegate.

Thoughts on that ?

I think it makes sense to change the name to PoolOwner and give the owner AccountID the ability to do a AccountSet Flag asfPoolDelegate for delegating functionality to a delegate.

I don't quite understand the need for the flag. Do you mean something similar to NFTokenMinter? If so, IMO in this case that should be on the pool and not on the account.

Exactly! I think it makes sense to change the name to PoolOwner and give the owner AccountID the ability to do an AccountSet Flag asfPoolDelegate for delegating functionality to a delegate.

If we introduce a second entity, PoolOwner, I agree with 1). However, I'm not sure about the asfPoolDelegate flag. I think the Pool should be self-contained. The spec should not introduce Pool specific changes to other ledger entries. That is primarily to minimize coupling with other ledger entries. By minimizing coupling, we make the ledger entry easier to change. Or that is the hope at least.

That said, we can achieve the same functionality by introducing two fields, PoolDelegate and PoolOwner to the Pool object. What do you think about that?