Oracle·Liquidation Simulator Lab
도입
Oracle adapter와 liquidation bot을 따로 만들면 학습 효과가 반으로 줄어든다. 실제 lending protocol에서 liquidation은 price validation 결과를 바로 사용한다. 가격이 stale이면 liquidation을 멈춰야 할 수 있고, 가격이 급변하면 candidate queue가 폭증할 수 있다.
이 실습은 oracle validation, health factor, liquidation quote, profit after gas를 하나의 simulator로 묶는다. 목표는 정답 코드를 복사하는 것이 아니라 어떤 입력이 어떤 운영 상태를 만드는지 직접 관찰하는 것이다.
학습 목표
- oracle price validation과 health factor 계산을 같은 simulator에 연결한다.
- liquidation candidate, repay amount, seized collateral, profit after gas를 계산한다.
- stale price와 thin liquidity가 liquidation queue에 미치는 영향을 실험한다.
개념 설명
PriceValid
전이 조건을 확인한다.
RiskScored
전이 조건을 확인한다.
CandidateQueued
전이 조건을 확인한다.
ExecutionPlanned
전이 조건을 확인한다.
OracleBlocked
전이 조건을 확인한다.
| 입력 | simulator 결과 | 운영 행동 |
|---|---|---|
| fresh price | HF 계산 | queue update |
| stale price | liquidation block | oracle incident alert |
| ETH shock | candidate 증가 | keeper capacity check |
| stablecoin depeg | debt/collateral 재평가 | new borrow gate |
코드로 확인하기
export function simulateLiquidation(account, price, threshold) { if (!price.fresh) return { status: "oracle-blocked", candidates: [] }; const hf = (account.collateral * price.usd * threshold) / account.debtUsd; if (hf >= 1) return { status: "safe", healthFactor: hf }; const repayUsd = Math.min(account.debtUsd * 0.5, account.debtUsd); const seizedUsd = repayUsd * 1.05; return { status: "liquidatable", healthFactor: hf, repayUsd, seizedUsd };}shock_scenarios: - name: eth_down_10 price_multiplier: 0.9 expected: queue_growth - name: stablecoin_depeg debt_price_multiplier: 1.03 expected: hf_drop - name: oracle_stale fresh: false expected: liquidation_blocked이 코드는 실제 protocol보다 단순하지만 simulator가 무엇을 해야 하는지 보여준다. price validation과 liquidation 판단이 분리되면 사고 대응이 가능해진다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| Oracle | 가격 입력이 유효한가 | validation result |
| Queue | 누가 청산 대상인가 | candidate list |
| Profit | liquidator가 실행할 유인이 있는가 | repay, seized, gas |
| Scenario | 충격 시 어떤 상태가 바뀌는가 | shock report |
실무 예시
인덱서[OPS] ETH 가격이 10% 떨어졌다. simulator는 단순히 몇 명이 청산되는지 세는 도구가 아니다. 어떤 담보 cluster가 위험한지, keeper capacity가 충분한지, price feed가 fresh한지, 사용자에게 어떤 notice를 보여야 하는지 같이 보여준다.
stale price가 감지되면 liquidation을 무조건 실행하면 안 된다. simulator는 oracle-blocked 상태를 만들어야 한다. 그래야 사고 때 "왜 청산이 안 됐는지" 설명할 수 있다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 교정 방식 |
|---|---|---|
| HF만 계산하면 된다 | stale oracle 상태가 빠진다 | price validation을 먼저 둔다 |
| liquidatable이면 항상 실행한다 | gas와 slippage로 손실이 날 수 있다 | profit after gas를 계산한다 |
| shock scenario는 리스크팀 문서다 | 실제 queue와 UI에 반영되지 않는다 | simulator output을 dashboard에 연결한다 |
| depeg는 stablecoin 강의 문제다 | debt price와 collateral value가 동시에 흔들린다 | debt/collateral 가격을 분리한다 |
실습 과제
- Liquidation simulator 구현하기: accounts, prices, thresholds를 받아 liquidatable accounts와 repay plan을 반환한다.
- Shock scenario 리포트 작성하기: ETH -10%, stablecoin depeg, oracle stale 시나리오에서 queue와 user notice 변화를 작성한다.
완료 기준
- safe oracle adapter와 health factor 계산을 연결한 simulator를 작성했다.
- 최소 3개 가격 충격 시나리오에서 liquidation queue가 어떻게 바뀌는지 설명했다.
근거 자료
- 02 Lending
- 11 Protocol Development