Technical Overview
EVM Evidence → Observation → Event · Posting → Valuation · Lot → Report
Daejang is building evidence-first infrastructure for reviewable digital-asset records. The currently implemented foundation reconstructs EVM transactions into canonical execution evidence and account-scoped Observations, validates the artifacts with CUE contracts, and persists revisions, lineage, terminal outcomes, and failure states in PostgreSQL.
This is an implementation-based technical document, not a claim that the tax workflow is complete. The EVM Evidence and Observation path is implemented. Event, Posting, Valuation, Korean tax inventory, and Report runtimes are planned on top of contracts that already exist in part.
1. Why the system is evidence-first
Digital-asset activity is split across exchange records, wallets, chains, and protocols. The same economic movement can appear in several sources, while a single transaction can contain a swap, fees, transfers, and unsupported protocol behavior.
The system therefore has to preserve more than a final number:
- what source record or chain coordinate was read;
- what was normalized, rejected, left unsupported, or failed;
- what interpretation and policy produced an Event or Posting;
- which price, FX rate, lot rule, and revision produced a reported amount; and
- what changed when a parser, policy, price, or user judgment changed.
The JIT engine deliberately stops at an Observation. Economic and tax meaning belongs to later, separately versioned stages.
2. System sequence and implementation boundary
The diagram describes responsibility handoffs, not service boundaries, network calls, or deployment topology. The Evidence layer currently produces EVM evidence and Observations. The handoff from Observation through interpretation, accounting, and reporting is the target sequence and remains planned.
What each stage answers
| Stage | Question | Output |
|---|---|---|
| Evidence | What did the source actually say or execute? | Preserved source and canonical execution evidence |
| Observation | What account-scoped fact can be stated without economic judgment? | Typed fact linked to its evidence |
| Interpretation | What economic event best explains those facts? | Versioned Event and explicit decision |
| Accounting | How should movements, value, and basis be represented? | Balanced Postings, Valuation, and inventory lineage |
| Report | How can a reviewer understand and retrace a figure? | Report line linked to revisions and source coordinates |
| Capability | Status | Evidence boundary |
|---|---|---|
| EVM JIT evidence reconstruction | Implemented | Candidate selection, chain/inclusion checks, receipts, logs, traces, and canonical artifacts |
| Token, ERC-4337, EIP-7702, and withdrawal Observations | Implemented | Account-scoped observable facts with explicit outcomes |
| Reorg, provider failure, divergence, and partial handling | Implemented | Fail-closed terminal outcomes and preserved artifacts |
| CUE evidence, ledger, lot, and manifest contracts | Implemented | Structural and cross-record validation |
| JIT, evidence, artifact, ledger, and lot persistence contracts | Implemented | Immutable revisions, lineage, and typed PostgreSQL clients; storage does not compute domain results |
| Production-connected exchange ingestion | Planned | Source contracts exist; a production adapter is not connected |
| Event and Posting interpretation runtime | Planned | Schema and storage contracts exist; the runtime does not |
| Price and FX valuation runtime | Planned | Selection and evidence contracts exist; the runtime does not |
| KR tax inventory runtime | Planned | Generic lot contracts exist; the Korean tax run model and engine do not |
| Report and Evidence Pack generator | Planned | Manifest validation contract exists; report model, generator, and publication store do not |
| GIWA commitment and external verification | Planned | No deployed contract, transaction, schema UID, or Explorer proof is claimed |
3. Implemented foundation
EVM evidence and Observation
The JIT engine accepts candidate transactions and an account scope, verifies chain identity and inclusion, collects execution artifacts, and normalizes supported facts into Observations. Every candidate reaches an explicit terminal outcome; unsupported or incomplete evidence cannot disappear inside a success count.
This path is Implemented. See JIT Evidence Reconstruction and Validation & Failure Semantics.
Schema contracts
The CUE modules define evidence, Observation, interpretation, Posting, Valuation, reconciliation, lot, and publication-manifest shapes. Golden examples and mutation tests check invariants such as exact coverage, revision pointers, lot lineage, and publication hashes.
This contract layer is Implemented. It validates data; it does not run interpretation, valuation, tax, or report computation.
Persistence and lineage
daejang-db provides immutable artifact, JIT, evidence, ledger, and lot storage boundaries. The ledger and lot packages can persist results produced elsewhere, enforce subject isolation and revision lineage, and publish completion events atomically.
This storage layer is Implemented. Domain engines remain responsible for producing Event, Posting, Valuation, and lot results.
4. Planned Event-to-Report path
Event and Posting
The first runtime milestone converts sufficiently supported Observations into versioned Events and balanced Postings. Its MVP fixture boundary is:
| Scenario | Target behavior |
|---|---|
| CEX fill | Produce asset and consideration Postings plus a fee Posting when separately evidenced |
| CEX withdrawal → owned EVM wallet | Join the two Observations as SELF_TRANSFER only with ownership and amount/time evidence; preserve basis continuity |
| EVM swap with gas | Separate received asset, disposed asset, protocol flow, and gas expense |
| External inbound transfer | Do not auto-classify as income without economic evidence |
| Balance delta or account-state snapshot | Use for reconciliation; do not create a Posting by itself |
| Unsupported DeFi interaction | End as unsupported or review-required; do not invent economic meaning |
This runtime is Planned. The detailed decision boundary is in Event, Posting & Valuation.
Valuation
KRW fair value requires pinned price and FX evidence, source comparison, tolerance handling, and explicit fallback or conflict resolution. Quantity, price, and FX remain exact integer ratios, with rounding performed once at the final KRW unit.
This runtime is Planned.
Provenance Lot Graph and KR Tax Inventory
These are related but not interchangeable:
- The Provenance Lot Graph traces acquisition, disposal, and confirmed continuity across Postings. The generic
LotRunandLotAllocationcontracts already model this lineage. - The KR Tax Inventory is the policy result for
resident × tax year × tax_asset_id. The target policy pools all owned accounts, wallets, and exchanges; location is provenance, not a separate inventory. It applies annual total-average cost and carries basis through confirmed self-transfers.
The current LotRun.scope contains only assetIds. A typed TaxInventoryRun with taxYear, taxAssetId, and a provisional/final runMode is still required. The engine and that contract are Planned.
Report and publication
The schema already provides #EvidenceManifestData and #ValidatePublication, so a publication can eventually pin its evidence generation, scope, closure, revisions, and content hashes. What is missing is a ReportModel, a generator that derives it from the ledger and tax inventory, a publication-specific store, and rendered report/Evidence Pack artifacts.
This stage is Planned. See Tax Inventory & Report.
5. Delivery sequence
| Phase | Deliverable | Exit evidence |
|---|---|---|
| P0 | Freeze Event-to-Report contracts and fixtures | Versioned fixtures and explicit unsupported cases |
| P1 | Event and Posting runtime | CEX fill, self-transfer, EVM swap/gas golden cases |
| P2 | Valuation runtime | Exact-ratio KRW results, missing/conflicting-rate cases |
| P3 | Provenance Lot Graph | Allocation lineage and continuity queries |
| P4 | KR Tax Inventory | Annual total-average runs by resident, tax year, and tax asset |
| P5 | Report and Evidence Pack | Reproducible report, manifest validation, revision diff |
The Golden Path is complete only when one selected source set can be processed from evidence to Observation, Event, Posting, Valuation, tax inventory, and Report; the final figure must drill back to its exact source coordinates and revision.
6. Verification evidence and limits
The following commands were run against the surveyed base branches on 2026-07-25:
| Repository | Verification | Result |
|---|---|---|
daejang | npm run lint, npm run typecheck, npm test, npm run build | Passed; proves only the repository's current checks |
daejang-jit-engine | go test ./..., go vet ./..., go build ./... | Passed |
schema | make check | Passed |
daejang-db | make check, go test ./..., go vet ./..., go build ./... | Passed |
These are local results against private repositories. They do not prove live RPC behavior, live PostgreSQL integration, a production exchange adapter, or the planned Event-to-Report runtime. See Current Limitations and Claim Boundaries.