feat: liquidity mining #250
Conversation
enthusiastmartin
left a comment
enthusiastmartin
left a comment
There was a problem hiding this comment.
Just initial quick review.
I have a feeling that there is a mixture of concrete types and generic types which however expect traits such From and Into to be implement by that type ( eg. balance and currency).
If it is defined like that - there are not many options for types anyways and I would consider to set balance and currency types to u128, or u32 respectively.
This approach will make certain things easier to do - but it limits the "re-use" of the pallet ( but i dont think that's an issue and we should not be worries about that).
eg. XYK is currently done in similar way where balance and currency id is se to u128 and u32.
| ); | ||
|
|
||
| // update global pool accumulated RPZ | ||
| let now_period = Self::get_now_period(global_pool.blocks_per_period)?; |
|
I've reviewed the core functionality so far only naming nitpicks that can also be addressed later (I'd rather do now since it's probably not hard). I'll continue with logic / tests and benchmarks tmrw |
| /// Liquidity pool yield farm details. | ||
| #[pallet::storage] | ||
| #[pallet::getter(fn liquidity_pool)] | ||
| type LiquidityPoolData<T: Config> = StorageDoubleMap< |
There was a problem hiding this comment.
I would personally set some constants for max amount of pools (any map really) and then benchmark against that max number since maps/double maps might take longer to read/write when there is a lot of entries. Something like 255 should be sufficient.
|
It should be checked if nft class id is less than ReserveClassIdUpTo from the NFT pallet |
Description
Implementation of liquidity mining pallet
Related Issue
#242