Question about swap code example in move-examples

[lumos42]

I have some questions about swap example using FungibleAsset.

In the function create_lp_token, it says - "We don't enable automatic primary store creation because we need LPs to call into this module for transfers so the fees accounting can be updated correctly".

1. Why don't we want primary store enabled fungible asset for LP tokens? I don't understand how it will affect fee accounting.
2. Even though it says that we don't want primary store, it goes on to call the function create_primary_store_enabled_fungible_asset which implies that it has the primary store enabled. Is this intended, or a mistake in the example?
3. How should I decide whether to enable primary store or not?
4. In the function ensure_lp_token_store, it checks for the primary store. If LP tokens are meant to be in primary store, then why create a new store here?

[kshitijc1506]

Explanation of the First Three Questions

This is a weird one... I'm not entirely sure what it means by "We don't enable automatic primary store creation". We still use primary stores for LP tokens in the module. LP tokens will be stored in liqudity provider's primary stores, based on the current implementation in this example.

As for "because we need LPs to call into this module for transfers so the fees accounting can be updated correctly", you can refer to this part of the code. Basically, we want liquidity providers to call directly into the liquidity_pool.move module for transfers, instead of calling into pfs::transfer or fa::transfer. This is because in our transfer function, we defined these two operations:

1. Once they call transfer in our module, we freeze their primary store so they can't call pfs/fa::transfer later. This can only be bypassed through our module, as we need the TransferRef to bypass a frozen store.
2. We call update_claimable_fees to update the fees.

New Solution

Although, we now have dispatchable FA, so this problem is irrelevant since we can just implement deposit/withdraw overrides and not have to worry about liquidity providers calling into pfs::transfer. As even pfs::transfer will route through our defined override logic. However, when override functions are used, fa::deposit/withdraw don't work.

Explanation of the Fourth Question

I'm not sure, but this part looks like a mistake to me. Since, we're not using the store object returned by create_store anywhere. We do however, create stores within the LiquidityPool resource to store the actual tokens (i.e. APT/USDC) inside it, alongside separate stores for the accumulated fees.

Hope that helps, please let me know if you have any follow ups.

[lumos42]

Thank you for the explanation! I have another question from the same example, but it's a bit unrelated.

I understand that we can convert from Object<X> to Object<Y> by using object::convert function, but in the example, it converts without explicitly stating the output type, and it still works. How does it work?

[kshitijc1506]

I believe the compiler can infer the type since the function returns Object<LiquidityPool>.

[lumos42]

Got it, thank you 🙏