DeFi 카테고리와 가치포착 모델
도입
DeFi 카테고리는 단순한 메뉴 이름이 아니다. DEX, lending, derivatives, stablecoin, vault, restaking은 각각 돈이 들어오고 나가며 위험이 전이되는 방식이 다르다. 같은 "수수료"라는 단어도 DEX에서는 LP 보상일 수 있고, lending에서는 borrower가 내는 이자일 수 있으며, perps에서는 funding payment처럼 long과 short 사이에서 직접 이동하는 값일 수 있다.
교육 자료에서 카테고리를 먼저 잡는 이유는 이후 강의가 흩어지지 않게 하기 위해서다. Uniswap v4 hook, Aave liquidation, Hyperliquid funding, RWA vault NAV를 모두 한 화면에 올리면 복잡해 보인다. 그러나 actor, revenue event, balance sheet, failure mode로 나누면 같은 틀에서 읽을 수 있다.
학습 목표
- DEX, lending, derivatives, stablecoin, RWA, restaking의 수익 모델을 구분한다.
- 사용자 가치와 protocol value capture가 같은 말이 아니라는 점을 설명한다.
- protocol fee, LP fee, liquidation bonus, spread, funding, vault fee를 이벤트 단위로 태깅한다.
개념 설명
이 protocol의 핵심 상태 변수는 무엇인가?
swap, pool, liquidity, slippage가 중심이다
collateral, LTV, health factor, liquidation이 중심이다
margin, funding, open interest, liquidation price가 중심이다
share, NAV, maturity, redemption queue가 중심이다
| 카테고리 | 사용자 가치 | 수수료 이벤트 | 주요 위험 |
|---|---|---|---|
| DEX/AMM | 즉시 교환과 가격 발견 | swap fee, protocol fee | slippage, MEV, LP loss |
| Lending | 담보 기반 차입과 이자 수익 | borrow interest, reserve factor | oracle, liquidation, bad debt |
| Perps | 레버리지와 hedging | trading fee, funding payment | margin, funding squeeze, oracle divergence |
| Vault/Yield | 전략 위임과 자동 복리 | management fee, performance fee | share price drift, strategy loss |
| RWA | 오프체인 cashflow 접근 | servicing fee, redemption spread | legal claim, NAV lag, liquidity gate |
| Restaking | security service exposure | reward, operator fee | slashing, correlated dependency |
가치포착을 볼 때는 "사용자가 낸 돈"과 "프로토콜이 가져가는 돈"을 분리한다. DEX swap fee는 대부분 LP에게 갈 수 있고 일부만 protocol fee로 전환될 수 있다. Perp funding은 protocol revenue가 아니라 long과 short 사이의 peer-to-peer transfer일 수 있다. Lending interest는 supplier yield와 reserve factor로 나뉜다. 이 차이를 무시하면 protocol의 지속 가능성, 사용자 비용, 리스크 보상 수준을 모두 잘못 평가한다.
코드로 확인하기
type FeeEvent = | { kind: "swap"; grossFeeUsd: number; protocolShareBps: number } | { kind: "borrow_interest"; interestUsd: number; reserveFactorBps: number } | { kind: "funding"; paymentUsd: number; payerSide: "long" | "short" } | { kind: "vault_performance_fee"; profitUsd: number; feeBps: number };export function classifyValueCapture(event: FeeEvent) { switch (event.kind) { case "swap": return { userCostUsd: event.grossFeeUsd, protocolRevenueUsd: (event.grossFeeUsd * event.protocolShareBps) / 10_000, recipient: "LP and protocol treasury" }; case "borrow_interest": return { userCostUsd: event.interestUsd, protocolRevenueUsd: (event.interestUsd * event.reserveFactorBps) / 10_000, recipient: "supplier and reserve" }; case "funding": return { userCostUsd: event.paymentUsd, protocolRevenueUsd: 0, recipient: event.payerSide === "long" ? "short traders" : "long traders" }; case "vault_performance_fee": return { userCostUsd: (event.profitUsd * event.feeBps) / 10_000, protocolRevenueUsd: (event.profitUsd * event.feeBps) / 10_000, recipient: "vault manager" }; }}// SPDX-License-Identifier: MITpragma solidity ^0.8.24;library FeeRouter { struct Split { uint256 lpAmount; uint256 treasuryAmount; } function splitSwapFee(uint256 grossFee, uint16 protocolShareBps) internal pure returns (Split memory) { require(protocolShareBps <= 10_000, "bad share"); uint256 treasury = grossFee * protocolShareBps / 10_000; return Split({ lpAmount: grossFee - treasury, treasuryAmount: treasury }); }}TypeScript 함수는 funding을 protocol revenue로 잘못 잡지 않게 한다. Solidity library는 gross swap fee가 treasury와 LP 사이에서 어떻게 나뉘는지를 명시한다. 교육용 코드지만 중요한 습관을 담고 있다. fee event는 항상 payer, recipient, protocol share, accounting period를 함께 가져야 한다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| Actor | 누가 돈을 내고 누가 받는가 | payer, receiver, treasury split |
| Balance sheet | protocol이 재고나 부채를 갖는가 | pool reserve, debt, share supply |
| Revenue | gross fee와 protocol revenue가 다른가 | fee split rule |
| Risk | 수익이 어떤 손실 가능성을 보상하는가 | slippage, liquidation, funding, slashing |
실무 예시
백엔드[OPS] "perps volume이 늘었으니 protocol revenue도 늘었다"는 문장은 검증 전에는 쓸 수 없다. 거래량이 늘면 trading fee는 늘 수 있지만, funding payment는 trader 사이에서 오갈 수 있다. maker rebate, referral, incentive도 gross fee와 net revenue를 갈라놓는다.
운영 대시보드는 이벤트를 카테고리별로 받되 동일한 revenue table에 넣는다. 단, event_kind, payer, recipient, protocol_revenue_usd, user_cost_usd를 분리한다. 이렇게 하면 다음 강의에서 AMM과 lending을 비교할 때 "어느 쪽이 돈을 더 많이 버는가"가 아니라 "어느 위험을 어떤 방식으로 가격화하는가"로 질문이 바뀐다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 교정 방식 |
|---|---|---|
| 모든 fee는 protocol revenue다 | LP 보상과 treasury 수입을 합쳐 과대평가한다 | gross fee, supply-side revenue, protocol revenue를 분리한다 |
| 카테고리는 UI 메뉴다 | 같은 protocol이 vault, lending, DEX 기능을 동시에 가질 때 놓친다 | 핵심 상태 변수로 분류한다 |
| 높은 yield는 좋은 가치포착이다 | yield가 subsidy, leverage, maturity risk에서 온 것인지 숨겨진다 | yield source와 loss path를 함께 기록한다 |
| funding은 수수료다 | peer-to-peer transfer를 protocol revenue로 기록한다 | payerSide와 recipient를 태그로 남긴다 |
실습 과제
- 수익 모델 분류표 만들기: 5개 이상 DeFi 카테고리를 actor, 사용자가 얻는 가치, 수수료 이벤트, 주요 위험으로 나눈다.
- 프로토콜 이벤트 태그 설계하기: swap fee, borrow interest, liquidation bonus, funding payment를 fee event로 입력받아 revenue type을 반환하는 함수를 작성한다.
완료 기준
- 최소 5개 DeFi 카테고리를 actor, revenue event, main risk로 나눈 표를 만들었다.
- fee event가 사용자 비용인지, LP 보상인지, protocol revenue인지 구분하는 태그 규칙을 작성했다.
근거 자료
- 01 Market Overview
- 03 DEX and AMM
- DefiLlama Methodology