기술 개요
EVM Evidence → Observation → Event · Posting → Valuation · Lot → Report
Daejang은 디지털 자산 기록의 근거를 먼저 남긴다. 현재 구현된 경로는 EVM transaction을 canonical 실행 증거와 account 범위 Observation으로 복원하고 CUE로 artifact를 검증한 뒤 revision, lineage, terminal outcome과 실패 상태를 PostgreSQL에 저장한다.
이 문서는 현재 구현을 기준으로 썼다. 세금 workflow가 완성됐다는 뜻은 아니다. EVM Evidence와 Observation 경로는 동작하지만 Event, Posting, Valuation, 한국 세무 inventory, Report runtime은 아직 개발 전이다.
1. 왜 증거가 먼저인가
디지털 자산 활동은 거래소 기록, 지갑, 체인, protocol에 나뉘어 있다. 같은 경제적 이동이 여러 원천에 나타날 수 있고, 하나의 transaction에도 swap, fee, transfer, 미지원 protocol 동작이 함께 들어갈 수 있다.
최종 숫자만 저장해서는 이 과정을 다시 확인할 수 없다. 함께 남겨야 할 정보는 다음과 같다.
- 어떤 source record 또는 chain 좌표를 읽었는지
- 무엇이 normalized, rejected, unsupported, failed 상태가 됐는지
- 어떤 해석과 policy가 Event 또는 Posting을 만들었는지
- 어떤 price, FX rate, lot rule, revision이 보고 금액을 만들었는지
- parser, policy, price, 사용자 판단이 바뀌었을 때 무엇이 달라졌는지
JIT engine은 의도적으로 Observation에서 멈춘다. 경제적 의미와 세무 의미는 이후의 별도 version 단계가 책임진다.
2. 전체 처리 순서와 구현 경계
이 그림은 실제 service 구성이나 network call을 나타내지 않는다. 각 단계가 어떤 책임을 넘겨받고 다음 단계에 무엇을 전달하는지만 추상화했다. 현재 Evidence 계층은 EVM evidence와 Observation까지 만든다. Observation 이후 해석, 회계 처리, 보고 단계는 목표 흐름이며 runtime은 아직 개발 전이다.
단계별로 답하는 질문
| 단계 | 핵심 질문 | 결과 |
|---|---|---|
| Evidence | 원천에서 실제로 확인된 것은 무엇인가? | 보존된 원문과 canonical 실행 증거 |
| Observation | 경제적 판단 없이 account 범위에서 말할 수 있는 사실은 무엇인가? | evidence와 연결된 typed fact |
| Interpretation | 이 사실을 가장 잘 설명하는 경제적 사건은 무엇인가? | versioned Event와 명시적인 판단 |
| Accounting | 자산 이동, 가치, 취득가를 어떻게 표현할 것인가? | balanced Posting, Valuation, inventory lineage |
| Report | 검토자가 숫자를 어떻게 이해하고 다시 확인할 수 있는가? | revision과 source 좌표까지 연결된 report line |
| 기능 | 상태 | 근거 경계 |
|---|---|---|
| EVM JIT evidence reconstruction | 구현됨 | candidate 선택, chain/inclusion 확인, receipt·log·trace와 canonical artifact |
| Token, ERC-4337, EIP-7702, withdrawal Observation | 구현됨 | account 범위 관찰 사실과 명시적 outcome |
| Reorg, provider 실패·불일치, partial 처리 | 구현됨 | fail-closed terminal outcome과 artifact 보존 |
| CUE evidence, ledger, lot, manifest 계약 | 구현됨 | 구조와 record 간 invariant 검증 |
| JIT, evidence, artifact, ledger, lot 저장 계약 | 구현됨 | immutable revision, lineage, typed PostgreSQL client. 저장 계층은 domain 결과를 계산하지 않음 |
| production 연결 거래소 수집 | 계획 | source 계약은 있으나 production adapter는 연결되지 않음 |
| Event·Posting 해석 runtime | 계획 | schema·저장 계약은 있으나 runtime 없음 |
| Price·FX valuation runtime | 계획 | 선택·증거 계약은 있으나 runtime 없음 |
| 한국 세무 inventory runtime | 계획 | 일반 lot 계약은 있으나 한국 세무 run model과 engine 없음 |
| Report·Evidence Pack generator | 계획 | manifest 검증 계약은 있으나 report model·generator·publication store 없음 |
| GIWA commitment와 외부 검증 | 계획 | 배포 contract, transaction, schema UID, Explorer 증거를 주장하지 않음 |
3. 구현된 기반
EVM evidence와 Observation
JIT engine은 candidate transaction과 account scope를 받는다. chain identity와 inclusion을 확인하고 실행 artifact를 수집한 뒤 지원하는 사실을 Observation으로 normalize한다. 모든 candidate에는 terminal outcome이 남기 때문에 unsupported 항목이나 불완전한 증거가 성공 건수에 섞이지 않는다.
이 경로는 구현됨이다. 구현 내용은 JIT 증거 복원과 검증과 실패 의미론에서 확인할 수 있다.
Schema 계약
CUE module은 evidence, Observation, interpretation, Posting, Valuation, reconciliation, lot, publication manifest 구조를 정의한다. Golden example과 mutation test는 exact coverage, revision pointer, lot lineage, publication hash 등의 invariant를 검사한다.
계약과 검증은 구현됨이다. interpretation, valuation, tax, report 계산은 수행하지 않는다.
저장과 lineage
daejang-db는 immutable artifact, JIT, evidence, ledger, lot 저장 경계를 제공한다. ledger와 lot package는 다른 runtime이 만든 결과를 저장하고 subject isolation과 revision lineage를 강제한다. 완료 event도 원자적으로 발행할 수 있다.
저장 계층은 구현됨이다. Event, Posting, Valuation, lot 결과는 domain engine이 만들어야 한다.
4. 개발 예정인 Event-to-Report 경로
Event와 Posting
첫 구현 단계에서는 근거가 충분한 Observation을 versioned Event와 balanced Posting으로 바꾼다. MVP fixture 범위는 다음과 같다.
| 시나리오 | 목표 동작 |
|---|---|
| CEX fill | 자산·대가 Posting과 별도 증거가 있는 fee Posting 생성 |
| CEX withdrawal → 소유 EVM wallet | 소유권·수량·시간 근거가 있을 때만 SELF_TRANSFER로 연결하고 basis continuity 보존 |
| Gas가 포함된 EVM swap | 수취 자산, 처분 자산, protocol flow, gas expense 분리 |
| 외부 inbound transfer | 경제적 근거 없이 income으로 자동 분류하지 않음 |
| Balance delta 또는 account-state snapshot | reconciliation에만 사용하고 그 자체로 Posting을 만들지 않음 |
| 미지원 DeFi interaction | unsupported 또는 review-required로 종결하고 경제적 의미를 만들어내지 않음 |
이 runtime은 계획이다. 자세한 판단 경계는 Event, Posting, Valuation에 있다.
Valuation
KRW fair value에는 고정된 price·FX 증거, source 비교, tolerance 처리, 명시적 fallback 또는 conflict resolution이 필요하다. Quantity, price, FX는 exact integer ratio로 유지하고 최종 KRW 단위에서 한 번만 반올림한다.
이 runtime은 계획이다.
Provenance Lot Graph와 KR Tax Inventory
둘은 연결되지만 같은 것이 아니다.
- Provenance Lot Graph는 수량의 취득, 처분, 확인된 continuity를 Posting 사이에서 추적한다. 일반
LotRun과LotAllocation계약이 이 lineage를 이미 모델링한다. - KR Tax Inventory는
resident × tax_year × tax_asset_id범위의 policy 결과다. 모든 소유 account·wallet·exchange를 합산하고, 위치는 별도 inventory가 아니라 provenance로 남긴다. 연간 총평균법을 적용하고 확인된 self-transfer에서는 basis를 승계한다.
현재 LotRun.scope에는 assetIds만 있다. taxYear, taxAssetId, provisional/final runMode를 가진 typed TaxInventoryRun이 추가로 필요하다. engine과 이 계약은 계획이다.
Report와 publication
Schema에는 이미 #EvidenceManifestData와 #ValidatePublication이 있어 publication이 사용한 evidence generation, scope, closure, revision, content hash를 고정할 수 있다. 없는 것은 ledger와 tax inventory에서 ReportModel을 만드는 generator, publication 전용 store, render된 report/Evidence Pack artifact다.
이 단계는 계획이다. 세무 inventory와 리포트를 참고한다.
5. 개발 순서
| Phase | 산출물 | 종료 근거 |
|---|---|---|
| P0 | Event-to-Report 계약과 fixture 고정 | versioned fixture와 명시적 unsupported case |
| P1 | Event·Posting runtime | CEX fill, self-transfer, EVM swap/gas golden case |
| P2 | Valuation runtime | exact-ratio KRW 결과와 missing/conflicting rate case |
| P3 | Provenance Lot Graph | allocation lineage와 continuity query |
| P4 | KR Tax Inventory | resident·tax year·tax asset별 연간 총평균 run |
| P5 | Report·Evidence Pack | 재현 가능한 report, manifest 검증, revision diff |
선택한 source set 하나가 evidence부터 Report까지 처리되고 최종 숫자에서 source 좌표와 revision을 다시 찾을 수 있어야 Golden Path가 완료된다.
6. 검증 근거와 한계
2026-07-25에 실사한 기본 브랜치에서 다음 명령을 실행했다.
| 저장소 | 검증 | 결과 |
|---|---|---|
daejang | npm run lint, npm run typecheck, npm test, npm run build | 통과. 저장소의 현재 검사 범위만 증명 |
daejang-jit-engine | go test ./..., go vet ./..., go build ./... | 통과 |
schema | make check | 통과 |
daejang-db | make check, go test ./..., go vet ./..., go build ./... | 통과 |
이는 비공개 저장소에 대한 로컬 결과다. live RPC, live PostgreSQL integration, production 거래소 adapter, 개발 예정인 Event-to-Report runtime을 증명하지 않는다. 현재 제약과 주장 경계를 참고한다.