오래된 가격은 마지막 보고값 자체가 당시에는 맞았지만 현재 시각까지 갱신되지 않은 상태다. 잘못된 가격은 최신 시각처럼 보이더라도 소스·집계·설정 오류로 시장을 제대로 반영하지 못할 수 있다. 사고 공지에서는 feed 주소와 자산, answer와 updatedAt, 갱신 조건, sequencer 상태, 프로토콜이 허용하는 최대 지연과 borrow·liquidation 차단 규칙을 함께 확인한다.
값이 같다는 사실과 최신이라는 사실은 다르다
시장 가격이 한동안 거의 움직이지 않으면 같은 오라클 값이 정상일 수 있다. 반대로 updatedAt이 최근이어도 잘못된 소스나 설정으로 부정확한 값이 제출될 수 있다. 화면의 가격 하나만 보지 말고 feed contract, round, answer, decimals, updatedAt과 현재 블록 시각을 함께 기록한다.
Aave 공식 문서는 각 reserve가 oracle contract와 연결되고 governance가 소스를 선택하며, oracle이 time-based 또는 deviation-based 운영 논리에 따라 갱신될 수 있다고 설명한다. 정해진 편차를 넘지 않으면 heartbeat까지 값이 유지될 수 있으므로 거래소 tick과 매초 같지 않다는 사실만으로 사고를 단정하지 않는다.
오라클 가격은 숫자와 시각, 소스, 사용 규칙이 함께 있어야 의미가 완성된다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 값이 같다는 사실과 최신이라는 사실은 다르다
시장 가격이 한동안 거의 움직이지 않으면 같은 오라클 값이 정상일 수 있다 .
- 지연이 생긴 층을 찾아야 한다
데이터 제공자와 노드가 새 값을 집계했어도 온체인 제출 거래가 지연될 수 있다.
- 프로토콜의 소비 규칙이 피해를 결정한다
같은 stale feed를 써도 앱이 최대 지연을 검사해 revert하면 잘못된 청산을 막을 수 있다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
지연이 생긴 층을 찾아야 한다
데이터 제공자와 노드가 새 값을 집계했어도 온체인 제출 거래가 지연될 수 있다. L2 sequencer가 멈추면 거래 제출과 오라클 업데이트가 함께 막힐 수 있다. 체인은 갱신됐지만 RPC·인덱서 캐시가 예전 round를 보여 주는 경우도 있다. 각 층의 타임스탬프를 비교한다.
Aave V3의 PriceOracleSentinel 문서는 L2 sequencer 상태에 따라 borrow와 liquidation 허용 여부를 제한하고 복구 뒤 grace period를 두는 설계를 설명한다. 하지만 Aave v3.7 문서는 이 sentinel 검사를 제거했다고 밝힌다. 버전별 구현이 달라졌으므로 과거 보호 장치가 현재도 있다고 가정하면 안 된다.
| 층 | 확인값 | 오독 방지 |
|---|---|---|
| 데이터 소스 | 시장 범위·집계 상태 | 한 거래소 가격과 동일시하지 않기 |
| feed 업데이트 | round·answer·updatedAt | 같은 값과 stale을 구분 |
| L2 sequencer | up/down과 복구 시각 | 체인 제출 불가를 feed 오류로 단정하지 않기 |
| 프로토콜 소비 | staleness 한도·fallback·차단 | feed 정상과 앱 안전을 동일시하지 않기 |
| RPC·인덱서 | 응답 블록·캐시 | 표시 지연을 원장 지연으로 오해하지 않기 |
프로토콜의 소비 규칙이 피해를 결정한다
같은 stale feed를 써도 앱이 최대 지연을 검사해 revert하면 잘못된 청산을 막을 수 있다. 검사 없이 마지막 값을 계속 쓰면 가격 급변기에 오래된 담보가치로 차입이나 청산이 이뤄질 수 있다. fallback oracle이 자동 전환되는지, 관리자가 수동으로 source를 바꿔야 하는지도 본다.
AaveOracle 문서는 governance 역할이 asset source와 fallbackOracle을 설정할 수 있고 getAssetPrice로 base currency 가격을 반환한다고 설명한다. 사건 분석에서는 실제 당시 source 주소, 권한 변경 거래, fallback 활성 여부를 확인한다. 문서상 기능이 존재한다는 사실만으로 사건 때 사용됐다고 단정하지 않는다.
잘못된 가격은 최신 round에서도 생긴다
decimals 오해, 잘못된 base/quote 방향, wrapped asset 환율, cap과 snapshot 시각 불일치, 주소 매핑 오류는 updatedAt이 최신이어도 잘못된 값을 만든다. 0이나 극단값만 찾는 모니터링으로는 작은 편차가 청산 임계값을 넘기는 사고를 놓칠 수 있다.
가격을 독립 시장자료와 비교할 때 동일 시각·통화·자산 형태를 맞춘다. wstETH와 stETH처럼 교환비율이 있는 자산을 단순 현물가격만으로 비교하지 않는다. oracle adapter 내부의 변환과 상한·하한을 재현한다.
- feed와 자산·네트워크 주소를 정확히 고정한다
- answer·decimals·updatedAt·round와 기준 블록을 저장한다
- heartbeat·편차·sequencer·RPC 상태를 분리한다
- 프로토콜의 staleness·fallback·차단 규칙을 코드에서 확인한다
- 동일 시각·통화·자산 형태로 독립 가격과 비교한다
복구 공지는 가격 정상화 이후를 설명해야 한다
새 round가 정상 범위로 돌아와도 이미 잘못 청산된 거래는 자동 취소되지 않는다. borrow·liquidation 재개, grace period, cap 조정, source 교체, 영향 계정 산정과 보상 제안은 별도 단계다. 가격 정상화 시각과 서비스 정상화 시각을 나눈다.
Aave 문서의 sentinel 설계는 복구 직후 이용자가 포지션을 건강하게 만들 시간을 주려는 목적을 설명한다. 현재 버전에서 같은 장치가 제거됐다면 다른 grace mechanism 또는 governance 조치가 있는지 확인한다. 기사에서 과거 구현을 현재 보호로 표현하지 않는다.
사고 범위를 거래 단위로 재현한다
영향 창의 모든 oracle update와 관련 borrow·withdraw·liquidation 이벤트를 시간순으로 놓는다. 어떤 거래가 stale 또는 잘못된 값에 의존했는지, 정상 가격이었다면 health factor가 어땠는지 반사실 계산의 가정을 밝힌다.
프로토콜 손실, 이용자 담보 손실, liquidator bonus, bad debt를 한 금액으로 합치지 않는다. 회수된 bonus와 확정 보상도 구분한다. 조사 중 수치는 기준 블록과 계산 방법을 붙이고 후속 공지에서 갱신한다.
자주 묻는 질문
가격이 몇 분 안 바뀌면 stale인가요?
feed별 heartbeat·편차와 앱의 허용 지연이 다르다. updatedAt과 해당 설정을 함께 확인해야 한다.
오라클 round가 최신이면 가격도 정확한가요?
보장되지 않는다. source·단위·asset mapping·adapter 설정 오류로 최신 round도 부정확할 수 있다.
정상 가격이 다시 올라오면 잘못된 청산도 취소되나요?
온체인 완료 거래는 자동 취소되지 않는다. 별도 보상·회수·거버넌스 절차가 필요할 수 있다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
