Event, Posting & Valuation

Planned

The CUE and PostgreSQL contracts for this stage exist and validate. The domain runtime that produces these records does not yet exist.

Responsibility boundary

An Observation records what a source or chain execution showed. It does not by itself say that a transfer was income, that two legs form a swap, or that an exchange withdrawal and wallet receipt are the same self-transfer.

The planned flow preserves those decisions as versioned records:

Observation → InterpretationHypothesis → InterpretationDecision
            → InterpretedEvent revision → FlowLeg · AssetPosting · FlowRelation
            → Valuation

• AssetPosting records which owned account and asset increased or decreased.
• FlowRelation records why two legs are linked, including confirmed continuity.
• Valuation records a monetary measurement and the exact evidence and policy used.

These roles stay separate so that a changed interpretation does not rewrite source facts.

MVP behavior

Input scenario	Required output	Must not happen
CEX trade fill	Disposed asset, acquired asset, consideration, and separately evidenced fee Postings	Collapsing trade and fee into one unexplained delta
CEX withdrawal plus owned-wallet receipt	A SELF_TRANSFER Event and CONFIRMED CONTINUITY only when ownership, asset, amount, and timing evidence support the join	Treating the withdrawal as a disposal or the receipt as new income
EVM swap plus gas	Separate swap legs and gas Posting with traceable chain coordinates	Hiding gas in the acquired quantity or assigning a guessed protocol meaning
External inbound transfer	Review material until income, gift, transfer, or other economic grounds exist	Automatically classifying every inbound transfer as income
Balance delta or account-state snapshot	Reconciliation evidence	Creating a Posting without a source movement or accepted Event
Unsupported DeFi interaction	UNSUPPORTED or review-required terminal state with native evidence retained	Producing a confident Event from an unknown protocol pattern

Fail-closed interpretation

Insufficient evidence remains visible

When ownership, coordinates, asset identity, amount, or relation grounds are inadequate, the system does not auto-confirm the interpretation. It records the hypothesis and terminal decision, then leaves the item unresolved or review-required.

For example, a confirmed exchange withdrawal and confirmed wallet receipt plus an applicable OwnershipAssertion can support self-transfer continuity. If the destination is not confirmed, the OUT Posting remains, the destination leg is MISSING, and no arrival Posting or basis carry is created. Later evidence creates a new revision rather than deleting the earlier result.

Valuation rules

KRW FAIR_VALUE requires a PRICE selection and, when needed, an FX selection. Each selection pins the source artifacts, comparison policy, and tolerance.

• Missing required evidence keeps the valuation incomplete.
• A source conflict outside tolerance requires an explicit resolution.
• Fallback use records both the reason and the fallback evidence.
• assetQuantity × PRICE × FX is evaluated as an exact integer ratio.
• Rounding occurs once, at the final KRW smallest unit.
• COST_BASIS follows the original KRW acquisition evidence and never fabricates a market price that was not used.

Build boundary

Component	Current state
CUE types and invariants	Implemented
Ledger and valuation persistence clients	Implemented
Hypothesis generation and decision runtime	Planned
Event revision and Posting projection runtime	Planned
Price/FX collection and valuation runtime	Planned
Golden fixtures for the six MVP cases above	Planned

Tax inventory and report generation depend on accepted Postings and Valuations. See Tax Inventory & Report.