LP incentives

[z0r0z]

we should allow anyone to add reward tokens for LP-ng to a given Pool ID

[shortdoom]

trying out few concepts and in need for clarification

reward as, user receives N tokensN when he provided liquidity to pool ID 1, where tokenN is different token than the ones received from that pool.

so, should this be understood as integrated token farming inside of a pool(s)? same as locking LP-tokens on some DeFi project farm in exchange for some % of governance/utility tokens?

what I currently designed and coded in some part uses above assumption and... I want to follow factory pattern (similar to Uni's V2&V3) to allow creation of rewards Vault after pool is created (save gas on pool creation, gives optionality for rewards). there could be infinite amount of reward vaults for any pool id (protocol deployed, user deployed, 3rd deployed). deployer of reward vault would have control over it's math (responsibility to verify lies on user, but reward vaults are separated from pool so low risk for Helios). users would be able to claim from reward vault based on amount of their LP tokens in given pool. New standard can be also used for that (EIP-4626)

do I get it right?

[z0r0z]

excellent stuff. So yes, the first part is quite simple and as you suggested. Anyone should be able to provide a reward token for adding liquidity to a pool. And similar to sushi masterChef, this might be an increasing reward based on time locked into LP.

Rather than create separate vault contracts it might be simpler to just have an array mapping on top of each pool ID, with each array index corresponding to a struct that contains reward logic (amount...token....time), with corresponding tracking to users.

Related, I did a mock of how erc4626 might operate on top of 1155 token, so we might consider combining the Helios concept of 1155 base for AMM as well as the reward vaults.

[shortdoom]

Slightly confused PoC: https://github.com/shortdoom/Helios/blob/2c8a2bf0ef86772ad440aa028f2e2eac08628056/contracts/Helios.sol#L106

I left some lax commentary in natspec regarding current functions, to-do's and things which need some design decisions.

Helios.sol is extended with Reward Vaults logic. This pushed lock-in/unlock mechanism into HeliosERC1155 (LP-tokens) as the only viable solution if we decide to incentivize staking rewards. It's not something I am fan of but it happened. Each Reward Vault has it's own corresponding Reward Token deployed upon creation of the Reward Vault. In PoC above, Reward Token is ERC20 implementation from solmate with ability to cap totalSupply upon creation and mints access restricted to Helios.sol. Expectation is that user can provide his math/logic for distribution of Reward Tokens. Capping totalSupply is just one of the options (see natspec). Locking/depositing LP into Reward Vault is tracked by block.timestamp and amount in HeliosERC1155.sol under positions mapping. Expectation is that user provided math/logic will want to use those variables for Reward Token calculations. Reward Tokens calculations are to be implemented inside of previewWithdraw() function.

I think it's one of the roads, but seems a little bloated. I wanted to keep a balance between modularity (Reward Vault creators having flexibility with rewards logic) and trust (Reward Vault creators making malicious Vaults). I think there is a lot of to cut-from here.

Gas-wise, creating Vault is expensive (0.09 eth at 100 gwei). However deposits (0.015) and withdraws (0.007) seem to be around similar gas cost as some existing staking vaults in the wild. This is by no means finished implementation but discussion started.

Contracts of interest: Helios.sol, HeliosERC1155.sol + RewardToken.sol
Tests are only provided in form of successfully executed calls to implemented functions.

HH Tests output: