Lending on Jeongseup Blog

DefiDash

Thu, 22 Jan 2026 00:00:00 +0000

Role

Owner & Team Lead (curg-13)

Description

DefiDash is a DeFi leverage lending aggregator built on the Sui ecosystem. It aggregates multiple lending protocols on Sui to provide optimized leverage strategies for consumer users. The project consists of three repositories: a TypeScript SDK for protocol integration, a frontend DApp, and a marketing website.

Tech Stack

TypeScript
Sui Move
React / Next.js

Building a Leverage Position Preview for DeFi on Sui

Fri, 27 Feb 2026 00:00:00 +0000

How I built previewLeverage — a read-only preview engine that calculates leveraged lending position metrics across Suilend, Navi, and Scallop, without executing any on-chain transaction.

Team: curg-13 | SDK: defidash-sdk

Why Preview Before Leverage?

In DeFi lending, leverage means borrowing against your collateral to amplify your position. A 2x leverage on $100 of SUI gives you $200 total exposure — potentially doubling your returns, but also your risk.

Before users click “Confirm”, they need to know:

How much will be borrowed via flash loan?
What’s the liquidation price?
What’s the expected annual return (Net APY)?
How far can the price drop before liquidation?

That’s what previewLeverage computes — entirely off-chain, using real-time protocol data.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


const preview = await sdk.previewLeverage({
 protocol: LendingProtocol.Suilend,
 depositAsset: 'SUI',
 depositValueUsd: 100,
 multiplier: 2.0,
});

// preview.netApy → 2.33%
// preview.liquidationPrice → $0.63
// preview.priceDropBuffer → 33%

Glossary: Lending Protocol Concepts

If you’re a developer without DeFi background, here’s what you need to know. I’m also studying these concepts in depth — check the Lending Protocol Study series for worked examples:

Day 1: DeFi 렌딩의 핵심 개념과 아키텍처 — Pool-based 중개, Share-Based Accounting, Scaled Balance 패턴
Day 2: Compound V2 Deep Dive와 Aave V3 아키텍처 — Fresh 패턴, Mantissa 연산, 비트맵 스토리지 최적화

LTV (Loan-to-Value)

LTV is the maximum percentage of your collateral’s value that you can borrow.

$$\text{LTV} = \frac{\text{Borrowed Value}}{\text{Collateral Value}}$$

If SUI has a 70% LTV on Suilend, depositing $100 of SUI lets you borrow up to $70 of USDC. Each protocol sets different LTV ratios per asset — riskier assets get lower LTV.

Protocol	SUI LTV	XBTC LTV
Suilend	70%	60%
Navi	75%	67%
Scallop	85%	75%

For more details on how Health Factor works with LTV, see Lending Protocol Study Day 1 — the “Share-Based Accounting” section explains why each protocol tracks collateral differently.

Liquidation Threshold (LT)

Liquidation Threshold is the LTV level at which your position gets liquidated. It’s always higher than the borrow LTV, creating a safety buffer.

1
2
3


Borrow LTV: 70% → You can borrow up to 70%
Liq. Threshold: 75% → Liquidation triggers at 75%
Safety buffer: 5%

When the market price drops and your position’s actual LTV exceeds the liquidation threshold, a liquidator can repay part of your debt and claim your collateral at a discount.

Liquidation mechanics are a deep topic — the Lending Protocol Study series covers Compound V2’s liquidateBorrowFresh() and Aave V3’s architecture in detail.

Max Multiplier

Derived directly from LTV:

$$\text{Max Multiplier} = \frac{1}{1 - \text{LTV}}$$

With 70% LTV → max 3.33x leverage. With 85% LTV → max 6.67x. This is a hard protocol limit — you physically cannot borrow more than what the collateral factor allows.

Flash Loan

A flash loan is an uncollateralized loan that must be borrowed and repaid within a single atomic transaction. If you don’t repay, the entire transaction reverts as if it never happened.

In our leverage strategy, the flow is:

Flash loan USDC from Scallop
Swap USDC → deposit asset (e.g., SUI)
Deposit all collateral to lending protocol
Borrow USDC from protocol (using deposited collateral)
Repay flash loan

All 5 steps happen in one Sui Programmable Transaction Block (PTB). If step 5 fails, everything reverts.

For more on why Sui’s PTB model is ideal for this — see DefiDash Journal Day 1 where we compare PTB-based atomic leverage vs EVM Flash Loan patterns.

Supply APY & Borrow APY

Supply APY: What you earn by depositing assets. Composed of base interest + reward tokens (e.g., sSUI, DEEP).
Borrow APY: What you pay for borrowing. Some protocols give borrowing incentives (rebates).
Net APY: The leveraged return on your equity.

$$\text{Net APY} = \frac{\text{Total Position} \times \text{Supply APY} - \text{Debt} \times \text{Borrow APY}}{\text{Initial Equity}}$$

With 2x leverage: if supply APY > borrow APY, your returns are amplified. If not, you’re paying more than you earn (negative Net APY).

The interest rate models behind these APYs (JumpRateModel, utilization curves) are covered in Lending Protocol Study Day 1 and Day 2. Especially the Mantissa-based fixed-point arithmetic in Day 2 is directly relevant to how we parse on-chain rate data.

Liquidation Price

The asset price at which your position hits the liquidation threshold:

$$\text{Liquidation Price} = \frac{\text{Total Debt}}{\text{Total Collateral Amount} \times \text{Liquidation Threshold}}$$

For a $100 SUI position at 2x leverage on Suilend (LT = 75%):

Debt = $100, Total collateral = ~52.6 SUI (at $3.80)
Liquidation Price = $100 / (52.6 × 0.75) ≈ $2.53
That’s a ~33% price drop buffer from current price

How It’s Built

Architecture

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


previewLeverage(params)
 │
 ├─ 1. Resolve coin type ('SUI' → '0x2::sui::SUI')
 ├─ 2. Fetch risk params from protocol adapter
 │ └─ getAssetRiskParams(coinType) → { ltv, liquidationThreshold, maxMultiplier }
 ├─ 3. Validate multiplier ≤ maxMultiplier
 ├─ 4. Fetch current price from 7k Protocol aggregator
 │
 ├─ 5. Position calculation
 │ ├─ flashLoanUsdc = equity × (multiplier − 1) × 1.02 buffer
 │ ├─ totalPositionUsd = equity × multiplier
 │ └─ ltvPercent = debt / totalPosition × 100
 │
 ├─ 6. Liquidation calculation
 │ ├─ liquidationPrice = debt / (collateralAmount × LT)
 │ └─ priceDropBuffer = (1 − liqPrice / currentPrice) × 100
 │
 ├─ 7. APY calculation
 │ ├─ Supply APY: base + reward (per protocol adapter)
 │ ├─ Borrow APY: gross − rebate (per protocol adapter)
 │ └─ Net APY = (position × supplyAPY − debt × borrowAPY) / equity
 │
 └─ 8. Swap slippage estimation via 7k DEX aggregator quote

Multi-Protocol Adapter Pattern

Each lending protocol (Suilend, Navi, Scallop) implements the ILendingProtocol interface, and the preview engine queries them through a unified API:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


interface ILendingProtocol {
 getAssetRiskParams(coinType: string): Promise<{
 ltv: number;
 liquidationThreshold: number;
 maxMultiplier: number;
 }>;
 getAssetApy(coinType: string): Promise<{
 supplyApy: number;
 rewardApy: number;
 borrowApy: number;
 }>;
 // ... deposit, borrow, withdraw, etc.
}

The same previewLeverage call works across all three protocols — just change the protocol parameter:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Compare leverage across protocols
for (const protocol of ['suilend', 'navi', 'scallop']) {
 const preview = await sdk.previewLeverage({
 protocol,
 depositAsset: 'SUI',
 depositValueUsd: 100,
 multiplier: 2.0,
 });
 console.log(`${protocol}: Net APY ${(preview.netApy * 100).toFixed(2)}%`);
}

This adapter pattern follows the same principle as Aave V3’s modular architecture — separation of concerns with a thin routing layer. The Day 2 study covers how Aave V3 uses delegatecall + Library pattern to achieve a similar pluggable design.

Data Sources

Data	Source	Notes
Asset price	7k Protocol `getTokenPrice`	Real-time DEX aggregated price
LTV / LT	Protocol on-chain state	Suilend `RateLimiterConfig`, Navi `ReserveData`, Scallop `risk_models`
Supply/Borrow APY	Protocol SDK + on-chain query	Includes reward token APY
Flash loan fee	Scallop `FLASHLOAN_FEES_TABLE`	Currently 0% for USDC
Swap slippage	7k Protocol `quote()`	Real-time DEX routing

Challenges & Bugs Fixed

Reward APY showing 3700% instead of 1.46%

Suilend stores reward coin types without the 0x prefix internally (e.g., deeb7a4...::deep::DEEP). When we passed this to the 7k price API, it returned 0. The fallback code then used the deposit asset’s price ($67,987 for LBTC) as a proxy for the reward token (DEEP at $0.027), inflating the reward APY to 3700%.

Fix: normalize the coin type with 0x prefix before price lookup, and skip the reward if price is still unavailable.

1
2
3
4
5
6
7
8


// Before (broken)
const rewardPrice = await getTokenPrice(rewardCoinType); // returns 0
// Fallback: uses LBTC price → 3700% APY

// After (fixed)
const normalizedReward = normalizeCoinType(rewardCoinType);
const fetchedPrice = await getTokenPrice(normalizedReward);
if (fetchedPrice <= 0) continue; // skip this reward

Scallop risk params not accessible via SDK

Scallop’s TypeScript SDK doesn’t expose risk_models data. We had to query the on-chain risk_models dynamic fields directly using suiClient.getDynamicFieldObject() to extract LTV and liquidation threshold values.

Verified Results (2026-02-26, Mainnet)

SUI 2x Leverage

	Suilend	Navi	Scallop
Asset LTV	70%	75%	85%
Liq. Threshold	75%	70%	90%
Max Multiplier	3.33x	4.00x	6.67x
Liq. Price	$0.63	$0.68	$0.53
Price Drop Buffer	33%	29%	44%
Supply APY	2.89%	2.97%	2.98%
Borrow Net APY	3.45%	4.57%	5.80%
Net APY	2.33%	1.37%	0.15%

XBTC 2x Leverage

	Suilend	Navi	Scallop
Asset LTV	60%	67%	75%
Supply APY	3.78%	6.73%	0.00%
Net APY	4.10%	8.88%	-5.80%

The negative Net APY on Scallop XBTC means borrowing costs exceed supply earnings — leverage actually loses money in that case.

What’s Next

leverage() — Actually execute the leveraged position on-chain
deleverage() — Close/reduce a leveraged position (flash loan → repay debt → withdraw → swap → repay)
previewDeleverage() — Preview the unwinding process
Cross-protocol position comparison dashboard

DefiDash Technical Journal Day 1: 프로젝트 킥오프와 Sui 렌딩 생태계 분석

Fri, 27 Feb 2026 00:00:00 +0000

DefiDash 개발 과정을 기록하는 테크니컬 저널 시리즈. Day 1에서는 프로젝트의 동기와 목표, Sui 생태계의 렌딩 프로토콜 현황, 그리고 레버리지 렌딩 어그리게이터의 아키텍처 설계를 다룬다.

Team: curg-13

왜 DefiDash인가

DeFi 렌딩 시장은 이미 성숙해있다. Ethereum에는 Aave, Compound, MakerDAO가 있고, 다른 체인에도 포크된 프로토콜들이 넘쳐난다. 그런데 Sui 생태계는 다르다.

Sui는 Move 기반의 Object-centric 모델을 사용한다. EVM의 Account-based 모델과 근본적으로 다른 패러다임이다. 이 차이는 DeFi 프로토콜 설계에도 영향을 미친다:

Object Ownership: 자산이 계정이 아닌 오브젝트로 관리된다
Parallel Execution: 독립적인 오브젝트 간 트랜잭션은 병렬 실행 가능
PTB (Programmable Transaction Blocks): 하나의 트랜잭션에서 여러 DeFi 연산을 원자적으로 실행

특히 PTB는 레버리지 렌딩에 결정적이다. EVM에서는 Flash Loan으로 여러 트랜잭션을 하나로 묶지만, Sui에서는 PTB로 네이티브하게 복합 연산이 가능하다.

문제는 Sui의 렌딩 프로토콜들이 아직 파편화되어 있다는 것이다. 각 프로토콜마다 다른 인터페이스, 다른 이자율 모델, 다른 담보 비율. 일반 사용자가 최적의 레버리지 전략을 찾는 것은 사실상 불가능하다.

DefiDash는 이 문제를 해결한다. Sui 생태계의 렌딩 프로토콜들을 하나의 인터페이스로 어그리게이트하여, 사용자에게 최적의 레버리지 전략을 제공한다.

프로젝트 구조

curg-13 팀으로 3개의 레포지토리를 구성했다.

1
2
3
4


curg-13/
├── defidash-sdk # 핵심 SDK - 프로토콜 통합 레이어
├── defidash-frontend # 사용자 facing DApp
└── defidash-website # 랜딩 페이지 & 문서

defidash-sdk

프로토콜 어그리게이션의 핵심이다. 각 렌딩 프로토콜의 인터페이스를 추상화하고, 통합된 API를 제공한다.

주요 책임:

각 프로토콜의 온체인 데이터 조회 (이자율, 담보 비율, 유동성)
레버리지 포지션 시뮬레이션
PTB 구성 및 트랜잭션 빌딩
최적 경로 계산 (어떤 프로토콜 조합이 가장 유리한지)

defidash-frontend

일반 사용자를 위한 DApp이다. 복잡한 레버리지 전략을 직관적인 UI로 제공한다.

핵심 UX 목표:

원클릭 레버리지 포지션 오픈/클로즈
실시간 Health Factor 모니터링
프로토콜 간 이자율 비교 대시보드

defidash-website

프로젝트 소개와 문서를 담는 마케팅 사이트다.

Sui 렌딩 생태계 현황

현재 Sui에서 활동 중인 주요 렌딩 프로토콜들을 정리했다.

Protocol	Type	Key Feature
Scallop	Pool-based	Sui 최초의 렌딩 프로토콜, sCoin 모델
NAVI Protocol	Pool-based	Dynamic interest rate, Flash Loan 지원
Suilend	Pool-based	Solend 팀의 Sui 버전, Obligation 기반
Bucket Protocol	CDP-based	BUCK 스테이블코인 발행

EVM 생태계와 비교하면 아직 초기 단계지만, 각 프로토콜이 Sui의 특성을 살린 독자적인 설계를 가지고 있다. 이 차이점이 곧 어그리게이션의 가치다.

아키텍처 설계: 어그리게이션 레이어

레버리지 렌딩 어그리게이터의 핵심은 Protocol Adapter Pattern이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


사용자 → DefiDash Frontend
 ↓
 DefiDash SDK
 ↓
 ┌─────────┼─────────┐
 ↓ ↓ ↓
 Scallop NAVI Suilend ← Protocol Adapters
 Adapter Adapter Adapter
 ↓ ↓ ↓
 └─────────┼─────────┘
 ↓
 Sui Network

각 프로토콜 Adapter는 동일한 인터페이스를 구현한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


interface LendingProtocolAdapter {
 // 프로토콜 상태 조회
 getMarkets(): Promise<Market[]>;
 getInterestRates(market: string): Promise<InterestRate>;
 getUserPosition(address: string): Promise<Position>;

 // 트랜잭션 빌딩
 buildSupplyTx(params: SupplyParams): TransactionBlock;
 buildBorrowTx(params: BorrowParams): TransactionBlock;
 buildLeverageTx(params: LeverageParams): TransactionBlock;
}

이 패턴의 장점은 새로운 프로토콜 추가가 Adapter 하나만 구현하면 된다는 것이다. SDK의 코어 로직이나 프론트엔드를 수정할 필요 없다.

레버리지 렌딩의 원리

일반 사용자를 위해 레버리지 렌딩이 어떻게 작동하는지 정리한다.

기본 개념

담보 예치: 1,000 USDC를 렌딩 프로토콜에 담보로 예치
대출: 담보 대비 700 SUI를 대출 (LTV 70%)
재예치: 대출받은 SUI를 다시 담보로 예치
반복: 이 과정을 반복하면 실효 레버리지가 증가

1
2
3
4
5
6


초기 자본: 1,000 USDC
1차 대출: 700 SUI → 재예치
2차 대출: 490 SUI → 재예치
3차 대출: 343 SUI → 재예치
...
실효 노출: ~3,333 USDC 상당 (약 3.3x 레버리지)

Sui PTB의 이점

EVM에서는 이 과정을 Flash Loan + 여러 컨트랙트 호출로 구현해야 한다. 가스비도 높고 실패 리스크도 있다.

Sui의 PTB에서는 하나의 트랜잭션 블록 안에서 모든 단계를 원자적으로 실행할 수 있다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


const txb = new TransactionBlock();

// 1. 담보 예치
const receipt = txb.moveCall({ target: `${PROTOCOL}::deposit`, arguments: [...] });

// 2. 대출
const borrowed = txb.moveCall({ target: `${PROTOCOL}::borrow`, arguments: [...] });

// 3. 재예치 (대출 결과를 바로 사용)
txb.moveCall({ target: `${PROTOCOL}::deposit`, arguments: [borrowed, ...] });

// 하나의 트랜잭션으로 실행
await client.signAndExecuteTransactionBlock({ transactionBlock: txb });

Flash Loan 없이도 원자적 레버리지가 가능하다. 이것이 Sui에서 렌딩 어그리게이터를 만드는 핵심 이유다.

Day 1 정리

항목	결정 사항
프로젝트명	DefiDash
팀	curg-13
타겟 체인	Sui
핵심 기술	PTB 기반 레버리지 렌딩 어그리게이션
SDK 언어	TypeScript
아키텍처	Protocol Adapter Pattern
첫 통합 대상	Scallop, NAVI, Suilend

Next: Day 2

다음 저널에서는 실제 SDK 개발을 시작한다.

Sui 렌딩 프로토콜 온체인 데이터 구조 분석
Protocol Adapter 구현 (Scallop부터)
PTB 기반 레버리지 트랜잭션 빌딩

DefiDash의 전체 코드는 curg-13 조직에서 확인할 수 있다.

Lending Protocol Study Day 2: Compound V2 Deep Dive와 Aave V3 아키텍처

Wed, 25 Feb 2026 00:00:00 +0000

7일간의 DeFi Lending Protocol 스터디 시리즈. Day 2에서는 Compound V2의 내부 구조를 코드 레벨로 파고들고, 렌딩 프로토콜의 3가지 유형을 분류한 뒤, Aave V3의 아키텍처 진화를 분석한다.

Repository: jeongseup/lending-protocol-study

Day 2 목표

Compound V2의 CToken 상속 구조와 “Fresh” 패턴을 코드 레벨로 이해한다
Mantissa 기반 고정소수점 연산과 Lazy Interest Accrual 메커니즘을 파악한다
렌딩 프로토콜을 3가지 유형(Pool-based, CDP-based, Fixed-rate)으로 분류한다
Aave V3의 비트맵 스토리지 최적화와 아키텍처 진화를 분석한다

Compound V2 Deep Dive: CToken 상속 구조

Day 1에서 Compound V2의 핵심 파일 3개를 언급했다. Day 2에서는 CToken의 상속 구조부터 파고든다.

1
2
3
4


CTokenInterface (인터페이스)
 └─ CToken (핵심 로직)
 ├─ CErc20 (ERC20 자산용 - USDC, DAI 등)
 └─ CEther (ETH 전용)

CErc20과 CEther의 차이는 단순하다. ETH는 ERC20이 아니라 msg.value로 받아야 하므로, 자금 수수 로직만 다르고 핵심 렌딩 로직은 CToken에 모두 있다.

중요한 건 CToken이 풀 역할까지 겸한다는 점이다. mint(), borrow(), repay(), liquidate() 모두 CToken 컨트랙트에 있다. 하나의 컨트랙트가 ERC20 토큰이면서 동시에 렌딩 풀인 Monolithic 구조다.

Fresh 패턴: “이자부터 정산하고 본론으로”

Compound V2의 모든 핵심 함수 이름에 Fresh가 붙어 있다.

1
2
3
4


function mintFresh(address minter, uint mintAmount) internal
function borrowFresh(address payable borrower, uint borrowAmount) internal
function repayBorrowFresh(address payer, address borrower, uint repayAmount) internal
function liquidateBorrowFresh(address liquidator, address borrower, ...) internal

왜 Fresh일까? **“이자를 최신 상태로 정산한 뒤에 핵심 로직을 실행한다”**는 패턴이다.

1
2
3
4


function mint(uint mintAmount) external returns (uint) {
 accrueInterest(); // 1. 이자 먼저 정산
 return mintFresh(msg.sender, mintAmount); // 2. 그 다음 본론
}

모든 external 함수가 이 패턴을 따른다:

1

사용자 호출 → accrueInterest() → xxxFresh() → 실제 로직

이렇게 하는 이유는 간단하다. 이자 계산은 마지막 업데이트 이후의 블록 수에 기반한다. 이자를 정산하지 않고 mint()을 실행하면, 기존 예치자들의 교환비율이 부정확한 상태에서 새로운 지분이 발행되어 기존 예치자가 손해를 본다.

Mantissa: Solidity의 소수점 해법

Solidity에는 부동소수점이 없다. Compound V2는 이를 Mantissa 방식으로 해결한다.

$$\text{Mantissa} = \text{실제값} \times 10^{18}$$

예를 들어:

이자율 5% → 0.05 × 10^18 = 50000000000000000
교환비율 0.02 → 0.02 × 10^18 = 20000000000000000

곱셈과 나눗셈 시 스케일링을 맞춰야 한다:

1
2
3
4
5
6
7
8


// 두 Mantissa 값의 곱셈: 결과를 10^18으로 나눠서 스케일 복원
function mulScalar(Exp memory a, uint scalar) pure internal returns (Exp memory) {
 return Exp({mantissa: a.mantissa * scalar});
}

function mulExp(Exp memory a, Exp memory b) pure internal returns (Exp memory) {
 return Exp({mantissa: a.mantissa * b.mantissa / 1e18});
}

이 패턴은 Compound만의 것이 아니다. Aave의 RAY(10^27), Uniswap V3의 Q96(2^96), MakerDAO의 WAD(10^18) 모두 같은 원리다. 정수로 소수점을 표현하기 위한 고정소수점 연산.

Lazy Interest Accrual: 이자는 “필요할 때만” 계산한다

accrueInterest()는 매 블록마다 자동으로 실행되는 게 아니다. 누군가 트랜잭션을 보낼 때만 실행된다. 이것이 Lazy Evaluation이다.

1
2
3


블록 100: Alice가 mint() → accrueInterest() 실행 (블록 0~100 이자 계산)
블록 200: 아무 일 없음 → 이자 계산 안 함
블록 300: Bob이 borrow() → accrueInterest() 실행 (블록 100~300 이자 계산)

200 블록 동안 아무도 상호작용하지 않으면, 200 블록치의 이자가 한번에 계산된다. 가스비는 트랜잭션 수가 아니라 상호작용 빈도에 비례한다.

accrueInterest()가 업데이트하는 상태 변수는 딱 4개다:

1
2
3
4


totalBorrows // 총 대출량 (이자 포함)
totalReserves // 프로토콜 수익 누적
borrowIndex // 대출자 이자 추적용 전역 인덱스
accrualBlockNumber // 마지막 이자 정산 블록 번호

4개의 SSTORE = 20,000 gas. 사용자 수가 아무리 많아도 이 비용은 고정이다. 이것이 Day 1에서 설명한 Scaled Balance 패턴의 실제 구현이다.

이자 시나리오 시뮬레이션

구체적인 숫자로 따라가보자.

초기 상태

1
2
3
4
5
6


블록 0: Pool에 10,000 USDC
- totalCash = 10,000
- totalBorrows = 0
- totalReserves = 0
- borrowIndex = 1.0 (1e18)
- exchangeRate = 10,000 / 500,000 = 0.02 (cToken 500,000개 발행 가정)

Alice가 1,000 USDC 대출

1
2
3
4
5


블록 100: Alice borrow(1,000)
- accrueInterest() 실행 (totalBorrows = 0이므로 이자 없음)
- totalCash = 9,000 (1,000 빠짐)
- totalBorrows = 1,000
- Alice의 borrowSnapshot = {principal: 1,000, interestIndex: 1.0}

100블록 후 이자 정산

1
2
3
4
5
6
7


블록 200: Bob이 mint() 호출
- 이자율: borrowRate = 0.0001/블록 (연 약 5.3%)
- 경과 블록: 100
- simpleInterestFactor = 0.0001 × 100 = 0.01
- 새 totalBorrows = 1,000 × 1.01 = 1,010
- Reserve Factor 10%: 새 totalReserves = 10 × 0.1 = 1
- 새 borrowIndex = 1.0 × 1.01 = 1.01

Alice의 실제 대출 잔액은?

$$\text{Alice 대출잔액} = \frac{\text{principal} \times \text{현재 borrowIndex}}{\text{Alice의 interestIndex}} = \frac{1{,}000 \times 1.01}{1.0} = 1{,}010 \text{ USDC}$$

Alice의 Storage를 건드리지 않고도 전역 borrowIndex 하나만으로 정확한 잔액을 계산했다.

렌딩 프로토콜의 3가지 유형

Day 1에서는 Pool-based 모델만 다뤘다. 실제로 렌딩 프로토콜은 자금 조달 방식에 따라 3가지로 분류된다.

1. Pool-based (Compound, Aave)

1

예치자 → [Pool] → 차입자

기존 예치금에서 대출
예치자가 없으면 빌릴 수 없다
이자율은 Utilization Rate에 연동

2. CDP-based (MakerDAO)

1

사용자 → [Vault] → 새 DAI 발행

프로토콜이 새 토큰을 발행 (mint)
예치자 없이도 대출 가능
Stability Fee(이자)는 거버넌스가 결정
CDP = Collateralized Debt Position

3. Fixed-rate (Yield Protocol)

1

사용자 → fyToken (만기 시 1:1 교환 가능)

할인된 미래 가치 토큰 매매
0.95 fyUSDC를 사면, 만기에 1 USDC → 약 5% 고정 금리
이자율이 트레이딩으로 결정

비교 정리

특성	Pool-based	CDP-based	Fixed-rate
자금 출처	예치자	프로토콜 발행	시장 매매
이자율 결정	알고리즘 (사용률)	거버넌스 투표	시장 수급
변동/고정	변동	반고정	고정
대표	Compound, Aave	MakerDAO	Yield, Notional
필요 조건	유동성 공급자	없음 (mint)	만기 매칭

대부분의 메이저 프로토콜이 Pool-based인 이유: 구현이 단순하고, 유동성이 자연스럽게 형성되기 때문이다. CDP는 토큰 경제 설계가 복잡하고, Fixed-rate는 만기 매칭이 어렵다.

Aave V3 아키텍처: Compound에서 무엇이 진화했나

Compound V2는 CToken이 모든 걸 한다. Aave V3는 이를 분리했다.

1
2
3
4
5
6
7


Compound V2:
 사용자 → CToken.mint() (CToken = 풀 + 토큰)

Aave V3:
 사용자 → Pool.supply() (Pool = 라우터)
 → SupplyLogic.executeSupply() (Library = 실제 로직)
 → aToken.mint() (aToken = 순수 영수증)

delegatecall + Library 패턴

Aave V3의 Pool.sol은 얇은 프록시에 가깝다. 실제 로직은 Library 컨트랙트에 있다.

1
2
3
4
5
6
7
8


// Pool.sol
function supply(address asset, uint256 amount, ...) external {
 SupplyLogic.executeSupply(...); // delegatecall로 Library 호출
}

function borrow(address asset, uint256 amount, ...) external {
 BorrowLogic.executeBorrow(...);
}

Library를 쓰면:

코드 크기 제한(24KB) 회피 - Pool의 로직이 아무리 커도 Library에 분산
관심사 분리 - Supply, Borrow, Liquidation 로직이 독립적으로 관리
단, Library는 독립 배포 후 업그레이드 불가 - Proxy 패턴과 조합하여 해결

Debt Tokenization

Compound V2에서 대출은 단순 매핑이다:

1
2


// Compound V2
mapping(address => BorrowSnapshot) accountBorrows;

Aave V3는 대출도 토큰화했다:

1
2
3


// Aave V3
variableDebtToken.mint(borrower, amount); // 대출하면 부채 토큰 발행
variableDebtToken.burn(borrower, amount); // 상환하면 부채 토큰 소각

부채를 토큰화하면 무엇이 좋은가?

balanceOf()로 대출 잔액 조회 가능 (표준 인터페이스)
Transfer 제한으로 부채 이전 방지
이벤트 표준화 (Transfer 이벤트로 대출/상환 추적 가능)

Aave V3.2부터 Stable Rate이 제거되었다. 변동금리만 남았으므로 stableDebtToken은 더 이상 사용되지 않는다.

비트맵 스토리지 최적화

Day 2의 가장 중요한 기술적 발견이다. Compound V2와 Aave V3의 사용자 상태 관리 방식이 근본적으로 다르다.

Compound V2: 배열 순회

1
2
3
4
5
6
7


// Comptroller.sol
mapping(address => CToken[]) public accountAssets; // 사용자별 참여 마켓 배열

// Health Factor 계산 시
for (uint i = 0; i < assets.length; i++) {
 // 모든 마켓을 순회하며 담보 가치 합산
}

문제: 사용자가 참여한 마켓이 많을수록 가스비가 선형으로 증가한다.

Aave V3: 비트맵

1
2
3
4
5
6
7


// 하나의 uint256에 128개 자산의 상태를 담는다
// 각 자산이 2비트를 차지: [담보 사용 여부][대출 여부]
mapping(address => UserConfigurationMap) internal _usersConfig;

struct UserConfigurationMap {
 uint256 data; // 256비트 = 128개 자산 × 2비트
}

비트맵의 구조:

1
2
3
4
5


비트 위치: ... | 5 | 4 | 3 | 2 | 1 | 0 |
자산 ID: | 2 | 1 | 0 |
의미: ... | C | B | C | B | C | B |
 B = Borrowing (대출 중)
 C = Collateral (담보로 사용 중)

Health Factor 계산 시:

1
2
3
4


// 비트맵에서 해당 비트가 0이면 스킵
if (userConfig.data & (1 << (reserveIndex * 2)) == 0) {
 continue; // 이 자산은 대출도 담보도 아님 → O(1)로 스킵
}

성능 비교

1
2
3
4
5


Compound V2 (배열):
 10개 마켓 참여 → 10번 SLOAD + 루프 = ~50,000 gas

Aave V3 (비트맵):
 128개 마켓 확인 → 1번 SLOAD + 비트 연산 = ~2,100 gas

비트 연산(AND, SHIFT)은 3 gas다. 128개 자산을 확인해도 2,100 + 128 × 3 = 2,484 gas. 배열 방식 대비 약 20배 절약이다.

이 차이가 결정적인 이유: Health Factor 계산은 모든 트랜잭션에서 발생한다. supply, borrow, repay, liquidate 전부. 가장 빈번하게 호출되는 로직의 가스를 20배 줄이면 프로토콜 전체의 가스 효율이 극적으로 개선된다.

LendingPool 리팩토링: 배운 것을 적용하기

스터디 프로젝트의 LendingPool.sol에 Aave V3의 PoolStorage 패턴을 적용했다.

Before: 단순 매핑

1
2


mapping(address => mapping(address => uint256)) public deposits;
mapping(address => mapping(address => uint256)) public borrows;

After: 구조화된 스토리지

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


struct ReserveData {
 uint128 liquidityIndex;
 uint128 variableBorrowIndex;
 uint128 currentLiquidityRate;
 uint128 currentVariableBorrowRate;
 uint40 lastUpdateTimestamp;
 uint16 id;
 address aTokenAddress;
 address variableDebtTokenAddress;
 uint128 totalDeposits;
 uint128 totalBorrows;
}

mapping(address => ReserveData) internal _reserves;
mapping(uint256 => address) internal _reservesList;
uint16 internal _reservesCount;

mapping(address => UserConfigurationMap) internal _usersConfig;

핵심 변경점:

_reserves: 자산 주소 → ReserveData 매핑 (모든 자산 상태를 하나의 구조체로)
_reservesList: reserveId → 자산 주소 매핑 (비트맵 인덱싱용)
_usersConfig: 사용자별 비트맵 (담보/대출 상태)

비트맵 헬퍼도 구현했다:

1
2
3
4
5
6
7
8
9


function isUsingAsCollateral(UserConfigurationMap memory self, uint256 reserveIndex)
 internal pure returns (bool) {
 return (self.data >> (reserveIndex * 2 + 1)) & 1 != 0;
}

function isBorrowing(UserConfigurationMap memory self, uint256 reserveIndex)
 internal pure returns (bool) {
 return (self.data >> (reserveIndex * 2)) & 1 != 0;
}

리팩토링 후 모든 62개 테스트(기존 61 + 비트맵 테스트 1)가 통과했다.

JumpRateModel 테스트: Fuzz Testing까지

Day 1에서 이론으로 다룬 JumpRateModel을 실제로 구현하고 테스트했다.

Unit Test: 18개 케이스

1
2
3
4
5
6


[PASS] testGetBorrowRate_ZeroUtilization()
[PASS] testGetBorrowRate_AtKink()
[PASS] testGetBorrowRate_AboveKink()
[PASS] testGetBorrowRate_FullUtilization()
[PASS] testGetSupplyRate_WithReserveFactor()
... (18개 전부 통과)

Fuzz Test: 6개 케이스

1
2
3
4
5
6
7
8
9


function testFuzz_BorrowRateMonotonicity(uint256 util1, uint256 util2) public {
 util1 = bound(util1, 0, 1e18);
 util2 = bound(util2, util1, 1e18);

 uint256 rate1 = model.getBorrowRate(cash1, borrows1, reserves1);
 uint256 rate2 = model.getBorrowRate(cash2, borrows2, reserves2);

 assertGe(rate2, rate1); // 사용률이 높으면 이자율도 높아야 한다
}

Fuzz Testing으로 검증한 불변 조건:

단조 증가: 사용률이 올라가면 이자율도 올라간다
Supply ≤ Borrow: Supply Rate은 항상 Borrow Rate 이하
Kink에서의 연속성: kink 전후로 이자율이 비연속적으로 뛰지 않는다

전체 24개 테스트 (18 unit + 6 fuzz) 모두 통과.

Day 2 핵심 인사이트 정리

Fresh 패턴은 렌딩의 정합성을 보장한다 - 이자를 먼저 정산하지 않으면 교환비율이 부정확해져서 기존 사용자가 손해본다. “이자부터, 그 다음 본론"이 원칙.
Lazy Interest Accrual은 가스 효율의 핵심 - 매 블록이 아니라 트랜잭션이 발생할 때만 이자를 계산한다. 4개의 SSTORE로 전체 사용자의 이자를 한번에 정산.
렌딩은 3가지 유형 - Pool-based(예치금에서 빌림), CDP-based(새 토큰 발행), Fixed-rate(할인 토큰). 대부분이 Pool-based인 이유는 구현 단순성과 유동성 형성의 용이함.
비트맵이 아키텍처를 결정한다 - Compound의 배열 vs Aave의 비트맵. 한 번의 SLOAD로 128개 자산 상태를 확인하는 것은 단순한 최적화가 아니라, Health Factor 계산이 모든 트랜잭션에서 발생하기 때문에 프로토콜 전체 가스 효율을 좌우한다.
Storage 레이아웃이 아키텍처를 결정한다 - Compound는 배열 중심이라 Monolithic이 자연스럽고, Aave는 비트맵 + 구조체 중심이라 Modular가 자연스럽다. 데이터 구조가 코드 구조를 결정한다.

Next: Day 3

내일은 청산(Liquidation) 메커니즘을 파고든다.

청산 트리거 조건과 liquidateBorrowFresh() 코드 리딩
청산 보너스(Liquidation Incentive) 경제학
Foundry Fork Testing으로 Aave V3 메인넷 청산 시뮬레이션
고급 Foundry 테스팅 패턴 (invariant, fork)

이 시리즈의 전체 코드와 학습 자료는 lending-protocol-study 레포에서 확인할 수 있다.

Lending Protocol Study Day 1: DeFi 렌딩의 핵심 개념과 아키텍처

Mon, 23 Feb 2026 00:00:00 +0000

7일간의 DeFi Lending Protocol 스터디 시리즈. 백엔드/인프라 엔지니어 관점에서 렌딩 프로토콜을 코드 레벨까지 파헤친다.

Repository: jeongseup/lending-protocol-study

Why Lending Protocol?

블록체인 인프라 엔지니어로 일하면서 노드 운영, 밸리데이터 모니터링, 스테이킹 보상 분석 등을 해왔다. 그런데 DeFi의 가장 큰 축인 렌딩 프로토콜은 “대충 알겠는데 코드 레벨에서는 모른다"는 상태였다.

이번 스터디의 목표는 명확하다:

Compound V2 / Aave V3의 핵심 로직을 코드로 읽고 구현한다
렌딩의 수학적 모델(이자율, 청산, Health Factor)을 공식 수준으로 이해한다
Solidity + Go 모니터링 도구까지 만들어 실무에 적용 가능한 수준으로 올린다

렌딩 프로토콜의 본질: 풀 기반 중개

전통 금융의 대출은 대출자와 차입자를 1:1로 매칭한다. DeFi 렌딩은 다르다.

1
2


전통 금융: Alice → [은행] → Bob (1:1 매칭)
DeFi 렌딩: Alice → [Pool] ← Bob (풀 기반 간접 매칭)

예치자들이 자산을 풀에 넣으면, 차입자들이 담보를 걸고 풀에서 빌려간다. 아무도 누가 누구에게 빌려줬는지 모른다. 이자율은 풀의 사용률(Utilization Rate)에 따라 알고리즘이 자동으로 결정한다.

이 구조의 핵심 이유는 간단하다:

1

블록체인 = 익명 → 신용평가 불가 → 담보로만 판단 → 과담보 필수

신용이 없으니 담보로 대체한다. 그래서 DeFi 렌딩은 태생적으로 과담보(Over-collateralized) 구조다.

렌딩의 5대 핵심 파라미터

렌딩 프로토콜을 이해하려면 이 5가지 숫자만 확실히 알면 된다.

파라미터	의미	일반적 범위
LTV (Loan-to-Value)	담보 대비 얼마까지 빌릴 수 있나	75-80%
Health Factor	내 포지션이 안전한가 (< 1이면 청산)	1.0 이상 유지
Utilization Rate	풀의 자금 중 얼마가 빌려졌나	이자율 결정
Reserve Factor	프로토콜이 이자에서 떼가는 비율	10-35%
Collateral Factor	자산의 담보 가치 인정 비율	자산마다 다름

외워야 할 공식 3개

$$HF = \frac{LT}{LTV}$$$$\text{최대 허용 하락률} = 1 - \frac{LTV}{LT}$$$$\text{Supply APY} = \text{Borrow APR} \times \text{Utilization} \times (1 - \text{Reserve Factor})$$

세 번째 공식이 특히 중요하다. Supply APY가 Borrow APR보다 수학적으로 항상 작은 이유가 여기 있다. 풀의 돈이 100% 빌려진 게 아니고(Utilization < 1), 프로토콜이 Reserve Factor만큼 떼가기 때문이다.

단, 토큰 인센티브(COMP, AAVE)나 포인트/에어드랍까지 포함하면 역전될 수 있다. 2020년 DeFi Summer에 “빌리면 돈 버는” 상황이 실제로 발생했다.

이자율 모델: Jump Rate Model

“사용률이 올라가면 이자율도 올라간다"는 단순한 원칙이지만, 구현 방식은 프로토콜마다 다르다.

프로토콜	모델	특징
Compound V2	Jump Rate Model	원조. kink 지점에서 이자율 급등
Aave V3	Variable Rate Strategy	비슷하지만 파라미터 구조 다름
MakerDAO	거버넌스 직접 설정	알고리즘 아님
Euler V2	모듈형	풀 생성자가 모델 직접 선택

DEX에서 x * y = k (CPMM)가 원조 모델이듯, 렌딩에서는 Jump Rate Model이 원조다. “유일한 표준"은 아니지만, 대부분의 모델이 이걸 변형한 것이다.

cToken vs aToken: 이자를 반영하는 두 가지 방법

렌딩에 자산을 예치하면 “영수증 토큰"을 받는다. 이 영수증이 이자를 반영하는 방식이 Compound와 Aave에서 근본적으로 다르다.

Compound의 cToken: 교환비율 상승

1
2
3


예치: 1,000 USDC → 50,000 cUSDC (교환비율 0.02)
1년후: 50,000 cUSDC 그대로, 교환비율 0.025로 상승
인출: 50,000 × 0.025 = 1,250 USDC

토큰 수량은 변하지 않고, 교환비율이 올라간다.

Aave의 aToken: 잔고 자동 증가 (Rebase)

1
2
3


예치: 1,000 USDC → 1,000 aUSDC (1:1)
1년후: 지갑에 1,050 aUSDC로 자동 증가
인출: 1,050 aUSDC → 1,050 USDC

교환비율은 1:1 고정이고, 토큰 수량이 늘어난다.

비교	cToken	aToken
UX	비직관적 (교환비율 계산 필요)	직관적 (잔고 = 실제 가치)
DeFi 호환성	유리 (표준 ERC20)	불리 (rebase 토큰)
수학	`amount = shares × exchangeRate`	`balance = scaledBalance × index`

수학적으로는 동일하다. “언제 곱하느냐"의 차이일 뿐이다.

cToken의 교환비율 패턴은 사실 DeFi 전반에서 반복되는 범용 패턴이다.

1

지분으로 변환 → 전역 비율만 업데이트 → 인출 시 역변환

이 패턴을 쓰는 곳들:

프로토콜	용도
Compound cToken	렌딩 예치 영수증
ERC-4626	토큰화된 Vault 표준
Lido wstETH	Liquid Staking
Rocket Pool rETH	Liquid Staking
Walrus StakingPool	스토리지 네트워크 스테이킹

Walrus의 StakingPool과 비교하면:

1
2
3
4
5
6
7
8
9


Compound cToken:
 exchange_rate = (totalCash + totalBorrows - totalReserves) / totalSupply
 deposit: shares = amount / exchange_rate
 withdraw: amount = shares × exchange_rate

Walrus StakingPool:
 exchange_rate = total_wal / total_shares
 stake: shares = principal × total_shares / total_wal
 withdraw: amount = shares × total_wal / total_shares

같은 공식이다. 변수명만 다르다.

가스 최적화의 핵심: Scaled Balance

aToken이 “잔고가 자동으로 늘어난다"면, 매번 모든 사용자의 잔고를 업데이트하는 걸까? 당연히 아니다. 그러면 가스비가 폭발한다.

핵심 아이디어: 쓰기를 읽기로 바꾼다.

1

Scaled Balance = 예치금 / 예치 시점의 liquidityIndex

이 값은 한번 저장되면 절대 변하지 않는다. 변하는 건 전역 liquidityIndex 하나뿐이다.

잔고를 조회할 때 scaledBalance × 현재 index로 계산한다. balanceOf()는 view 함수이므로 가스비가 0이다.

1
2
3
4
5
6


순진한 방식: 이자 발생 시 모든 사용자 잔고 SSTORE
 → 1,000명 × 5,000 gas = 5,000,000 gas

Scaled Balance: 전역 index 1개만 SSTORE
 → 5,000 gas
 → 99.9% 절약

EVM에서 SSTORE(쓰기)는 5,000 gas, MUL(곱셈)은 5 gas다. 쓰기는 계산보다 1,000배 비싸다. Merkle Patricia Trie를 재계산하고 모든 노드에 영구 저장해야 하기 때문이다. Scaled Balance는 이 비용 구조를 정확히 활용한 최적화다.

Compound V2 vs Aave V3: 아키텍처 차이

두 프로토콜의 가장 큰 차이는 코드 구조에 있다.

1
2
3
4
5


Compound: CToken이 풀 역할까지 겸함 (Monolithic)
 사용자 → CToken.mint()

Aave/우리 프로젝트: Pool과 토큰 분리 (Modular)
 사용자 → Pool.deposit() → aToken.mint()

Compound의 CToken은 ERC20 토큰이면서 동시에 렌딩 풀이다. mint(), borrow(), repay(), liquidate() 모두 CToken 컨트랙트에 있다. 반면 Aave는 Pool이 중심이고 aToken은 순수한 영수증 토큰이다.

Compound V2 코드 리딩 가이드

Compound V2 코드를 읽고 싶다면, 핵심 3개 파일, 5개 함수만 보면 된다.

CToken.sol - 핵심 함수 5개:

accrueInterest() - 이자 누적 (borrowIndex = scaled balance 패턴)
mintFresh() - 예치
borrowFresh() - 대출
repayBorrowFresh() - 상환
liquidateBorrowFresh() - 청산

Comptroller.sol - 핵심 함수 1개:

getHypotheticalAccountLiquidityInternal() - Health Factor 계산

BaseJumpRateModelV2.sol - 이자율 모델

나머지(Governance, Lens, Timelock 등)는 렌딩 로직과 무관하므로 무시해도 된다.

이자율의 3개 레이어

DeFi에서 실제 수익률은 단순한 이자율이 아니라 3개 레이어의 합이다.

1
2
3


Layer 1: 기본 이자 → Jump Rate Model이 결정
Layer 2: 토큰 인센티브 → COMP, AAVE 등 거버넌스 토큰 보상
Layer 3: 포인트/에어드랍 → Blast, EigenLayer 등

Layer 2, 3까지 포함하면 “빌리면 돈 버는” 상황도 발생한다. 2020 DeFi Summer에 COMP 보상이 대출 이자보다 커서 Compound에서 빌리는 것 자체가 수익이었던 것이 대표적인 사례다.

Day 1 핵심 인사이트 정리

렌딩의 본질은 풀 기반 중개 - 예치자와 대출자를 직접 매칭하지 않고, 풀을 통해 간접 매칭한다. 스테이킹 풀과 동일한 패턴.
Share-Based Accounting은 DeFi의 범용 패턴 - cToken, ERC-4626, wstETH, rETH, Walrus 전부 같은 원리. “지분으로 변환 → 전역 비율만 업데이트 → 인출 시 역변환.”
가스 최적화의 핵심은 “쓰기를 읽기로 바꾸기” - SSTORE는 계산보다 1,000배 비싸다. Scaled Balance 패턴으로 전역 index 하나만 업데이트하고 나머지는 읽기 시점에 계산.
Compound는 Monolithic, Aave는 Modular - CToken이 풀 겸 토큰 vs Pool과 토큰 분리.
실제 수익률 = 기본 이자 + 토큰 인센티브 + 포인트 - 3개 레이어를 모두 봐야 DeFi의 실제 경제를 이해할 수 있다.

Next: Day 2

내일은 Aave V3 아키텍처를 코드 레벨로 들어간다.

Pool.sol, SupplyLogic.sol, BorrowLogic.sol, LiquidationLogic.sol 리딩
Fork Testing으로 Aave V3 메인넷 상태에서 직접 테스트
Fuzz Testing으로 이자율 엣지 케이스 탐색

이 시리즈의 전체 코드와 학습 자료는 lending-protocol-study 레포에서 확인할 수 있다.

DefiDash 시작 계기: Defi Saver for Sui

Thu, 11 Dec 2025 00:00:00 +0000

CURG 13기 활동 중 DefiDash 프로젝트가 시작된 배경과, 레퍼런스인 Defi Saver를 분석한 기록.

Team: curg-13

1. 프로젝트 히스토리

이 프로젝트는 CURG(Crypto United Research Group)라는 한국 블록체인 스터디에서 출발했다. 퇴사 후 13기로 합류했고, 이번 기수의 활동기간은 2025.10.11부터 2026.3.28이었다. DefiDash는 2025.12부터 본격적으로 개발을 시작한 프로젝트다.

초기 방향 탐색

처음에는 Sui Stack(Walrus, Seal, Nautilus, DeepBook 등)을 활용해서 재미있는 것들을 만들어보려 했다. 하지만 팀원들과 나 모두 Sui Stack 자체에 크게 흥미를 잃었다.

간단히 써본 결과, 해당 스택은 커머셜한 Web2 비즈니스를 Web3화하는 방향에 초점이 맞춰진다고 느꼈기 때문이다.

EVM 생태계에서는 필요한 인프라를 유저(커뮤니티)가 직접 개발하고 비즈니스화하면서 상호작용하는 반면, Sui에서는 필요한 인프라를 재단 레벨에서 미리 구상하고 생태계 툴로 자리잡아둔 구조다. 블록체인을 구축하고 개발자를 유치하는 전략적 차이라고 생각한다.

방향성 좁히기

이후 팀원들과의 회의를 통해 초기 방향을 아래 3가지로 좁혔다.

Pendle to Sui + Lucky Gaming — 기존에 Walrus Haultout 해커톤에서 Sui random module을 활용해 나간 경험을 확장
Defi Saver to Sui — Sui에 렌딩 프로토콜이 여럿 있으니 이를 aggregation 하는 것으로 출발
Academic Research in Sui — 오픈소스 Move DeFi 컨트랙트를 분석하면서 EVM과 MoveVM 차이를 비교

약 2주간의 논의를 거쳐, 2025.12.11 시점에 Defi Saver for Sui로 방향을 결정지었다.

2. Defi Saver 분석

Defi Saver란?

Defi Saver를 간단히 말하면, crypto portfolio dashboard + leverage yield farming(looping) 플랫폼이다. 추후 포지션 규모가 크면 자동으로 포지션을 조절해주는 기능도 제공한다.

가령 담보로 맡긴 BTC가 급락하는 경우, liquidation을 방지하기 위해 leverage multiplier를 자동으로 줄여준다는 뜻이다.

Defi Saver 말고도 비슷한 crypto asset dashboard 서비스는 다양하다.

특장점

Safe(Gnosis) Smart Wallet 사용: 처음 접속 시 유저에게 Smart Wallet을 생성하도록 한다.
- Automation 기능 지원을 위해서이며, execTransaction 같은 여러 트랜잭션을 하나로 묶어서 실행하기 위함이다.
- 이걸 보고 Sui에서는 PTB가 네이티브하게 지원되니까 오히려 만들기 편하겠다는 생각을 했다.
Looping 레버리지: 유저가 BTC를 맡기면 LTV에 따라 최대 레버리지까지 USDC를 빌려서 → 그 금액으로 BTC를 다시 사서 → 재예치하는 looping 방식을 지원한다.
직관적인 UX: Liquidation price, 여러 리스크 팩터 등이 한눈에 보인다. 처음에는 별것 아닌 것 같았지만, 막상 만들어보니 이런 디테일한 정보를 잘 관리하고 UX로 풀어내는 게 쉽지 않다는 걸 뒤늦게 알게 되었다.

Defi Saver 직접 사용해보기

아래는 직접 써본 예시다.

가격이 변동함에 따라, 담보 자산(여기선 cbBTC) 상승 시 레버리지 효과를 가질 수 있게 된다.

기본적으로 내 EOA(MetaMask 지갑 주소)에서 호출한 컨트랙트 메소드는 다음과 같다. 해당 rollup tx 안에는 여러 로직이 포함되어 있는 구조다.

1
2
3
4
5


Function: execTransaction(
 address to, uint256 value, bytes data, uint8 operation,
 uint256 safeTxGas, uint256 baseGas, uint256 gasPrice,
 address gasToken, address refundReceiver, bytes signatures
)

Net Transfer로 보면 로직이 보다 명확해진다.

실제 트랜잭션: basescan.org/tx/0x0869a6…

참고로 Defi Saver에서는 Flash Loan으로 빌린 금액의 0.25%를 서비스 수수료로 받는 비즈니스 모델을 가진다.

포지션을 다음과 같이 preview 형태로도 제공해준다.

포지션을 종료하면 기존 로직을 역행하는 과정을 거친다. 기본적으로 looping 과정에서 Morpho Flash Loan을 사용한다.

Close position tx: basescan.org/tx/0xe04ccb…

3. 구조 분석

Leverage Max Multiplier

최대 레버리지 배수는 다음과 같이 결정된다.

$$\text{Max Multiplier} = \frac{1}{1 - \text{LTV}}$$

Leverage 내부 트랜잭션 구조

롤업된 트랜잭션을 의미별로 구조화하면 3가지 컴포넌트로 나뉜다.

Flash Loan — 레버리지에 필요한 초기 자금 확보
Swap — 빌린 스테이블코인을 담보 자산으로 교환
Deposit & Lending — 렌딩 프로토콜에 담보 예치 및 대출

4. DefiDash 프로젝트 구상

위 분석을 바탕으로, 이번 13기 과정에서는 leverage, deleverage(포지션 on/off) 정도만 지원하는 MVP를 만들기로 했다.

각 컴포넌트별로 Sui 생태계에서 사용할 프로토콜을 매핑하면 다음과 같다.

Flash Loan

레버리지 루핑에 필요한 스테이블코인을 어디서 빌려올 것인가?

Scallop
NAVI

Swap (Aggregator / DEX)

Flash Loan으로 빌려온 스테이블코인을 최적 비율로 담보 자산으로 교환할 곳은?

Aftermath
Cetus
7k Protocol

Deposit & Lending

레버리지 포지션의 유지 비용(Supply APR - Borrow APR)이 가장 저렴한 곳은?

Suilend
NAVI
Scallop
Bluefin

Flash Loan 출처가 Scallop이라고 해서 렌딩 프로토콜도 반드시 Scallop일 필요는 없다. 각 컴포넌트는 독립적으로 최적의 조합을 선택할 수 있다.

5. 프로젝트 목표 정의

목표: 3개 렌딩 프로토콜(Suilend, NAVI, Scallop)을 통합하는 leverage lending protocol aggregator 만들기.

최종 워크플로우

PTB 하나에 다음 5단계를 원자적으로 실행한다.

1
2
3
4
5


1. Flash Loan ← Scallop
2. Swap ← 7k Aggregator
3. Deposit ← Lending Protocol (Suilend / NAVI / Scallop)
4. Borrow ← 같은 Lending Protocol
5. Repay ← Scallop (Flash Loan 상환)

각 컴포넌트를 TypeScript SDK 레벨로 먼저 만들어보고, 필요하다면 컨트랙트도 파헤쳐보는 것으로 방향을 잡았다.

프로젝트 완성 후에는 실제 레버리지 포지션을 통해 서비스 이용의 수익성을 검증할 계획이다.

다음 글에서는 실제 SDK 개발에 착수한다. Sui 렌딩 프로토콜의 온체인 데이터 구조를 분석하고, Protocol Adapter 패턴을 설계한 과정을 다룬다.

DefiDash Journal Day 1: 프로젝트 킥오프와 Sui 렌딩 생태계 분석

DefiDash의 전체 코드는 curg-13 조직에서 확인할 수 있다.

Lending on Jeongseup Blog

DefiDash

Role

Description

Tech Stack

Building a Leverage Position Preview for DeFi on Sui

Why Preview Before Leverage?

Glossary: Lending Protocol Concepts

LTV (Loan-to-Value)

Liquidation Threshold (LT)

Max Multiplier

Flash Loan

Supply APY & Borrow APY

Liquidation Price

How It’s Built

Architecture

Multi-Protocol Adapter Pattern

Data Sources

Challenges & Bugs Fixed

Reward APY showing 3700% instead of 1.46%

Scallop risk params not accessible via SDK

Verified Results (2026-02-26, Mainnet)

SUI 2x Leverage

XBTC 2x Leverage

What’s Next

Links

DefiDash Technical Journal Day 1: 프로젝트 킥오프와 Sui 렌딩 생태계 분석

왜 DefiDash인가

프로젝트 구조

defidash-sdk

defidash-frontend

defidash-website

Sui 렌딩 생태계 현황

아키텍처 설계: 어그리게이션 레이어

레버리지 렌딩의 원리

기본 개념

Sui PTB의 이점

Day 1 정리

Next: Day 2

Lending Protocol Study Day 2: Compound V2 Deep Dive와 Aave V3 아키텍처

Day 2 목표

Compound V2 Deep Dive: CToken 상속 구조

Fresh 패턴: “이자부터 정산하고 본론으로”

Mantissa: Solidity의 소수점 해법

Lazy Interest Accrual: 이자는 “필요할 때만” 계산한다

이자 시나리오 시뮬레이션

초기 상태

Alice가 1,000 USDC 대출

100블록 후 이자 정산

렌딩 프로토콜의 3가지 유형

1. Pool-based (Compound, Aave)

2. CDP-based (MakerDAO)

3. Fixed-rate (Yield Protocol)

비교 정리

Aave V3 아키텍처: Compound에서 무엇이 진화했나

delegatecall + Library 패턴

Debt Tokenization

비트맵 스토리지 최적화

Compound V2: 배열 순회

Aave V3: 비트맵

성능 비교

LendingPool 리팩토링: 배운 것을 적용하기

Before: 단순 매핑

After: 구조화된 스토리지

JumpRateModel 테스트: Fuzz Testing까지

Unit Test: 18개 케이스

Fuzz Test: 6개 케이스

Day 2 핵심 인사이트 정리

Next: Day 3

Lending Protocol Study Day 1: DeFi 렌딩의 핵심 개념과 아키텍처

Why Lending Protocol?

렌딩 프로토콜의 본질: 풀 기반 중개

렌딩의 5대 핵심 파라미터

외워야 할 공식 3개

이자율 모델: Jump Rate Model

cToken vs aToken: 이자를 반영하는 두 가지 방법

Compound의 cToken: 교환비율 상승

Aave의 aToken: 잔고 자동 증가 (Rebase)

Share-Based Accounting: DeFi의 범용 패턴

가스 최적화의 핵심: Scaled Balance