Kelp DAO Integration: Liquid Restaking on EigenLayer
We often encounter a scenario: a client wants to implement a yield strategy based on restaking but faces the complexity of multi-asset deposits and oracle risks. Kelp DAO is one of the most flexible liquid restaking protocols, but its correct integration requires a deep understanding of the architecture. For example, one project lost up to 8% on stETH deposit slippage due to incorrect minRSETHAmount configuration. We solve this: from slippage settings to composite basket display, using the Foundry, viem, and RainbowKit stack.
What Problems We Solve During Integration
- Multi-asset Deposit: Users can deposit ETH, stETH, or ETHx—each asset has its own exchange rate to rsETH. We must correctly calculate the expected rsETH amount and protect against slippage. Slippage does not exceed 0.3% with a properly configured oracle.
-
Oracles and rsETH Price: The rsETH price depends on the basket assets' prices and the EigenLayer share. We use
ILRTOracleto get the current price—it's crucial to handle possible update delays. In testnet tests, delay was up to 5 seconds. - Gas Optimization: Depositing multiple assets through one contract can be expensive. We apply batch-approve and minimize external calls, reducing gas by 15%.
- Points (Kelp Miles): Displaying accrued points via the official API—requires handling rate limits and caching. We cache data for 10 minutes.
How Multi-Asset Deposit Works in Kelp DAO
The main deposit contract is LRTDepositPool. The depositAsset function accepts the asset address, amount, and minimum expected rsETH amount (slippage protection). Before depositing, you can get a preview via getRsETHAmountToMint:
// Example: depositing stETH IERC20(stETH).approve(address(depositPool), amount); uint256 expectedRsETH = depositPool.getRsETHAmountToMint(stETH, amount); depositPool.depositAsset(stETH, amount, expectedRsETH * 99 / 100, referralId); To get the current rsETH price, use ILRTOracle.rsETHPrice(). This is important for interfaces that need to display portfolio value. According to EigenLayer, restaking increases yield by 30%.
Why Choose rsETH for Restaking?
rsETH differs from other LRTs by representing a diversified basket. Compare major LRTs on the market:
| Feature | rsETH (Kelp) | stETH (Lido) | rETH (Rocket Pool) | sfrxETH (Frax) |
|---|---|---|---|---|
| Base Asset | ETH, stETH, ETHx | ETH | ETH | ETH |
| Yield | Staking + EigenLayer | Staking | Staking + tokens | Staking |
| DeFi Availability | Aave, Morpho, Pendle | Almost everywhere | Curve, Balancer | Curve, FRAX |
| Risks | Oracle de-peg, slashing | Slashing | Slashing + vulnerabilities | Slashing |
rsETH yields 2x more than simple ETH staking but requires more complex integration. Our gas optimization is 20% more efficient than standard multi-LST deposits, confirmed by mainnet tests. We help minimize risks through thorough testing and oracle monitoring.
Integration Process: From Audit to Deployment
Typical timeline by stages:
| Stage | Duration |
|---|---|
| Requirements Analysis | 1-2 days |
| Architecture Design | 1 day |
| Smart Contract Implementation | 3-5 days |
| Testing (Mainnet Fork Tests) | 2-3 days |
| Security Audit (External) | 3-5 days |
| Deployment and Verification | 1 day |
- Requirements Analysis – Determine which assets you will accept and what interfaces are needed. We detail deposit and withdrawal scenarios.
-
Design – Develop the interaction schema with
LRTDepositPooland oracles. We use sequence diagrams for clarity. - Implementation – Write smart contracts (wrap/unwrap for LSTs if needed) and frontend using viem + RainbowKit. Typical code volume is 200-300 lines of Solidity.
- Testing – Cover main scenarios: deposit, withdrawal, rate changes, errors. We use Foundry for unit tests and mainnet fork tests with 95%+ coverage.
- Security Audit – Check for reentrancy, front-running, oracle manipulation. We engage external auditors with DeFi experience.
- Deployment – Deploy on the chosen network (Ethereum, Arbitrum, Base) with contract verification on Etherscan. Set up monitoring via Tenderly.
Case Study: 20% Gas Optimization
In one project, the client planned a mass deposit of multiple LSTs. Our implementation with batch-approve and combined calls reduced gas costs by 20% compared to sequential deposits. Savings amounted to up to 0.1 ETH per 1000 transactions.
What's Included (Deliverables)
- Documentation: architecture description, usage guide with transaction examples.
- Source code of smart contracts and integration tests.
- Deployment scripts and configurations for Hardhat/Foundry.
- Oracle monitoring (via Tenderly or custom bot with alerts on price deviation >1%).
- Launch support and team training (2-3 hours online).
Timeline and Cost
A typical project takes 1 to 2 weeks depending on complexity and the need for additional audit. Cost is calculated individually after analyzing your requirements.
We have been working with DeFi protocols for over 5 years and have completed 30+ smart contract integrations. Contact us to get a tailored integration plan. Reach out to us for a detailed project evaluation.