Plugins

Custom plugins must be built to integrate yield-bearing tokens with the gauge system.

Plugins are smart contracts designed to incorporate yield-bearing assets into the Voting system. By doing so, users have the opportunity to deposit their assets into a Plugin and in return, earn OTOKEN rewards. The Plugin extracts the yield from these deposited assets and allocates it as a voting incentive to VTOKEN holders who voted for the Plugin. Its responsibilities encompass managing user deposits, withdrawals, updating balances in the associated Gauge contract for OTOKEN reward distribution, and channeling the harvested yield to its designated Bribe contract.

Developers should build custom plugins to integrate yield-bearing assets into the gauge system. Each different yield-bearing asset will likely require a different custom-built plugin. This section will discuss how developers can build plugins for a LilToken gauge system

IMPORTANT NOTICE

A bribe token should never be the same as an underlying token.

Rebase and fee on transfer tokens should not be used as an underlying token.

Glossary

underlying: The primary yield-bearing asset token. This is what users will deposit into the plugin. For example, the underlying token of a plugin could be LP-USDC/WETH, wstETH, sLP-USDC-DAI, or sDAI.

tokensInUnderlying: These are the tokens that are in the underlying token. For example, if the underlying is LP-USDC/WETH the tokensInUnderlying would be USDC and WETH. For the sDAI plugin could be DAI.

bribeTokens: These are the rewards that the yield-bearing underlying asset generates. For example, the LP-USDC/WETH could genereate swap fees and the yield would be USDC and WETH, these would be the bribeTokens. Or the LP-USDC/WETH could be deposited in a farm to earn CAKE. In this case, the bribeTokens would be CAKE.

protocol: This is the protocol that the plugin was built for. For example, if the plugin is a UniswapV2 LP then the protocol would be UniswapV2. If the plugin was sDAI then the protocol would be MakerDAO.

symbol: This is the symbol for the plugin that will appear on the UI. For example the symbol for a stable solidly USDC/DAI LP could be sLP-USDC/DAI. It is important to plan a symbol naming from the start. For example, what should be the symbol of that same solidly LP but deposited in a gauge to earn SOLID? Possibly sLP-USDC/DAI-G, where G stands for gauge. It doesn't matter as long as you are consistent.

Deposit/Withdraw Logic

Users will be depositing tokens into a plugin contract, which will allow them to earn OTOKEN rewards. The plugin contract is responsible for storing those deposits and can apply further logic to that. For example, one plugin could be for LP tokens, where LP tokens are deposited and just held in the plugin contract (earning swap fees). This is a straightforward implementation already handled by the inherited depositFor() function. Another type of plugin could be for LP tokens in a farm. In this scenario the user would deposit the LP tokens in the plugin and the plugin would then deposit those LP tokens in a farm contract to earn farming rewards.

The plugin must also contain the functionality for a user to withdraw their deposits. In the scenario where the LP tokens are held in the plugin contract the withdrawal is straightforward and already handled by the inherited withdrawFor() function. In the scenario where the plugin deposits the LP token into a farm, then logic for withdrawing from the farm would have to implemented.

ClaimAndDistribute Logic

The plugin is also responsible for claiming yield and distributing it to its bribe contract. In the case where an LP token is held in the plugin, the claimAndDistribute() function may just claim the swap fees and send them to the bribe contract. In the case where the LP token is in a farm, the claimAndDistribute() function would have to claim the reward token from the farm, then send it to the bribe contract.