대조 및 준비금 증명(PoR)
대사(Reconciliation)와 준비금 증명(Proof of Reserve)
KSC(ieum) SaaS에서 Reconciliation & PoR는 단순한 리포트 기능이 아니라, 시스템 신뢰의 핵심 메커니즘입니다.
이 섹션은 다음 질문에 답하기 위해 존재합니다.
“지금 발행된 스테이블코인이 정말 담보로 뒷받침되고 있는가?”
“이 시스템은 사후 감사에 대응할 수 있는가?”
“문제가 생겼을 때, 책임은 어디까지인가?”
왜 Reconciliation이 필요한가
기존 금융 시스템에서는 대사가 사후 작업에 가깝습니다.
하루 또는 월 단위로 집계
서로 다른 시스템 간 수작업 대조
문제가 발견되면 이미 늦은 경우도 많음
반면, KSC는 다음을 전제로 설계되었습니다.
발행과 동시에 검증 가능해야 한다. 대사는 사후가 아니라 상시적으로 이루어져야 한다.
이를 위해 KSC SaaS는 On-chain 데이터와 Off-chain 기록을 구조적으로 분리하고, 그 둘을 항상 비교 가능한 상태로 유지합니다.
PoR(Proof of Reserve)이란 무엇인가
KSC에서 PoR은 단순히 “준비금이 있습니다”라는 선언이 아닙니다.
PoR은 다음을 의미합니다.
On-chain 발행량이
Off-chain에 기록된 담보 및 원장과
항상 대응 관계를 이루고 있음이 증명 가능한 상태
즉, PoR은 **보고서(document)**가 아니라 **검증 가능한 상태(state)**입니다.
On-chain vs Off-chain: 무엇을 비교하는가
KSC의 대사는 항상 두 개의 축을 기준으로 이루어집니다.
On-chain (블록체인 상 데이터)
실제로 발행된 BNK(KRW 스테이블코인)의 총량
소각(Burn) 반영 이후의 순 발행량
누구도 임의로 수정할 수 없는 공개 상태
Off-chain (KSC SaaS Ledger)
입금(Deposit) 기록
담보 승인 이력 (Pending / Approved)
발행·소각 요청 및 결과 기록
정산(Settlement) 기록
KSC SaaS는 블록체인 실행 주체가 아닙니다. 대신, 실행 결과를 기록하고 검증하는 단일 원장 역할을 수행합니다.
Reconciliation의 기본 원칙
KSC의 대사는 다음 원칙을 따릅니다.
실행과 기록을 분리한다
실행: App Backend
기록·검증: KSC SaaS
모든 발행·소각은 기록 없이 유효하지 않다
On-chain에만 존재하는 상태는 “운영 완료”가 아님
SaaS Ledger에 기록되어야 운영상 유효
차이(Delta)는 항상 해석 대상이다
Delta = 0 → 정상
Delta ≠ 0 → 즉시 확인 대상 (반드시 오류는 아님)
Delta는 오류인가?
많은 실무자들이 가장 먼저 묻는 질문은 이것입니다.
“Delta가 발생하면, 시스템에 문제가 있는 건가요?”
정답은 아닙니다.
Delta는 다음과 같은 정상적인 상황에서도 발생할 수 있습니다.
담보 승인 대기(Pending Collateral)
발행/소각 직후의 시점 차이
정산 지연
KSC는 Delta 자체를 문제로 보지 않고, Delta의 원인을 추적 가능하게 만드는 것을 목표로 합니다.
중요한 것은 **“차이가 있는가?”가 아니라 “왜 차이가 있는지를 설명할 수 있는가”**입니다.
감사(Audit) 관점에서의 Reconciliation
KSC의 Reconciliation 구조는 사후 감사를 전제로 설계되었습니다.
감사 시 확인 가능한 항목
언제 어떤 담보가 추가·승인되었는지
누가 승인했는지
승인 이후 발행이 얼마만큼 이루어졌는지
특정 시점 기준 On-chain / Off-chain 일치 여부
모든 정보는 로그와 기록 형태로 남아, 외부 감사 또는 내부 통제 보고에 그대로 활용될 수 있습니다.
책임의 경계
Reconciliation & PoR 구조에서 각 주체의 역할은 명확히 분리됩니다.
은행
발행 요청 주체
발행 정책 및 운영 책임
신탁사
담보 승인 책임
준비금 검증 책임
KSC SaaS
기록·대사·리포트 제공
실행에 대한 책임은 가지지 않음
이 분리는 운영 리스크를 줄이고, 책임을 명확히 하기 위한 설계입니다.
이 다음에 무엇을 보게 되는가
이 메인 페이지는 개요입니다. 다음 서브 페이지에서는 아래를 구체적으로 다룹니다.
실제 On-chain / Off-chain 데이터는 어디서 오고 어떻게 비교되는가
Delta가 발생했을 때 실무적으로 무엇을 확인해야 하는가
감사 관점에서 어떤 화면과 리포트를 제출하면 되는가
👉 다음으로 이어지는 페이지:
On-chain / Off-chain Matching
Delta Detection & Interpretation
Audit View & Responsibility
Last updated