Separate Handling of LRT Variants in liquifier.sol
Opened this issue · 0 comments
ByungHeonLEE commented
TL;DR
The current implementation of liquifier.sol
accepts all variants of LRT tokens indiscriminately. While this approach simplifies interactions, it potentially introduces risks and inefficiencies.
Concerns
1. Risk of Storage Mapping Confusion and Dependency Issues
- The liquifier.sol contract is upgradable, which introduces a risk of storage mapping confusion during upgrades. This confusion could lead to vulnerabilities if not managed carefully.
- Dependency management becomes more complex
2. Cost Implications of the Current Approach
- A separate approach, although initially more costly due to deployment expenses, could reduce the frequency of required upgrades and test regarding dependency, not new features
Proposal for Separation
I propose that separate the contract with handling of each LRT in the liquifier.sol
contract.
Advantages
- Enhanced Security: Reduce the risk of storage mapping confusion and make the contract's operation more transparent and safer during upgrades.
- Reduced operation costs: Each LRT variant would be less dependent on the others, making the system as a whole more modular and easier to upgrade in parts without significant affects.
- (Potential) Strategical implementation with various combination of LRTs: This modularity leads to flexible approach and combining each others with the same category.
e.g. Combine LRT with Pendle / Combine LRT with specific L2s
I welcome feedback, suggestions, and further discussions on this proposal from the community and team :)