DeFi Risk Dashboard Lab
도입
DeFi dashboard는 TVL과 volume을 크게 보여주는 화면이 아니다. 운영자가 오늘 무엇을 해야 하는지 알려주는 화면이어야 한다. AMM depth가 얕아졌는지, oracle이 stale인지, health factor가 1 근처에 몰렸는지, liquidation queue가 keeper capacity를 넘는지, RWA나 LRT exposure가 특정 자산에 집중됐는지 보여야 한다.
이 실습은 dashboard를 risk decision surface로 설계한다. 각 metric은 alert와 owner, next action으로 이어져야 한다. 그렇지 않으면 숫자는 예쁘지만 운영에는 쓸모가 없다.
학습 목표
- DeFi dashboard를 TVL 카드가 아니라 action-oriented risk surface로 설계한다.
- AMM depth, oracle freshness, HF distribution, liquidation queue, protocol exposure를 한 화면에 배치한다.
- alert severity와 owner, next action을 정의한다.
개념 설명
maxAgeSec policy 기준
trade size 대비 depth
liquidation cluster
keeper capacity
depeg sensitivity
timelock monitor
| Metric | Threshold | Owner | Action |
|---|---|---|---|
| Oracle age | maxAgeSec 초과 | BACKEND | new borrow disable |
| HF p10 | 1.10 미만 | OPS | liquidation queue review |
| Pool depth | trade size 대비 부족 | CLIENT | route warning |
| Queue size | keeper capacity 초과 | OPS | incentive and cap review |
코드로 확인하기
export function defiAlert({ oracleAgeSec, maxAgeSec, poolDepthUsd, hfP10, queueSize }: { oracleAgeSec: number; maxAgeSec: number; poolDepthUsd: number; hfP10: number; queueSize: number;}) { if (oracleAgeSec > maxAgeSec) return { severity: "critical", owner: "BACKEND", action: "disable-new-borrow" }; if (hfP10 < 1.05 || queueSize > 100) return { severity: "high", owner: "OPS", action: "review-liquidation-capacity" }; if (poolDepthUsd < 1_000_000) return { severity: "medium", owner: "CLIENT", action: "show-route-warning" }; return { severity: "watch", owner: "OPS", action: "monitor" };}select date_trunc('hour', observed_at) as hour, percentile_cont(0.1) within group (order by health_factor) as hf_p10, count(*) filter (where health_factor < 1.05) as urgent_accounts, max(oracle_age_sec) as max_oracle_age_secfrom lending_risk_snapshotsgroup by 1;코드와 SQL은 dashboard가 계산 가능한 상태에서 출발해야 함을 보여준다. 예쁜 카드보다 threshold와 action이 중요하다.
강의 포인트
| 관점 | 확인할 질문 | 증거로 남길 것 |
|---|---|---|
| Metric | 숫자가 어떤 행동을 바꾸는가 | threshold |
| Owner | 누가 대응하는가 | team or role |
| User impact | 사용자 화면이 바뀌는가 | copy and action |
| Review | alert가 사후 분석으로 남는가 | incident log |
실무 예시
운영[CLIENT] pool depth가 얕아졌는데 swap UI가 그대로라면 사용자는 과도한 slippage에 노출된다. dashboard alert는 client route warning으로 이어져야 한다. oracle stale alert는 backend borrow gate로 이어져야 한다.
대시보드가 관리자만 보는 화면이라면 늦다. 중요한 alert는 사용자 행동 제한과 연결된다. 단, repay나 withdraw처럼 사용자의 위험 감소 행동은 계속 열어둘 수 있는지 별도 판단해야 한다.
흔한 오해와 실패 시나리오
| 오해 | 실패 시나리오 | 교정 방식 |
|---|---|---|
| dashboard는 관찰 화면이다 | action이 없어 사고 대응이 늦다 | owner와 next action을 붙인다 |
| TVL이 가장 중요하다 | solvency와 user risk를 놓친다 | HF, oracle, queue를 우선한다 |
| 모든 alert는 운영자만 보면 된다 | 사용자 화면이 위험을 반영하지 못한다 | client action을 연결한다 |
| threshold는 나중에 정한다 | alert fatigue 또는 missed incident가 생긴다 | launch gate에 포함한다 |
실습 과제
- Risk dashboard wireframe 만들기: AMM, lending, oracle, liquidation, stablecoin exposure를 포함하는 dashboard wireframe을 만든다.
- Alert severity 함수 작성하기: oracle age, pool depth, HF p10, queue size를 받아 severity와 owner를 반환한다.
완료 기준
- dashboard에 최소 6개 metric과 4개 alert를 포함했다.
- 각 alert에 severity, owner, user-facing action을 붙였다.
근거 자료
- 01 Market Overview
- 09 Risk and Security