Drift Protocol 시리즈 : (2) Drift의 Model Mechanism과 새로운 도약 V2

verse2
verse2
Published in
18 min readOct 19, 2022

1. Drift Protocol
1.1 Model Mechanism
지난 아티클에서는 Drift Protocol의 근간인 DAMM(Protocol의 안정적인 거래환경을 구현하는 메커니즘)과 DLOB(DAMM을 기반으로 지정가 주문을 수행하는 시스템)에 대한 분석을 진행하였습니다. 두 시스템은 Drift의 가장 중요한 요소이지만 On-Chain Perpetual Deravatives는 정교한 기계장치와 같아 수많은 요소가 결합하여 작동하기에 Drift를 이루는 각 구조의 기능적 면모를 분석하려 합니다.

이처럼 전편에선 Mecahnism Overview를 다루었다면 이번편에서는 구체적으로 작동 방식에 대해 알아보도록 하겠습니다.

이어 Smart Contract 이슈에 기인한 V1의 종료 및 새로운 도약을 위한 V2 등 Drift Protocol의 거시적인 흐름에 대해 조망해보겠습니다.

분석에 앞서 기본적인 이해를 위해 간단한 설명을 하자면,
Derivatives는 일반적으로 헷징(위험에 대한 보험) 및 레버리지(포지션 노출 증가)를 위해 사용되며 행사와 만기 개념이 존재하나 Perpetual Futures은 만기가 존재하지 않아 다음과 같은 장점을 가집니다.

  • 유동성 파편화(자본 분산)를 방지
  • Rolling(포지션을 다시 잡는 행위) 비용 감소
  • Spread 및 Gas Fee를 감소

이러한 장점들은 Crypto Derivatives Market이 Perpetual Futures를 중심으로 구축되는데 주요한 역할을 하였습니다.

1.1.1 Margining
담보는 SOL, USDC로 예치 및 출금이 이루어지며, 모든 Perpetual Market과 Linear Perpetual Swaps은 USDC로 환산되어 표기됩니다. Drift Protocol의 Perpetual은 각 계약이 독립된 것이 아닌 Cross-margined (교차 증거금)이 가능하여 동일 계좌 내에서 각 계약의 Profit and Losses를 공유하여 적용할 수 있습니다.

  • 예를 들어 A 계약에서 발생한 손실에 대해 청산당하지 않도록 보증하기 위해 B, C, D 계약에서 발생한 수익을 교차하여 적용할 수 있습니다.
  • Account health formula : Log (Mrcurrent — Mrfull-Liquidation ) / Log(100)
  • Account health는 0~100% 값을 가지며 0%부터 부분적인 청산이 발생하게 됩니다.

1.1.2 Funding Rates
Perpetual Swap은 만기가 없기에 최종 결제 및 정산이 존재하지 않습니다. Funding Rate은 vAMM의 Mark Price를 Oracle Price와 동행할 수 있도록 하는 인센티브 메커니즘입니다.

Perpetual Swap(Mark) Price > Underlying Price = Funding Rate is Positive : (Long > Short 지급)

Perpetual Swap(Mark) Price < Underlying Price = Funding Rate is Negative : (Short > Long 지급)

Drift의 Mark Price가 기초자산 가격을 투사하는 Oracle Price보다 높을 때 Funding Rate은 Long 포지션에서 Short 포지션으로 지급됩니다. 이는 Long 포지션을 취할 유인을 낮추고 Short 포지션에 인센티브를 제공함으로써 균형점으로 회귀하게 합니다. 반대 시나리오 역시 동일한 메커니즘입니다.

Funding Rate 계산은 위와 같으며 Funding Rates 규모는 일정기간 0.12626%로 고정되어 있었습니다.

Drift는 Symmetric Funding Rate을 제공하는 것을 목표로 하며 이를위해 DAMM상 Long — Short 포지션간 불균형이 있을 때 Rebate 풀을 재원으로 사용자들에게 포지션간 Delta를 정산합니다.

1.1.3 PnL
Drift 상에서 유저의 현재 포지션은 시간 동안 발생한 모든 거래(Increasing, reducing, or Closing)의 누계를 나타냅니다. Active trading에서 미실현 PnL과 실현 PnL간 자금을 이동할 수 있으며 가장 중요한 값은
총담보(담보 (Collateral) + 미실현 PnL)입니다.

Drift에서 Free Collateral과 Realised Collateral중 작은 값만 인출이 가능하며 포지션을 종료하거나 줄이는 경우 인출할 수 있는 Realised Collateral이 증가하게 됩니다. 포지션을 유지하며 Realised Collateral을 초과한 미실현 PnL을 인출하기 원하는 사용자는 시장 거래를 통해 재포지셔닝 과정을 거쳐야합니다. Drift는 시장에서 거래 없이 Unrealised PnL을 정산할 수 있도록하는 메커니즘을 개발중입니다.

1.1.4 Oracle
Drift는 Oracle 기반 문제에 대한 여러 안전장치를 가지고 있으며 현재 Pyth와 Swithboard를 Oracle 소스로 활용하고 있으나 이는 시장 상황에 따라 조정될 수 있습니다.

a. Validity Check
Protocol의 안전성을 위해 Oracle 유효성을 검증하며 조건 중 하나에 해당할 경우 오류값이 반환되어 정해진 메커니즘이 작동하게 됩니다.

  • 기존 데이터 (최신 Slots 업데이트가 너무 늦어 현재 시장가를 반영하지 못함 (120 Slots))
  • 신뢰구간 문제 (가격에 대한 신뢰구간이 과도하게 증가 (> 25%)
  • 음수 가격 (모든 가격 필드 < 0)
  • 과도한 가격변동성 ((TWAP / 가격 비율)이 범위를 벗어남 : 50%)

Drift의 메커니즘에 따라 시장의 Liquidations과 Funding Rate 업데이트가 종료되며 잘못된 결제 규모를 산정하는 것을 방지하기 위해 온체인 Oracle twap 계산도 유효하지 않은 기간에 비례하여 축소됩니다.

b. Liquidation Protection
Oracle Price와 Mark Price의 가격 차이가 크고 ( > 10%, [(oracle — mark) / Oracle] > 10%) Oracle Price가 유효하다면 Liquidation이 일시적으로 중단됩니다.

Orcale Mechanism

청산의 허용과 중단에 대한 전체 로직은 위와 같습니다. Oracle Mark Divergence > 10% 상황에서 Divergency를 줄이는 방향으로 작동하지 못한다면 청산은 허용되지 않으며 < 10% 상황에서도 liqudity territory를 벗어난 Slippage가 발생하는 상황에선 청산은 중단됩니다.

c. Price Manipulation Prevention (가격 조작 방지)
Drift의 Clearinghouse는 Oracle Mark Divergence를 더욱 증가시키는 위험 거래를 일시 중지시킵니다. Divergency가 이미 깨진 경우를 제외하곤 해당하는 상황에서 포지션을 닫거나 줄이는 것도 허용되지 않습니다.

1.1.5 Perpetual Order Types
a. Market Orders 시장가 주문
시장가 주문은 주어진 자산을 현재 시장 가격으로 즉시 구매하거나 판매하는 일반적인 주문입니다. 주문자는 Slippage 허용오차(.1%, .5%, 1%, inf)를 설정할 수 있으며 제한 가격(Slippage 설정값)까지 주문을 실행할 수 없는 경우 주문이 실행되지 않고 취소됩니다.

b. Limit Orders 지정가 주문
해당 주문은 DAMM을 상대로 특정 조건(Mark Price가 특정한 트리거나 가격에 도달 등)이 충족될 때 키퍼 봇에 의해 실행됩니다. 사용자가 조건을 설정한 후 시장 가격이 조건을 충족하게되면 제한 가격까지 주문이 실행됩니다.

c. Advanced Orders

  • Stop Market Orders:
    자산의 Mark Price가 지정된 Trigger Price에 도달할 경우 해당 자산의 포지션을 닫는 주문입니다. 사용자가 Trigger Price를 지정하고 키퍼 봇은 해당 지점에 도달 시 주문을 실행하여 포지션을 시장 가격으로 마감합니다.
  • Stop Limit Orders:
    지정된 자산의 Mark Price가 Trigger Price에 도달한 경우 실행되는 주문입니다. 사용자가 Trigger Price와 Limit Price를 지정하고 Trigger Price에 Mark Price가 도달하게 되면 Keeper에 의해 지정가 주문이 실행됩니다.
  • Take Profit Orders: Stop Market Orders와 동일한 메커니즘이나 수익을 실현하기 위해 사용됩니다.
  • Take Profit Limit Orders: Stop Limit Orders와 동일한 메커니즘입니다.

즉, Stop은 일정부분 손실을 방지하기 위한 안전장치로, Take Profit은 수익 실현을 위한 장치로 사용됩니다. 아래와 같은 작동 조건을 가지며 Limit Orders는 일정 범위내에서 수익을 실현할 수 있도록 하는 보조장치와 같습니다.

d. Order Flags

  • Reduce only : 포지션을 줄이는 주문으로 해당 옵션을 적용하면 포지션 증가가 발생하지 않습니다.
  • Post only : 유동성을 제공할 수 있는 Maker order로 교환 수수료(0%)를 줄일 수 있습니다.
  • Immediate or cancel (IOC) : 주문이 접수되고 즉시 체결되지 않은 부분은 취소되게 됩니다.

1.1.6 Fees & Rebates
Drift Protocol은 10 Taker 거래당 10bps를 청구(POST flag가 명시적으로 설정되지 않은 모든 주문)하며 Maker에게 최대 5bps를 지급합니다. 거래 별 수수료는 포지션 규모에 기반해 사용자의 담보 계정에서 직접 차감하여 Funding Rate, Repeg, K Increase등을 위해 사용됩니다.

예를 들어, 유저가 SOL — PERP에서 $10,000 USD 포지션을 취하는 경우 거래 수수료는 0.1% * $10,000 = $10입니다. 사용자가 $10,000 포지션에 대한 메이커 주문(Limit order + POST flag)을 개시하는 경우 거래 Rebate는 최대 0.05% * $10,000 = $5입니다.

1.1.7 Liquidations
a. Liquidations
Drift Protocol 내에서 부분 및 전체 청산은 아래 조건에 따라 청산봇에 의해 이루어집니다.

- Liquidation Type : Partial, Full
-전체 청산을 방지하기 위해 부분적인 청산 모델이 우선하여 적용됩니다.
- Liquidation Margin Ratio : 부분 또는 전체 청산에 적용되는 사용자의 마진
비율입니다. 마진 비율 = 총담보 / 공개 포지션의 총합입니다.
- % of Positions Closed : Margin Ratio 기준이 충족될 때까지 청산이 진행되는 비율입니다.
- Liquidation Penalty : 청산 시 사용자의 남은 담보에서 가져오는 Collateral Penalty 비율입니다.
- % Given to Liquidators : 시스템의 Liquidation Penalty는 Drift의 보험 기금 및 청산인에게 분배됩니다.

이를 통해 protocol의 미래 잠재적 파산을 방지하고 시스템에서 발생하는 청산을 처리하기 위한 봇을 운영하는 청산인을 확보할 수 있게 됩니다.

b. Liquidation Price and Margin Ratio Calculation
정상적인 조건에서, 마진 비율 계산은 이론상 Mark Price after Closing(Exit Price)을 사용하여 총담보 및 오픈된 포지션의 마진 비율을 계산합니다.

Oracle-mark divergence > 3.33%일 때, 1) Drift Market slippage oracle 2) Mark Price after Closing 중 잘못된 청산을 방지하기 위해 더 나은 수치가 포지션을 평가하는 데 사용됩니다. Oracle error a, b 메커니즘에 따라 Liquidations과 Funding Rate updates는 종료될 수 있습니다.

2. Drift version 2

이처럼 정교하게 기획된 Drift Protocol은 Perpetual Marketplace로서 우위를 보이며 높은 거래량을 기록했습니다. 하지만 지난 Terra 생태계의 $LUNA와 $UST의 Death Spiral 상황에서 파생된 Smart Contract Issue로 인해 2022년 5월 서비스를 일시적으로 중단하였고 현재 V2의 오픈을 앞두고 있습니다.

3.1 Smart Contract Issue
1) Protocol에 담보 자금에 관한 정산 문제가 발생하여 유저가 Positive realised PNL을 인출하는데 필요한 동일한 금액의 Negative realised PNL 없이 출금이 진행되었습니다. AMM 메커니즘은 제로섬 정책으로 수익과 손실이 서로 상쇄되도록 하는 정산 절차를 가지고 있지만 순차적으로 이루어지진 않습니다. LUNA 가격이 급락한 사태에서, 수익을 본 사용자가 매도 포지션을 청산하여 플러스 손익 정산을 진행한 후에야 손실을 본 사용자의 매수 포지션 청산이 이루어짐으로써 제로섬 균형에 도달하기 전에 출금이 이루어졌습니다. 이에 따라 Protocol에서 전례 없는 레버리지 손실이 발생했습니다.

2) 정산 문제 이외에도 Insurance Fund에서 잘못된 인출이 발생하였습니다. 거래상대방의 지급 한도를 초과하는 상황에서 Protocol의 안정성을 유지하기 위한 Backstop 장치였으나, 매도 포지션 사용자들의 출금이 해당 기금에서 직접적으로 이루어졌습니다. 이로인해 Protocol의 Insurance Fund가 빠르게 고갈되었으며, 시장의 포지션 정산과 DAMM 조정이 불가능하게 되었습니다.

3) 또한 Drift는 Long-Short 불균형이 증가하는 상황(mark price와 terminal price 간 diverge)에서도 동일한 Leverage 비율을 제공하였습니다. Long-Short 불균형이 증가하는 상황에서 허용되는 레버리지 비율을 줄여야 했으나 일관된 비율을 제공하였고 이는, 거래소의 담보금을 기반으로 인출되는 금액을 증폭시키는 결과를 만들었습니다.

종합해보면 높은 레버리지 비율에 기반해 플러스 손익을 본 Short 포지션의 정산이 AMM 제로섬을 충족하지 않더라도 이루어졌고, 정산된 금액의 인출이 Insurance Fund에서 직접적으로 진행되었습니다.

이처럼 각 측면에서 발생한 이슈로 인해 Drift Protocol은 거래를 일시 중단한 후 전체 포지션을 종료하였으며 총 $19.55M(Insurance Fund $4.55M, financing $15M)을 사용자에게 정산 완료하였습니다.

3.2 V2 New Feature
Drift Protocol의 V2는 기존 V1에서 기존 문제가 발생했던 부분의 수정을 넘어 사용자에게 더 나은 거래 환경을 제공하기 위해 개선된 메커니즘을 제시합니다.

3.2.1 Liquidity Sector
a. JIT(Just-In-Time) Liquidity Mechanism

기존 DAMM의 유동성을 보완하기 위해 V2에서 JIT(Just-In-Time) Liquidity Mechanism을 새로 도입하였습니다. 새 구조는 기존의 DAMM 메커니즘 전체의 수정은 아니며 거래 체결에 관련된 새로운 유동성 보완 메커니즘입니다.

  • 1) 트레이더가 유동성 풀에 taker order를 넣습니다.
  • 2) taker order는 Drift’s Keeper Network에 기록되어 관리됩니다.
  • 3) Market maker는 ((DAMM_bid * (X-t) + DAMM_est_entry * t) /X) 식에 기반한 메이커 쿼트를 제공하여 taker order를 체결합니다.
  • 4) JIT Price는 5초간 변동하며, take order는 트레이더가 설정한 최대 Slippage 가격 범위내에서 Oracle Price(t=0)로 시작하여 DAMM Price(t=5)까지 순차적으로 체결됩니다.
  • 5) 오더에 대한 Market maker의 수요가 충분하지 않아 거래가 종료되지 않은 경우, t=5에서 남은 오더는 DAMM Liquidity에 기반해 이루어집니다.

기존 taker order가 일시에 DAMM에서 체결된 것과 다르게 JIT 구조를 통해 순차적으로 거래가 체결되게 함으로써 Taker와 Maker 양 측면에 Incentive를 부여하는 동시에 DAMM의 변동성을 완화하게 됩니다.

b. Passive Liquidity Pool
Drift v2에서 유저는 DAMM perpetual market에 유동성을 공급할 수 있으며, 공급된 LP는 DAMM의 Net 포지션에 관계없이 발생하는 새로운 거래에 대해 반대 포지션을 취하게 됩니다. LP는 사용자의 레버리지를 위해 사용될 수도 있으나 안정적인 거래 환경을 구축하기 위해 중점적으로 사용됩니다.

구체적으로 공급된 LP는 Protocol의 담보자산을 늘리는 동시에 DAMM의 k 값을 증가시켜 AMM 상의 Liquidity depth를 높임으로써 전체적인 Slippage를 감소시킵니다. 이에 대한 대가로 유동성 공급자는 거래에서 발생하는 수수료(90%)와 Funding rate의 일부를 받습니다.

3.2.2 Trading sector
a. Smart Market Maker

기존 V1에서 Oracle Price를 반영하는 다양한 안전장치가 존재하였으나, 극단적인 변동성을 감안하지는 못하였습니다. V2에서는 Smart Market Maker 메커니즘을 통해 Mark Price와 Oracle Price 간 가격이 일치할 수 있도록 DAMM의 Peg 값을 조정하고 변동성, inventory skew, Volatility, Oracle Mechanism에 기반해 Basic Spread를 재조정합니다. 이는 Spread 값을 거래소가 선제적으로 설정하는 것으로 Net 포지션 입장에서 Funding Rate이 실제 Long/Short 포지션에 맞춰 변동하는 것보다 유리하게 작용합니다.

이러한 개선을 통해 유저들이 Funding Rate Incentive를 위해 Mark Price와 Oracle Price 간 Spread를 줄여 DAMM의 균형을 달성하도록 유도하며, 무엇보다 Long/Short 간 미결제 약정 밸런스를 유지함으로써 막대한 시장 변동에 직면한 상황에서도 균형 있는 정산이 이루어지도록 돕습니다.

- 다양한 변수에 따른 Protocol의 base_asset-amount와 Total Fees의 변동 그래프

b. Protocol collateral
기존 V1 담보 시스템을 확장하여 V2에서는 $USDC 이외의 자산을 지원할 예정입니다. Protocol에서 고려 중인 자산은 SOL, BTC, ETH 등이 있으며 다양한 담보 자산을 지원하게 되는 경우 Protocol 내에서 자산간 차입 및 대출의 실현도 가능해질 것입니다. 결과적으로 Protocol 내 담보 자산의 총량을 증가시킴으로써 안정성과 유저 확장 측면에서 강점을 확보하며, 자신의 포지션을 유지한 채로 시장 참여가 가능해집니다.

자체적인 Token Incentive 구조 없이 완성도 높은 DeFi Marketplace를 구현했다는 점에서, Drift는 새로운 패러다임으로 작용할 잠재력을 가지고 있습니다. Solana의 대표적인 DeFi Derivatives Protocol로서 긴 기간 사랑을 받아온 만큼 V2 출시와 함께 맞이할 새로운 도약은 더욱 기대해볼 만합니다.

본 글은 verse2에서 제공하는 Drift Protocol 시리즈 (2) Drift의 Model Mechanism과 새로운 도약 V2입니다. Drift Protocol시리즈를 읽기 원하신다면 아래의 리스트를 참조하십시오. 시리즈의 경우 순차적으로 글을 읽는 것을 권장드립니다.

1. (1) Drift, DAMM과 DLOB 기반 Decentralized Derivatives Exchange
2. (2) Drift의 Model Mechanism과 새로운 도약 V2

verse2는 Web3 프로덕트 개발에 전문화된 팀이자, 잠재력 있는 Web3 프로젝트를 위한 인큐베이터입니다. 팀은 Crypto Finance 분야에 대한 심층적인 지식과 경험을 보유하고 있습니다.

verse2 [Homepage | Twitter | Medium]

--

--

verse2
verse2
Editor for

Build, incubate, invest — Making all possible in the crypto. / verse2.io