페그, 유동성, 슬리피지

도입

스테이블코인이 1달러를 목표로 한다고 해서 모든 순간 1달러로 정산되는 것은 아니다. 사용자는 결제 화면에서 100 USDC를 보냈다고 생각하지만, merchant는 결국 어떤 자산으로 얼마를 받을지 확인해야 한다. 이 간격이 peg, liquidity, slippage의 실무 문제다.

이 강의는 "스테이블코인은 1달러다"라는 문장을 네 개의 가격으로 쪼갠다. Face value, redeem value, market price, executable price가 서로 다르면 checkout, refund, treasury, merchant settlement 정책도 달라져야 한다.

학습 목표

• 페그 이탈과 유동성 부족을 사용자 경험 관점으로 설명한다.
• 스왑 경로와 주문 크기에 따른 슬리피지 리스크를 점검한다.
• oracle price, market price, executable price를 정산 정책으로 연결한다.

개념 설명

1. 네 가지 가격을 분리한다

결제 제품은 하나의 priceUsd 필드로 모든 판단을 하면 안 된다. 가격은 사용 목적마다 다르다.

예를 들어 oracle price가 1.0000달러이고 market mid price가 0.9990달러여도, 100만 달러를 특정 L2 pool에서 USDC로 바꾸는 executable price가 0.9920달러라면 merchant settlement는 손실을 본다. Checkout은 명목 가격보다 실행 가격을 기준으로 고액 결제 한도를 정해야 한다.

2. Peg가 흔들리는 이유를 원인별로 읽는다

원인이 다르면 대응도 다르다. Issuer redemption 지연은 disclosure와 withdrawal policy 문제이고, pool liquidity 부족은 route limit과 quote expiry 문제다. Bridge/CCTP 지연은 사용자가 기다리는 상태를 어떻게 보여줄지의 문제다.

3. AMM에서는 주문 크기가 가격을 만든다

Uniswap 문서는 swap에서 price impact와 slippage를 사용자에게 보여줘야 하는 요소로 다룬다. 결제 시스템도 같은 원리를 쓴다. AMM pool liquidity가 얕으면 작은 주문도 가격을 움직이고, 큰 주문은 route를 쪼개거나 제한해야 한다.

결제 제품에서는 receivedAmount와 settledValue를 분리한다. 사용자가 100,000 PYUSD를 보냈더라도 merchant에게 USDC로 정산할 때 route output이 99,650 USDC라면 누가 350달러 차이를 부담하는지 정책이 필요하다.

4. Slippage 보호는 UX가 아니라 회계 장치다

Slippage tolerance는 단순히 swap 실패를 줄이는 옵션이 아니다. 결제에서는 손익 귀속을 정하는 회계 장치다.

정책은 자산별로 달라야 한다. Fiat-backed stablecoin, synthetic dollar, crypto-backed stablecoin은 depeg 원인이 다르기 때문이다. 한 자산의 0.5% discount는 일시적 pool imbalance일 수도 있고, issuer/redemption 신뢰 훼손 신호일 수도 있다.

5. Uniswap v4 Hooks route는 별도 검토한다

Uniswap v4 hooks는 pool lifecycle의 특정 시점에 custom logic을 붙일 수 있다. 동적 수수료, limit order, custom accounting 같은 설계가 가능하지만, 결제 시스템이 hook pool을 route로 쓸 때는 hook contract가 어떤 동작을 하는지 반드시 확인해야 한다.

Uniswap v4 공식 문서는 hooks가 pool, swap, fee, liquidity position 동작을 커스터마이즈할 수 있고 beforeSwap, afterSwap 같은 지점에서 실행될 수 있다고 설명한다. 또 Uniswap support 문서는 hooks가 제3자 개발자에 의해 만들어질 수 있으므로 주의가 필요하다고 안내한다. 결제 route가 hook pool을 통과하면 "토큰 A를 B로 바꾼다" 외의 로직이 실행될 수 있다는 뜻이다.

6. 결제 수락 정책은 threshold로 남긴다

Threshold는 절대값이 아니라 product policy다. Retail checkout은 낮은 한도와 짧은 quote expiry를 둘 수 있고, B2B settlement는 더 엄격한 route simulation과 manual approval이 필요하다.

7. 결제 금액별 route simulation을 만든다

이 표는 실습에서 실제 숫자로 채워야 한다. 숫자를 넣지 않은 "유동성이 충분하다"는 말은 강의 산출물로 인정하지 않는다.

코드로 확인하기

위 설계 결정을 코드에서 확인한다. 상태, 서명, 원장 이동, 실패 처리가 어디에 놓이는지 따라 읽으면 앞의 모델이 실제 구현 경계로 내려온다.

백엔드Quote 단계에서 slippage 보호 — 결제 금액별 분기

결제 직전에 chain DEX quoter를 호출해 expected output을 확인하고, max slippage를 넘으면 결제를 거절한다. Uniswap V3 QuoterV2 예시.

01import { createPublicClient, http, parseAbi } from "viem";02import { base } from "viem/chains";0304const quoterAbi = parseAbi([05  "function quoteExactInputSingle((address tokenIn, address tokenOut, uint256 amountIn, uint24 fee, uint160 sqrtPriceLimitX96)) view returns (uint256 amountOut, uint160 sqrtPriceX96After, uint32 initializedTicksCrossed, uint256 gasEstimate)"06]);0708const QUOTER_V2 = "0x3d4e44Eb1374240CE5F1B871ab261CD16335B76a";0910export async function getQuoteWithSlippage(args: {11  tokenIn: `0x${string}`;12  tokenOut: `0x${string}`;13  amountIn: bigint;14  fee: 100 | 500 | 3000;15}) {16  const client = createPublicClient({ chain: base, transport: http() });17  const [amountOut] = await client.readContract({18    address: QUOTER_V2, abi: quoterAbi, functionName: "quoteExactInputSingle",19    args: [{20      tokenIn: args.tokenIn, tokenOut: args.tokenOut,21      amountIn: args.amountIn, fee: args.fee, sqrtPriceLimitX96: 0n22    }]23  });2425  const expectedAt1to1 = args.amountIn; // stablecoin <-> stablecoin 가정26  const deltaBps = Number(((expectedAt1to1 - amountOut) * 10_000n) / expectedAt1to1);2728  return { amountOut, slippageBps: deltaBps };29}

백엔드결제 금액별 정책 — 자동/경고/수동

retail/mid/B2B 세 구간에 다른 정책. quote가 만료되기 전에 결제 트랜잭션을 보내야 하므로 quote_expires_at 도 저장한다.

01type PaymentDecision =02  | { kind: "auto-execute"; route: "direct-pool" }03  | { kind: "warn-user"; reason: string }04  | { kind: "block"; reason: string }05  | { kind: "manual-review"; reason: string };0607export function decidePayment(args: {08  amountUsd: number;09  slippageBps: number;10  pegDeviationBps: number;11  poolImbalance: number; // [-1, 1]12}): PaymentDecision {13  if (args.pegDeviationBps > 100) {14    return { kind: "block", reason: `peg deviated by ${args.pegDeviationBps}bps` };15  }16  if (args.amountUsd >= 100_000) {17    if (args.slippageBps > 30) {18      return { kind: "manual-review", reason: `B2B size + slippage ${args.slippageBps}bps` };19    }20    return { kind: "manual-review", reason: "B2B size — operator approval required" };21  }22  if (args.amountUsd >= 10_000) {23    if (args.slippageBps > 30) return { kind: "warn-user", reason: `slippage ${args.slippageBps}bps` };24    return { kind: "auto-execute", route: "direct-pool" };25  }26  if (args.slippageBps > 100) return { kind: "block", reason: `excessive slippage ${args.slippageBps}bps` };27  return { kind: "auto-execute", route: "direct-pool" };28}

인덱서페그 이탈 5분 평균 감지 — SQL

chain별·token별 1분 ticker에서 1분/5분/30분 이동 평균을 비교해 깊은 depeg을 감지한다.

01WITH minutely AS (02  SELECT03    token_symbol,04    chain_id,05    DATE_TRUNC('minute', observed_at) AS minute,06    AVG(price_usd) AS avg_price07  FROM stablecoin_ticks08  WHERE observed_at >= NOW() - INTERVAL '30 minutes'09  GROUP BY token_symbol, chain_id, DATE_TRUNC('minute', observed_at)10),11windows AS (12  SELECT13    token_symbol,14    chain_id,15    AVG(avg_price) FILTER (WHERE minute >= NOW() - INTERVAL '5 minutes')  AS p5m,16    AVG(avg_price) FILTER (WHERE minute >= NOW() - INTERVAL '30 minutes') AS p30m17  FROM minutely18  GROUP BY token_symbol, chain_id19)20SELECT21  token_symbol,22  chain_id,23  p5m,24  p30m,25  (p5m - 1.0) * 10000 AS deviation_5m_bps,26  CASE27    WHEN ABS(p5m - 1.0) > 0.01 THEN 'critical'28    WHEN ABS(p5m - 1.0) > 0.005 THEN 'warning'29    ELSE 'ok'30  END AS severity31FROM windows;

강의 포인트

실무 예시

백엔드[INDEXER] 상황: 사용자가 100만 달러 상당의 stablecoin으로 결제했고, merchant는 USDC로 정산받기를 원한다. Oracle price는 1달러지만, 해당 chain의 DEX route는 output이 0.992달러 수준이다.

이 예시의 핵심은 결제 성공과 정산 성공이 다르다는 점이다. 사용자의 transfer가 확인되어도 merchant settlement는 route liquidity와 executable price에 의존한다. 그래서 checkout 원장에는 paidAmount, quotedSettlementAmount, actualSettlementAmount, slippageLossOwner가 필요하다.

흔한 오해와 실패 시나리오

실습 과제

1. 백엔드네 가지 가격 분리표 만들기: face value, redeem value, market price, executable price를 각각 어떤 source에서 얻고 checkout/refund/settlement에 어떻게 쓰는지 표로 정리한다.
2. 백엔드결제 금액별 route simulation 만들기: 1,000달러, 10만달러, 100만달러 결제를 3개 chain과 3개 swap route로 비교하고 output amount, price impact, max slippage, route disable 조건을 적는다.
3. 운영Depeg 대응 runbook 작성하기: market price, executable price, pool imbalance, issuer redemption delay가 각각 threshold를 넘을 때 신규 결제, 고액 결제, 환불, merchant settlement를 어떻게 바꿀지 작성한다.

완료 기준

1. 페그와 유동성의 차이를 설명한다.
2. 슬리피지 보호 조건을 정했다.
3. depeg 대응 정책을 작성했다.
4. 결제 금액별 quote, max slippage, route disable 조건을 정의했다.

근거 자료

• 페그 유동성 슬리피지: 01-스테이블코인/12-페그-유동성-슬리피지.md
• Uniswap Docs: Swaps: https://developers.uniswap.org/docs/get-started/concepts/traders/swaps
• Uniswap v4 Hooks Concepts: https://developers.uniswap.org/contracts/v4/concepts/hooks
• Uniswap v4 Swap Hooks: https://developers.uniswap.org/contracts/v4/quickstart/hooks/swap
• Uniswap Support: What is a hook on Uniswap v4?: https://support.uniswap.org/hc/en-us/articles/30998263256717-What-is-a-hook-on-Uniswap-v4
• Chainlink Proof of Reserve: https://chain.link/proof-of-reserve