feat: add velkonix yield adapter (Aave V3 fork on MegaETH)#2768
feat: add velkonix yield adapter (Aave V3 fork on MegaETH)#2768CryptoBetmen wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughThis PR adds a new yield adaptor for Velkonix at src/adaptors/velkonix/index.js. It fetches reserve and aToken data from a protocol data provider contract on the megaeth chain, computes TVL, borrow, and supply USD values, derives APY and LTV metrics, and exports an apy function with associated metadata. ChangesVelkonix Adaptor
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
The velkonix adapter exports pools: Test Suites: 1 passed, 1 total |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/adaptors/velkonix/index.js (1)
72-80: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winScale underlying amounts with underlying token decimals.
Line 77 fetches decimals from the aToken, but Lines 101-104 scale underlying balances/debts. Aave aTokens usually mirror underlying decimals, but using
reserveTokensavoids silent mis-scaling if this fork diverges.Proposed change
- const underlyingDecimals = ( + const underlyingDecimals = ( await sdk.api.abi.multiCall({ chain: CHAIN, abi: 'erc20:decimals', - calls: aTokens.map((t) => ({ - target: t.tokenAddress, + calls: reserveTokens.map((t) => ({ + target: t.tokenAddress, })), }) ).output.map((o) => o.output);🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/adaptors/velkonix/index.js` around lines 72 - 80, The underlying amount scaling in the Velkonix adapter is using decimals fetched from the aToken, which can silently mis-scale balances if the fork’s aToken decimals differ from the underlying asset. Update the decimal lookup in the aToken processing flow to use the reserve/underlying token entries from the existing token data, and make sure the scaling applied later to underlying balances and debts uses those underlying token decimals consistently in the Velkonix index logic.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/adaptors/velkonix/index.js`:
- Around line 101-111: The liquidity calculation in the Velkonix adaptor is
using idle cash for tvlUsd, which underreports TVL once borrowing exists. In the
pricing loop in index.js, update the tvlUsd assignment to use total supplied
liquidity (the existing totalSupplyUsd derived from underlying balances plus
total borrow) and keep the idle/capped liquidity logic only for
availableBorrowUsd. Make the same adjustment anywhere else the same pattern
appears, including the later block referenced in the review, so tvlUsd
consistently represents supplied liquidity rather than available cash.
---
Nitpick comments:
In `@src/adaptors/velkonix/index.js`:
- Around line 72-80: The underlying amount scaling in the Velkonix adapter is
using decimals fetched from the aToken, which can silently mis-scale balances if
the fork’s aToken decimals differ from the underlying asset. Update the decimal
lookup in the aToken processing flow to use the reserve/underlying token entries
from the existing token data, and make sure the scaling applied later to
underlying balances and debts uses those underlying token decimals consistently
in the Velkonix index logic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 8e1a1ee1-46cb-479e-9f19-8ef994eed3ad
📒 Files selected for processing (1)
src/adaptors/velkonix/index.js
| const tvlUsd = toTokenAmount(underlyingBalances[i]) * price; | ||
| const totalBorrow = | ||
| BigInt(p.totalStableDebt) + BigInt(p.totalVariableDebt); | ||
| const totalBorrowUsd = toTokenAmount(totalBorrow) * price; | ||
| const totalSupplyUsd = tvlUsd + totalBorrowUsd; | ||
|
|
||
| const borrowCap = Number(poolsReserveCaps[i].borrowCap); | ||
| const borrowCapUsd = borrowCap * price; | ||
| const availableBorrowUsd = borrowCap | ||
| ? Math.max(Math.min(tvlUsd, borrowCapUsd - totalBorrowUsd), 0) | ||
| : tvlUsd; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Report supplied liquidity as tvlUsd, not only idle liquidity.
Line 101 currently makes tvlUsd equal the underlying cash sitting in the aToken contract. Once users borrow, that underreports pool TVL by the borrowed amount. Keep available liquidity separate for availableBorrowUsd, and set tvlUsd from total supplied liquidity.
Proposed change
- const tvlUsd = toTokenAmount(underlyingBalances[i]) * price;
+ const availableLiquidityUsd =
+ toTokenAmount(underlyingBalances[i]) * price;
const totalBorrow =
BigInt(p.totalStableDebt) + BigInt(p.totalVariableDebt);
const totalBorrowUsd = toTokenAmount(totalBorrow) * price;
- const totalSupplyUsd = tvlUsd + totalBorrowUsd;
+ const totalSupplyUsd = availableLiquidityUsd + totalBorrowUsd;
+ const tvlUsd = totalSupplyUsd;
const borrowCap = Number(poolsReserveCaps[i].borrowCap);
const borrowCapUsd = borrowCap * price;
const availableBorrowUsd = borrowCap
- ? Math.max(Math.min(tvlUsd, borrowCapUsd - totalBorrowUsd), 0)
- : tvlUsd;
+ ? Math.max(
+ Math.min(availableLiquidityUsd, borrowCapUsd - totalBorrowUsd),
+ 0
+ )
+ : availableLiquidityUsd;Also applies to: 118-123
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/adaptors/velkonix/index.js` around lines 101 - 111, The liquidity
calculation in the Velkonix adaptor is using idle cash for tvlUsd, which
underreports TVL once borrowing exists. In the pricing loop in index.js, update
the tvlUsd assignment to use total supplied liquidity (the existing
totalSupplyUsd derived from underlying balances plus total borrow) and keep the
idle/capped liquidity logic only for availableBorrowUsd. Make the same
adjustment anywhere else the same pattern appears, including the later block
referenced in the review, so tvlUsd consistently represents supplied liquidity
rather than available cash.
|
hi @CryptoBetmen, thanks for your PR - the TVL of these pools is extremely small and does not meet the 10k threshold to be displayed on defillama. Pls ping me when a pool is around this level and I will recheck. |
Summary by CodeRabbit