오라클, 청산, Proof of Reserve

도입

스테이블코인 시스템은 스스로 세계의 가격과 준비자산을 알지 못한다. 담보 가격, reserve 규모, tokenized fund의 NAV, wrapped asset의 backing 상태는 외부 데이터가 들어와야 판단할 수 있다. 이때 oracle과 Proof of Reserve는 단순한 보조 기능이 아니라 발행, 청산, 신규 결제 허용, dashboard 경고를 움직이는 신뢰 경계가 된다.

이 강의에서는 oracle을 "가격을 읽는 함수"로 끝내지 않는다. 어떤 값이 어디서 오고, 얼마나 최신이며, stale 또는 0이 되었을 때 어떤 product state로 전환되는지까지 설계한다. PoR도 "감사 완료"가 아니라 reserve data를 제품 정책에 연결하는 장치로 읽는다.

학습 목표

• 오라클과 준비자산 증명의 목적 차이를 설명한다.
• 청산과 보고 지연이 시스템 리스크로 전이되는 흐름을 추적한다.
• stale data, zero value, reserve shortfall을 제품 상태와 circuit breaker로 바꾼다.

개념 설명

1. Oracle, liquidation, PoR은 서로 다른 질문에 답한다

세 용어는 한 강의에 같이 나오지만 같은 기능이 아니다. 먼저 질문을 분리한다.

Oracle은 데이터를 가져오는 통로이고, liquidation은 부족담보를 처리하는 상태 전이이며, PoR은 reserve data를 onchain 또는 product policy로 끌어오는 검증 레이어다. 결제 제품에서는 세 가지를 섞지 않아야 한다. 가격 feed가 정상이라고 해서 reserve가 충분하다는 뜻은 아니고, PoR feed가 정상이라고 해서 redemption liquidity가 즉시 충분하다는 뜻도 아니다.

2. Oracle이 쓰이는 위치를 먼저 그린다

이 표를 작성한 뒤에야 contract integration을 시작한다. Feed 주소만 붙이는 작업은 마지막 단계다. 먼저 feed가 가격인지 reserve인지 NAV인지, 어떤 frequency로 갱신되는지, stale이면 어떤 함수가 멈춰야 하는지 정해야 한다.

3. Oracle consumer는 값보다 timestamp를 먼저 본다

Chainlink Data Feeds API의 latestRoundData()는 answer뿐 아니라 startedAt, updatedAt, roundId 같은 정보를 반환한다. 반대로 timestamp 없이 최신 answer만 주는 오래된 함수들은 freshness 판단에 부적합하다. 그래서 consumer contract나 backend policy는 다음 검사를 가져야 한다.

학습자는 여기서 중요한 습관을 가져야 한다. "Chainlink feed를 썼다"가 완료 기준이 아니다. 어떤 feed를 어떤 한계값과 fallback으로 소비하는지가 완료 기준이다.

4. Proof of Reserve는 감사가 아니라 policy input이다

Chainlink는 Proof of Reserve를 stablecoin, tokenized asset, wrapped asset의 reserve monitoring과 token mint logic에 연결할 수 있는 방식으로 설명한다. 이때 개발자가 해야 할 일은 PoR feed를 절대 진실로 취급하는 것이 아니라, 데이터 원천과 제품 정책을 분리해 기록하는 것이다.

PoR은 "은행 계좌에 돈이 있다"는 법률 의견을 대체하지 않는다. 또한 attestation의 시간 차이, reserve 범위, liability 계산 방식, chain별 wrapped supply 차이를 해결해 주지 않는다. 그러므로 PoR은 제품의 risk input이지 최종 보증 문구가 아니다.

5. PoR feed를 product policy로 감싼다

원본 문서의 흐름은 아래와 같은 상태머신으로 확장할 수 있다.

이 흐름은 컨트랙트와 backend 양쪽에 나눠 들어갈 수 있다. 컨트랙트가 mint를 막고, backend가 checkout token을 숨기며, dashboard가 마지막 feed update와 reserve ratio를 보여주는 식이다.

6. 청산은 oracle 오류를 증폭시킬 수 있다

Crypto-backed stablecoin에서 oracle은 liquidation의 시작점이다. Sky Protocol 문서는 부족담보 vault의 collateral과 debt가 protocol로 이동하고, auction이 시작되어 debt를 회수하려는 구조를 설명한다. Dog는 undercollateralized vault를 confiscate하고 auction module로 넘기며, Clipper는 auction을 시작한다. 이 설명은 개발자가 청산을 "자동 판매"로 단순화하면 안 된다는 뜻이다.

결제 시스템이 DAI/USDS 같은 crypto-backed stablecoin을 받는다면 단순히 peg price만 보지 말고 oracle freshness, liquidation backlog, keeper activity, governance parameter change를 dashboard signal로 둬야 한다.

7. 테스트는 happy path보다 실패값을 먼저 넣는다

코드로 확인하기

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

컨트랙트Chainlink Aggregator 안전 호출 패턴

latestRoundData()를 직접 받지 말고 updatedAt, answeredInRound, answer > 0 을 모두 확인해 stale/zero/예전 라운드를 차단한다.

01interface AggregatorV3Interface {02    function decimals() external view returns (uint8);03    function latestRoundData() external view returns (04        uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound05    );06}0708contract OracleConsumer {09    AggregatorV3Interface public immutable feed;10    uint256 public maxStaleness = 1 hours;1112    error StaleOracle(uint256 updatedAt, uint256 nowTime);13    error InvalidAnswer(int256 answer);14    error StaleRound(uint80 roundId, uint80 answeredInRound);1516    constructor(address feedAddr) {17        feed = AggregatorV3Interface(feedAddr);18    }1920    function safePrice() public view returns (uint256 price, uint8 priceDecimals) {21        (uint80 roundId, int256 answer, , uint256 updatedAt, uint80 answeredInRound) = feed.latestRoundData();2223        if (answer <= 0) revert InvalidAnswer(answer);24        if (block.timestamp - updatedAt > maxStaleness) revert StaleOracle(updatedAt, block.timestamp);25        if (answeredInRound < roundId) revert StaleRound(roundId, answeredInRound);2627        return (uint256(answer), feed.decimals());28    }29}

컨트랙트Proof of Reserve 게이트 — mint 차단

reserve < circulating 일 때 mint를 차단한다. PoR feed가 stale 이면 보수적으로 mint도 막는다.

01interface IPoRFeed {02    function latestAnswer() external view returns (int256);   // reserve in USD03    function latestTimestamp() external view returns (uint256);04}0506contract ReserveGatedMinter {07    IPoRFeed public por;08    IERC20Mintable public token;09    uint256 public porMaxStaleness = 24 hours;1011    error ReserveStale(uint256 updatedAt);12    error ReserveBelowCirculating(int256 reserve, uint256 circulating);1314    function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {15        if (block.timestamp - por.latestTimestamp() > porMaxStaleness) {16            revert ReserveStale(por.latestTimestamp());17        }18        int256 reserve = por.latestAnswer();19        uint256 newCirculating = token.totalSupply() + amount;20        if (reserve <= 0 || uint256(reserve) < newCirculating) {21            revert ReserveBelowCirculating(reserve, newCirculating);22        }23        token.mint(to, amount);24    }25}

백엔드Oracle freshness + circuit breaker — off-chain consumer

contract 측 검사 외에 백엔드도 같은 검사를 한 번 더 한다. circuit breaker는 운영자가 즉시 mint/route 를 막을 수 있는 권한.

01import { createPublicClient, http, parseAbi } from "viem";0203const aggregatorAbi = parseAbi([04  "function latestRoundData() view returns (uint80, int256, uint256, uint256, uint80)",05  "function decimals() view returns (uint8)"06]);0708export async function isFeedHealthy(client: any, feed: `0x${string}`, maxStalenessSec: number) {09  const [, answer, , updatedAt, answeredInRound] = await client.readContract({10    address: feed, abi: aggregatorAbi, functionName: "latestRoundData"11  });12  const now = BigInt(Math.floor(Date.now() / 1000));1314  if (answer <= 0n) return { healthy: false, reason: "answer<=0" };15  if (now - updatedAt > BigInt(maxStalenessSec)) {16    return { healthy: false, reason: `stale by ${Number(now - updatedAt)}s` };17  }18  if (answeredInRound === 0n) return { healthy: false, reason: "round id zero" };1920  return { healthy: true };21}2223export class CircuitBreaker {24  private tripped = false;25  trip(reason: string) {26    this.tripped = true;27    console.error(`circuit breaker tripped: ${reason}`);28  }29  reset(operator: string) {30    this.tripped = false;31    console.log(`circuit breaker reset by ${operator}`);32  }33  assertOpen(action: string) {34    if (this.tripped) throw new Error(`${action} blocked: circuit breaker is tripped`);35  }36}

강의 포인트

실무 예시

컨트랙트[BACKEND] 상황: checkout 서비스가 세 종류의 토큰을 지원한다. USDC는 issuer reserve disclosure를 참고하고, DAI/USDS는 oracle과 liquidation health를 보며, wrapped BTC는 PoR feed로 backing을 확인한다. 이때 하나의 priceUsd 필드로 모든 것을 처리하면 위험하다.

이 예시에서 좋은 설계는 asset.priceFeed, asset.reserveFeed, asset.navFeed, asset.maxStaleness, asset.pausePolicy를 분리한다. 그래야 가격은 정상인데 reserve가 stale인 경우, reserve는 정상인데 liquidity가 부족한 경우를 서로 다른 상태로 처리할 수 있다.

흔한 오해와 실패 시나리오

실습 과제

1. 컨트랙트Oracle consumer 검증표 만들기: price/reserve/NAV feed별로 source, heartbeat, deviation threshold, updatedAt, zero/negative answer, fallback, pauser 권한을 표로 정리한다.
2. 컨트랙트[BACKEND] PoR 기반 mint/acceptance policy 작성하기: reserve feed 정상, stale, reserve < circulating supply, operator change 상황에서 mint, redeem, checkout acceptance가 어떻게 바뀌는지 상태 전이를 작성한다.
3. 운영청산 실패 후처리 runbook 쓰기: oracle stale, collateral price gap, keeper shortage, auction backlog, bad debt 발생 시 사용자 안내, 운영 조치, dashboard 지표를 연결한다.

완료 기준

1. 오라클과 PoR을 구분했다.
2. stale data 대응 조건을 정의했다.
3. 청산 실패 후처리를 문서화했다.
4. oracle consumer가 검사해야 할 timestamp, answer, fallback, 권한 변경 항목을 정리했다.

근거 자료

• 오라클 청산 Proof of Reserve: 01-스테이블코인/10-오라클-청산-Proof-of-Reserve.md
• Chainlink Proof of Reserve: https://chain.link/proof-of-reserve
• Chainlink Data Feeds API Reference: https://docs.chain.link/data-feeds/api-reference
• Chainlink: What Are Proof of Reserves?: https://chain.link/education-hub/proof-of-reserves
• Sky Protocol: Collateral Liquidation: https://developers.sky.money/protocol/vaults/collateral-liquidation/