Abstract
Financial systems often need to answer questions that fungible assets were never designed to answer cleanly.
Which inbound transaction funded this withdrawal?
How much of the current balance still depends on provisional settlement?
Which downstream transactions are exposed if an earlier deposit reverses?
Did customer funds, platform liquidity, credit, or collateral ultimately finance a particular external transfer?
These questions appear simple until value is pooled, partially consumed, transferred between accounts, converted between assets, netted, batched, or reused across several operations.
Fungibility deliberately removes identity from individual units of value. Accounting systems aggregate balances precisely because one unit of the same asset is economically equivalent to another. Yet risk, compliance, reconciliation, provisional finality, and compensation frequently require preserving causal relationships that ordinary balances discard.
This creates a tension between fungibility and provenance.
This article examines value lineage as a causal accounting problem rather than a naive tracing problem. We explore source attribution, consumption policies, proportional lineage, conservation invariants, multi-asset transformations, internal transfers, liquidity pools, batching, credit substitution, privacy, and the conditions under which exact traceability is neither possible nor desirable.
The goal of value lineage is not to give every monetary unit a fictional serial number.
It is to preserve enough causal structure to explain where economic exposure originated, where it propagated, and who carries it now.
Fungibility destroys identity by design
Suppose an account receives two deposits:
Deposit A: 100 USD
Deposit B: 100 USD
The account now contains:
Balance: 200 USD
If the customer withdraws 50 USD, which deposit funded the withdrawal?
The ledger usually has no answer.
Nor should it necessarily have one.
USD is fungible. One dollar is economically substitutable for another dollar of equivalent legal and settlement status.
The balance exists because the system intentionally discarded unit identity.
This is one of the advantages of accounting.
Instead of tracking 200 individually identified dollars, the ledger stores an aggregate claim.
The difficulty begins when Deposit A and Deposit B are not economically equivalent.
Suppose:
Deposit A:
amount: 100 USD
settlement: reconciled
reversal_exposure: none
Deposit B:
amount: 100 USD
settlement: provisional
reversal_exposure: active
The account still shows:
Balance: 200 USD
But the economic quality of that balance is heterogeneous.
If the customer withdraws 150 USD, the system now needs to know how much provisional exposure has escaped the account.
The ledger balance alone cannot answer.
The information was lost when the sources were collapsed into one number.
Balance conservation is not exposure conservation
Traditional ledger correctness focuses on value conservation.
For a balanced transaction:
sum(debits) = sum(credits)
This invariant is essential.
But it says nothing about the conservation of risk attributes attached to value.
Suppose 100 provisional units enter the system.
Those units may later be:
traded
transferred
split
merged
withdrawn
used as collateral
converted into another asset
mixed with final funds
The nominal value remains accounted for, but its associated exposure may disappear from the system model unless lineage is preserved.
A second invariant is therefore needed conceptually:
economic exposure cannot disappear merely because value changed location
If 100 units of reversible value become 100 units of withdrawable value, some component must still carry the reversal exposure.
That component may be:
the customer
the merchant
the platform
a reserve account
a collateral position
an insurer
a liquidity provider
But somebody must carry it.
An architecture that preserves financial balances while losing exposure attribution is numerically correct and economically incomplete.
Lineage is about causality, not ownership
Value lineage is sometimes described as tracing money.
That framing is misleading.
The important question is not necessarily:
“Which exact unit of money moved?”
The useful question is:
“Which earlier economic events causally contributed to this later position or operation?”
This distinction matters because fungibility makes unit-level tracing arbitrary in many account-based systems.
Suppose:
reconciled funds: 80
provisional funds: 20
total balance: 100
The customer spends 10.
There is no natural physical fact determining whether those 10 units came from the reconciled or provisional portion.
The platform must apply an attribution policy.
Possible policies include:
final-first
provisional-first
FIFO
LIFO
proportional attribution
risk-weighted attribution
explicit source reservation
Each produces a different lineage graph.
Therefore lineage is partly derived state.
It is not always an objective property of the asset itself.
Attribution policy must be explicit
Consider:
Source A:
80 final units
Source B:
20 provisional units
Withdrawal:
50 units
Under final-first attribution:
Withdrawal:
50 from Source A
Remaining:
30 final
20 provisional
The provisional exposure remains inside the account.
Under provisional-first attribution:
Withdrawal:
20 from Source B
30 from Source A
Remaining:
50 final
The provisional exposure has now propagated into the withdrawal.
Under proportional attribution:
Withdrawal:
40 final
10 provisional
Remaining:
40 final
10 provisional
All three models preserve nominal balance.
They produce completely different risk outcomes.
This means source allocation cannot be buried inside implementation details.
It is financial policy.
Exact lineage is sometimes artificial
Engineers naturally prefer deterministic answers.
It is tempting to assign each outgoing operation to specific inbound lots.
This can work when the accounting model already preserves discrete lots.
It becomes artificial when funds are continuously pooled.
Imagine a treasury wallet containing millions of units from thousands of customers.
A single blockchain withdrawal is sent from that wallet.
Which deposit funded it?
At the chain level, the answer may be meaningless under an account-based asset model.
The wallet balance funded it.
Trying to assign the withdrawal to one historical deposit may create false precision.
The correct representation may instead be proportional exposure.
For example:
Treasury pool:
60% reconciled customer funds
20% provisional customer funds
10% platform liquidity
10% credit facility
A 100,000-unit withdrawal may then inherit exposure according to pool policy rather than individual deposit identity.
This is less intuitive than lot tracing.
It may be more truthful.
Lot-based lineage
Lot-based accounting treats value sources as identifiable quantities.
For example:
Lot A:
source: deposit_1001
amount_remaining: 500
finality: reconciled
Lot B:
source: deposit_1002
amount_remaining: 300
finality: provisional
An outgoing operation consumes from one or more lots.
A minimal model might look like:
#[derive(Debug, Clone)]
pub struct ValueLot {
pub lot_id: String,
pub source_operation_id: String,
pub asset: String,
pub original_amount: u64,
pub remaining_amount: u64,
pub risk_class: RiskClass,
}
#[derive(Debug, Clone)]
pub struct Consumption {
pub operation_id: String,
pub lot_id: String,
pub consumed_amount: u64,
}
#[derive(Debug, Clone)]
pub enum RiskClass {
Reconciled,
Provisional,
ReversalExposed,
PlatformCredit,
}
The important invariant is:
sum(consumption for lot) <= original lot amount
This approach is useful when source identity materially affects downstream treatment.
Examples include:
provisional deposits
restricted funds
customer collateral
promotional credit
borrowed liquidity
asset-specific reserves
The cost is complexity.
Every split, merge, transfer, conversion, and partial consumption expands the lineage graph.
Lineage graphs
A better conceptual representation is often a directed acyclic graph of economic dependencies.
For example:
Deposit A --------\
\
-> Trade C -> Withdrawal E
/
Deposit B --------/
Deposit D -> Transfer F -> Merchant Payout G
Each node represents an economic operation.
Each edge represents value contribution.
Edges may carry amounts:
Deposit A -- 60 --> Trade C
Deposit B -- 40 --> Trade C
Trade C -- 70 --> Withdrawal E
Trade C -- 30 --> Remaining Position
This graph answers questions that a normal ledger cannot.
If Deposit B reverses, which downstream operations depended on it?
How much exposure reached Withdrawal E?
How much remains internally recoverable?
Where did the original risk migrate?
The graph does not replace the ledger.
The ledger answers:
who owns what?
The lineage graph answers:
what caused what?
These are different questions.
Lineage and double-entry accounting
Value lineage should not mutate accounting semantics.
The ledger remains the authoritative record of balances and obligations.
Lineage is supplementary causal metadata.
Consider:
Customer deposits 1,000
Dr ExternalSettlementReceivable 1,000
Cr CustomerBalance 1,000
If the deposit is provisional, the ledger may additionally represent restrictions or reserve accounts.
The lineage system records:
customer_balance_credit
<- caused_by deposit_881
Later:
customer withdrawal 600
The ledger records the value movement.
The lineage engine records which source exposure contributed to the withdrawal.
This separation is important because lineage policy may evolve without rewriting historical accounting entries.
The journal remains factual.
The lineage model interprets causal dependence.
Internal transfers propagate exposure
Suppose Customer A receives 1,000 provisional units and transfers 600 internally to Customer B.
Customer B then sees an apparently ordinary balance.
If the system treats internal transfer as creating clean value, the provisional exposure disappears.
That is incorrect.
The risk moved.
The transfer should propagate source attributes according to policy:
Deposit X:
1,000 provisional
Transfer A -> B:
600
Customer A:
400 provisional exposure
Customer B:
600 provisional exposure
If Customer B then withdraws 500 externally, the platform must understand that the external withdrawal ultimately depends on Deposit X.
This is where naive per-account risk models fail.
Exposure can cross account boundaries.
The risk belongs to the value lineage, not merely to the account where the uncertainty originated.
Cross-customer contamination
Cross-customer propagation creates an uncomfortable problem.
Customer B may have no relationship with the original risky event.
Yet Customer B received value originating from Customer A.
Should Customer B inherit the same restrictions?
The answer depends on the product.
In some systems, internal transfer settles immediately between internal accounts and the platform chooses to absorb the source risk itself.
Then:
Customer A transfers provisional funds to Customer B
Platform:
assumes reversal liability
Customer B:
receives clean internal balance
The risk did not disappear.
It changed owner.
This transformation should be explicit.
A liability transfer event might record:
LiabilityTransfer:
source_operation: transfer_991
previous_holder: customer_A
new_holder: platform
exposure_amount: 600
policy: internal_transfer_guarantee_v3
Without this record, the platform unknowingly socializes risk.
Conversion between assets
Lineage becomes harder when value changes form.
Suppose provisional USD buys BTC.
The original exposure now backs a different asset.
Example:
Deposit:
10,000 USD provisional
Trade:
sell 10,000 USD
buy 0.15 BTC
If the deposit reverses, the BTC does not magically become invalid.
The platform now has an obligation mismatch.
The lineage relationship is:
provisional USD
-> trade execution
-> BTC position
The exposure must be converted into an economically meaningful quantity.
One approach is to track the source contribution at trade execution time.
For example:
source exposure:
10,000 USD
resulting asset:
0.15 BTC
attribution:
100% of BTC position financed by provisional source
If only 20% of the USD used in the trade was provisional:
BTC exposure ratio = 20%
The resulting risk is no longer naturally measured only in the original asset.
Market movement now matters.
If BTC rises, the downstream asset may exceed the original exposure.
If BTC falls, recovering the original liability may require more than liquidating the resulting asset.
This is where settlement risk becomes market risk.
Lineage transforms risk classes
A risk attribute does not always remain unchanged as value moves.
Suppose provisional USD is converted into BTC and later used as collateral for a loan.
The original settlement risk now interacts with:
market risk
liquidation risk
credit risk
liquidity risk
custody risk
The lineage graph should therefore propagate not merely labels but exposure relationships.
A downstream node may derive new risk from upstream sources.
Conceptually:
R_out =
transform(
R_in,
operation_type,
market_state,
collateral_policy
)
This transformation does not need to be mathematically perfect.
It needs to be explicit enough that the platform knows when an upstream failure can create downstream loss.
Pools destroy simple attribution
Treasury systems frequently pool value.
Customer funds may be held in omnibus wallets or settlement accounts.
The platform may also inject its own liquidity.
Suppose:
Pool total: 10,000,000
8,000,000 reconciled customer funds
1,000,000 provisional customer funds
500,000 platform capital
500,000 credit facility
A 200,000 withdrawal is paid from the same pool.
Lot-level tracing could technically assign some specific historical sources.
That assignment may have no economic meaning.
A pool-based exposure model may be more useful:
provisional_ratio =
provisional_customer_funds / pool_total
Then the platform may track aggregate contingent exposure rather than pretend the withdrawal came from particular deposits.
This is especially appropriate when all pool participants contractually share the same liquidity guarantees.
The lineage model should reflect the actual risk structure, not produce decorative precision.
Source substitution
A crucial concept in pooled systems is source substitution.
Suppose provisional customer funds enter a pool.
The platform immediately makes them available because it has enough own capital to guarantee settlement.
Economically, the customer is no longer spending provisional value.
The platform has substituted its own liquidity for the uncertain source.
The system should record this as a transformation:
provisional customer source
-> platform guarantee
-> clean available customer balance
platform:
retains provisional settlement exposure
This changes lineage.
The customer-facing value is now backed by platform liquidity.
The original provisional deposit becomes an asset or receivable of the platform.
This is a much more accurate model than continuing to tag every downstream customer operation as provisional forever.
Value lineage therefore needs explicit cut points where exposure is absorbed or reassigned.
Exposure boundaries
A lineage graph can grow indefinitely unless the architecture defines where causal propagation stops.
Useful boundaries include:
reconciliation completed
liability transferred
reserve funded
collateral posted
insurance coverage attached
platform guarantee applied
write-off recognized
legal settlement reached
At these points, the original source may no longer need to propagate its risk downstream.
For example:
Deposit X provisional
-> Platform Guarantee G
-> Customer Balance Y clean
Downstream transactions depend on Guarantee G, not directly on Deposit X.
Deposit X still matters to platform treasury and risk.
It no longer contaminates every later customer transaction.
This compression is essential for scalability.
Lineage compression
Exact provenance graphs can become enormous.
A high-volume system may process millions of operations per day.
Keeping every source relationship forever can become operationally expensive.
Lineage can be compressed when several source nodes share equivalent economic properties.
For example:
Sources:
1,000 deposits
same asset
same settlement provider
same finality class
same liability holder
same reversal policy
Instead of preserving each source separately for downstream risk calculation, the system may aggregate them into an exposure bucket.
ExposureBucket:
provider: Bank A
asset: USD
finality: provisional
total_amount: 4,200,000
liability_holder: platform
Detailed historical references remain available for audit.
Operational risk calculations use the compressed representation.
This distinction between archival provenance and active exposure state is important.
Not every query needs the entire causal graph.
UTXO systems and account-based systems
Blockchain architecture exposes this difference clearly.
In a UTXO model, outputs are discrete objects.
An input explicitly consumes previous outputs.
Value lineage exists naturally in the transaction graph.
Even then, economic attribution is not always simple because:
multiple inputs are merged
outputs are split
change outputs are created
coinjoin-like structures obscure ownership
off-chain contracts alter economic interpretation
In account-based systems, value lineage is less explicit.
The account balance changes through ordered state transitions, but individual units have no persistent identity.
A transfer says:
decrease account A by X
increase account B by X
It does not say which historical deposits constituted X.
An internal financial ledger usually resembles the account model more than the UTXO model.
Therefore value lineage must be constructed at the economic-operation level rather than inferred from individual units.
Batching
Payment systems often batch many economic operations into one external transaction.
Suppose 500 customer withdrawals are aggregated into one blockchain transaction.
Internally:
withdrawal_1
withdrawal_2
...
withdrawal_500
Externally:
transaction_hash = 0xabc...
If the external transaction fails or is reorganized, the platform must map the result back to all 500 business operations.
The external artifact has many parents.
Likewise, a single bank settlement record may represent net settlement for thousands of internal transactions.
This creates many-to-one lineage.
The opposite occurs when one business operation uses several external attempts or rails.
That produces one-to-many lineage.
Real systems therefore need:
one-to-one
one-to-many
many-to-one
many-to-many
causal relationships.
A single parent_transaction_id field will not survive this reality for long.
Netting
Net settlement complicates lineage further.
Suppose a platform owes Bank A 10 million and Bank A owes the platform 9 million.
Only 1 million moves externally.
Internally, however, 19 million of gross economic obligations existed.
The external movement does not map directly to individual internal transactions.
Lineage must preserve the relationship between gross obligations and net settlement.
For example:
SettlementBatch:
gross_payable: 10M
gross_receivable: 9M
net_external_settlement: 1M
The external 1 million cannot be naively attributed to the last 1 million of outgoing transactions.
It represents the net effect of a larger set of obligations.
This is another place where exact unit tracing becomes fiction.
The correct lineage object is the settlement batch.
Reversals across netted positions
Suppose one transaction inside a previously netted batch later reverses.
The original net external settlement remains historically correct.
The reversal creates a new obligation that will participate in a later settlement cycle.
This means lineage crosses settlement batches over time.
The causal chain may be:
payment P
-> settlement batch S1
-> net transfer T1
later:
reversal R
-> obligation O
-> settlement batch S2
-> net transfer T2
A system that rewrites S1 cannot represent this properly.
The original settlement batch must remain immutable.
The reversal becomes a new economic event with lineage back to P.
Lineage and reconciliation
Reconciliation becomes far more powerful when it can operate over causal relationships.
Instead of merely asking:
Does internal amount equal external amount?
the system can ask:
Which internal operations contributed to this external settlement?
Which external observations provide evidence for this internal operation?
Which provisional sources remain unresolved?
Which reversals produced open compensation obligations?
Which exposure bucket is currently under-collateralized?
Lineage transforms reconciliation from record matching into causal verification.
This is particularly useful in aggregated, netted, or retried workflows where one-to-one matching does not exist.
Formal invariants
Value lineage can be subjected to explicit correctness properties.
For every source lot:
consumed_amount + remaining_amount = original_amount
For every consumption:
consumed_amount >= 0
and:
consumed_amount <= source_remaining_before_consumption
For every transformation:
input_value
-> output_value + fees + realized_gain_or_loss
For provisional exposure:
unresolved_source_exposure
=
internal_exposure
+ propagated_exposure
+ transferred_liability
+ absorbed_loss
Nothing should disappear.
For liability transfer:
old_holder_exposure_after
+
new_holder_exposure_after
=
total_exposure_before
subject to explicit settlement, collateralization, insurance, or write-off events.
These invariants are more useful than asking whether every downstream operation has a neat parent ID.
Lineage under partial failure
Lineage updates must survive distributed failure.
Suppose a withdrawal commits in the ledger but the lineage service crashes before recording source consumption.
The financial balance is correct.
The causal model is now stale.
If later risk calculations depend on lineage, the system may release more provisional value than intended.
This means lineage updates cannot be treated as optional analytics.
If lineage participates in safety decisions, it must have reliability guarantees comparable to the ledger state it interprets.
Possible architectures include:
same atomic transaction
transactional outbox
deterministic replay from ledger events
event-sourced lineage reconstruction
The exact choice depends on system boundaries.
The important property is that lineage must be recoverable from authoritative events.
If its state can diverge permanently from the ledger, it cannot safely govern availability.
Deterministic reconstruction
A strong design treats lineage as a deterministic projection of financial events plus versioned attribution policy.
Conceptually:
LineageState_n =
reduce(
LineageState_n-1,
FinancialEvent_n,
AttributionPolicy_v
)
This allows rebuilding the lineage graph after corruption or software changes.
But policy versioning is critical.
If FIFO was used historically and the platform later switches to proportional attribution, replaying old events under the new policy would rewrite historical exposure.
Each attribution decision must therefore preserve its policy version.
Causality must be reproducible.
Privacy concerns
Detailed value lineage can become sensitive.
A lineage graph may reveal:
customer relationships
merchant flows
treasury strategy
risk classifications
credit dependencies
counterparty concentration
internal liquidity structure
Not every service should have unrestricted access.
This suggests separating:
lineage identity
lineage attributes
risk projection
audit evidence
A downstream service may only need to know:
20% reversal-exposed
It may not need to know which customer deposit created that exposure.
A reconciliation system may need detailed source references.
A customer-facing application may need none of them.
Value provenance should obey least-privilege principles like any other sensitive state.
Lineage does not mean surveillance
There is an architectural temptation to turn value lineage into universal transaction tracing.
That is not the goal.
The system should preserve causal information only where it supports legitimate requirements such as:
financial correctness
risk management
reconciliation
compliance
reversal handling
liability
auditability
Tracking every possible relationship indefinitely creates privacy risk, operational complexity, and false analytical confidence.
Lineage should be designed around specific invariants and questions.
If no system decision depends on a particular relationship, storing it forever may provide little value.
Observability
A value-lineage system needs operational visibility of its own.
Useful metrics include:
total unresolved exposure
propagated exposure
exposure by source class
exposure by destination domain
number of lineage edges
lineage reconstruction lag
unattributed balance
orphaned consumption events
liability transfer volume
exposure absorbed by platform
One metric is particularly important:
unattributed_risk_exposure
This represents value whose nominal accounting is understood but whose economic risk owner cannot currently be determined.
That number should be extremely boring.
A growing unattributed exposure means the system is losing causal information faster than it can reconcile it.
The danger of perfect-looking lineage
A lineage system can be wrong while looking beautifully precise.
Suppose engineers choose FIFO simply because it is easy.
Every withdrawal now has exact source assignments.
Dashboards look excellent.
Auditors can trace every path.
But if the economic agreements between parties do not actually imply FIFO risk attribution, the system has produced highly structured fiction.
Precision is not correctness.
Attribution policies must reflect contractual, accounting, settlement, and risk semantics.
The model should be as precise as reality permits and no more.
When lineage should stop
Not every value source should remain traceable forever.
Lineage can terminate when the relevant uncertainty has been resolved.
For example:
provisional deposit
-> reconciled
Once reconciliation eliminates the source-specific reversal risk, downstream operations may no longer need that provenance for liquidity decisions.
Likewise:
provisional source
-> platform guarantee
The customer-side lineage may terminate at the guarantee boundary.
The platform treasury system still tracks the original source.
Different domains may therefore preserve different depths of lineage.
This is not inconsistency.
It is separation of concerns.
Architecture
A practical value-lineage subsystem might consume authoritative financial events and produce exposure projections.
Conceptually:
Ledger Events
|
v
Source Classification
|
v
Attribution Engine
|
v
Lineage Graph
|
+----> Risk Exposure Projection
|
+----> Availability Engine
|
+----> Reconciliation
|
+----> Compensation Engine
|
+----> Audit Queries
The ledger remains authoritative for money.
The lineage system remains authoritative for causal attribution.
The risk engine consumes lineage but does not rewrite it.
The compensation engine uses lineage to identify where exposure propagated.
The reconciliation engine verifies that internal causal claims remain consistent with external evidence.
Conclusion
Fungible ledgers intentionally erase unit identity.
That is normally desirable.
The problem begins when different units of the same nominal asset carry different settlement quality, reversal risk, legal restrictions, collateral backing, or liability.
At that point, an aggregate balance is no longer sufficient to answer the system’s risk questions.
Value lineage restores causal structure without pretending that fungible money consists of individually traceable objects.
A resilient architecture distinguishes accounting ownership from causal attribution, makes source-consumption policy explicit, propagates exposure across transfers and transformations, models liability transfer, compresses lineage where appropriate, and defines clear boundaries where source-specific risk is absorbed or resolved.
The system should be able to answer:
Which uncertain sources contributed to this current position?
Where did their exposure propagate?
Which downstream operations depend on them?
Who carries that exposure now?
At what boundary does that causal relationship stop mattering?
Those questions are not accounting trivia.
They determine whether a platform understands its own balance sheet when settlement assumptions fail.
A ledger tells you where value is.
Lineage tells you what that value still depends on.
