Abstract

Financial systems are full of assertions.

A balance is available. A payment is settled. A customer may withdraw. A reserve is sufficient. A transaction is compliant. A collateral position is healthy. A provider has confirmed settlement.

Most architectures represent these assertions as state.

withdrawable = true
settled = true
available_balance = 250000

The problem is that the assertion usually becomes detached from the evidence that justified it.

Downstream services inherit the conclusion without inheriting its proof context. A payment service sees settled=true but does not know whether that conclusion came from a processor webhook, a bank statement, reconciliation-grade evidence, a manual override, or a stale provider response. A treasury service sees available liquidity but cannot determine which portion is externally confirmed, guaranteed, provisional, or dependent on a policy exception.

The system carries state.

It loses justification.

This article develops a different model: proof-carrying financial state.

In this model, economically relevant permissions are accompanied by durable evidence references, policy identity, state versions, trust assumptions, freshness requirements, and the authority that produced the conclusion. Downstream systems do not need to reconstruct the entire world, but they can verify that a claim satisfies the proof class required for the action they are about to perform.

The goal is not to place cryptographic proofs around every database row.

The goal is much more practical.

A financial system should never have to trust an economically significant claim without being able to answer:

What evidence supports this claim?

Who was allowed to make it?

Which policy transformed that evidence into this conclusion?

When was that conclusion valid?

And is that proof still strong enough for the operation we are about to execute?

State without justification

Consider a withdrawal service receiving:

{
  "account_id": "acct_8821",
  "available_balance": 500000,
  "withdrawable": true
}

The service has everything it needs to continue.

Or so it appears.

What does withdrawable = true mean?

Perhaps the inbound funds were fully reconciled.

Perhaps they were only operationally confirmed.

Perhaps the platform granted provisional availability.

Perhaps treasury explicitly guaranteed the exposure.

Perhaps a human operator manually released the funds.

Perhaps the field was calculated before a settlement reversal arrived.

Perhaps the service that calculated it was operating on a stale replica.

All of these cases can produce the same JSON.

The downstream service receives a conclusion with no visible causal structure.

This is a trust compression boundary.

The complexity of the upstream system has been reduced to a boolean.

Sometimes that is exactly what we want.

But if the downstream action can create irreversible economic consequences, the boolean alone is not enough.

Proof-carrying state

Instead of representing only the conclusion:

withdrawable = true

represent the conclusion together with the justification that made it valid.

Conceptually:

EconomicClaim:
    subject
    claim
    amount
    asset
    proof_class
    evidence_refs
    policy_digest
    state_version
    issued_at
    valid_until
    issuer

For example:

EconomicClaim:
    subject: account_8821
    claim: withdrawable_balance
    amount: 500000
    asset: USD

    proof_class: authoritative

    evidence_refs:
        settlement_441
        reconciliation_882
        reserve_snapshot_191

    policy_digest: 7e9c...91a
    state_version: ledger_884192

    issued_at: 14:04:12
    valid_until: 14:09:12

    issuer: availability_engine

Now the withdrawal service receives more than an answer.

It receives a claim it can evaluate.

The consumer may not need to understand every settlement event.

It only needs to verify that:

proof_class >= required_proof_class

and that the claim remains valid for the operation being attempted.

A proof is not necessarily cryptographic

The word proof deserves care.

In this context, proof does not automatically mean a zero-knowledge proof, theorem proof, SNARK, or cryptographic certificate.

Sometimes the proof is simply a durable chain of authoritative evidence.

For example:

provider transaction reference
+
bank settlement record
+
internal ledger version
+
policy evaluation result

Cryptography can protect integrity.

Formal verification can prove properties of the policy engine.

Digital signatures can bind an issuer to an assertion.

Hash commitments can make evidence sets tamper-evident.

But none of these mechanisms magically prove that the underlying economic event happened.

A signed lie remains a lie.

A valid hash proves integrity of data, not truth of the world represented by the data.

Proof-carrying financial state therefore separates:

evidence authenticity
evidence authority
policy correctness
claim validity

These are different properties.

Claims are scoped

A common architectural mistake is treating a strong claim in one domain as sufficient proof in another.

Suppose custody produces:

signature_created = true

That proves something useful.

It does not prove:

transaction_settled = true

Likewise:

blockchain_inclusion = confirmed

does not necessarily prove:

customer_funds_unconditionally_withdrawable = true

because compliance holds, liquidity constraints, or reversal policies may still apply.

A proof-carrying model therefore scopes claims precisely.

Instead of:

transaction_ok

use claims such as:

signature_authorized
transaction_submitted
transaction_included
settlement_operationally_final
settlement_reconciled
funds_internally_transferable
funds_externally_withdrawable

A claim should prove only what its evidence actually supports.

Permission is derived from proof

This leads to a clean separation.

Evidence says what was observed.

Claims say what can be concluded.

Permissions say what the system is allowed to do.

Evidence
    |
    v
Claim Evaluation
    |
    v
Economic Claim
    |
    v
Permission Evaluation
    |
    v
Action

For example:

bank settlement observed
    ->
settlement_authoritative
    ->
external_withdrawal_allowed

But another operation may require less:

processor accepted
    ->
settlement_operational
    ->
balance_display_allowed

The same transaction can therefore support different permissions at different proof strengths.

Proof classes

A useful architecture defines proof classes.

For example:

Observed
Corroborated
Authoritative
Reconciled

Observed means a relevant source reported the event.

Corroborated means additional independent evidence supports the claim.

Authoritative means an authority for the relevant domain confirmed it.

Reconciled means internal and external accounting evidence agree.

These classes should not be treated as universally ordered unless the domain semantics actually support that ordering.

For some claims:

Observed < Authoritative < Reconciled

may make sense.

For another claim, reconciliation may not strengthen the property being checked.

The proof lattice should reflect actual semantics rather than satisfying our understandable human desire to put everything in one neat enum.

Proof requirements belong to actions

Suppose the system defines:

DisplayBalance:
    requires Observed

InternalTransfer:
    requires Corroborated

ExternalWithdrawal:
    requires Authoritative

TreasuryLiquidityRelease:
    requires Reconciled

Now the permission boundary is explicit.

A developer adding a new withdrawal path cannot merely check:

balance > amount

The operation has a proof requirement.

This is powerful because proof requirements become part of the business invariant.

The same balance can support different permissions

Consider:

Ledger balance:        100,000
Observed settlement:   100,000
Authoritative:           80,000
Reconciled:              60,000

The account does not have four different balances.

It has one accounting position supported by different levels of evidence.

The platform may derive:

displayable:             100,000
internally_spendable:     90,000
externally_withdrawable:  80,000
treasury_usable:          60,000

This is much more precise than:

available_balance = 100000

because availability is permission-dependent.

Proof-carrying balances

One possible representation is a balance accompanied by evidence partitions.

For example:

BalanceView:
    account: acct_8821
    asset: USD

    ledger_balance: 100000

    proof_bands:
        observed:      100000
        corroborated:   90000
        authoritative:  80000
        reconciled:     60000

A withdrawal service requiring authoritative backing can immediately derive:

max_withdrawable = 80000

A treasury system requiring reconciliation-grade evidence sees:

deployable_liquidity = 60000

The accounting system remains unchanged.

What changes is how economic authority is projected from the accounting state.

Proof bands must conserve value

A subtle problem appears if evidence bands are calculated independently.

Suppose:

observed = 100
authoritative = 90
reconciled = 80

That is coherent if stronger classes are subsets of weaker ones.

But if independent calculations produce:

observed = 100
authoritative = 90
reconciled = 110

the projection is inconsistent.

If proof classes are hierarchical, an invariant should hold:

reconciled
<= authoritative
<= corroborated
<= observed
<= ledger_balance

If the proof model is not hierarchical, the system needs another structure.

The important point is that proof projections need invariants of their own.

Evidence references instead of evidence copies

Proof-carrying state should not copy every underlying event into every claim.

That becomes unmanageable.

Instead, claims can reference immutable evidence objects:

evidence_refs:
    evt_991
    stmt_441
    rec_228

Each evidence object contains:

source
claim
subject
source_time
observed_at
coverage
authority
integrity metadata

This keeps the claim compact while preserving traceability.

Evidence sets need identity

Suppose a decision depends on 200 evidence records.

A consumer does not necessarily need all 200 records inline.

The evidence set can have a canonical digest:

evidence_set_digest =
    H(
        canonicalize(
            evidence_id_1,
            evidence_id_2,
            ...
        )
    )

The claim then contains:

evidence_set_digest

plus references needed to retrieve the evidence.

This gives the claim a stable identity tied to the exact evidence used.

Policy is part of the proof

Evidence does not transform itself into permission.

Policy does.

Suppose the evidence says:

5 confirmations

The system concludes:

operationally_final

only because a policy says five confirmations are sufficient for this asset, network, amount, and risk class.

Therefore the proof of the final claim includes:

evidence
+
policy

not evidence alone.

This is why:

policy_version = v12

is weaker than it looks.

A version label tells us which release was intended.

A policy digest can identify the actual policy artifact.

For example:

policy_digest = SHA256(canonical_policy)

Then:

Claim =
    Evaluate(
        evidence_set,
        policy_digest
    )

becomes reproducible.

Policy digest is still not enough

The same policy can produce different conclusions depending on input state.

Suppose withdrawal policy uses:

current liquidity
customer risk tier
provider headroom
reversal exposure

The claim should therefore preserve references to the decision-time inputs.

Conceptually:

DecisionContext:
    policy_digest
    evidence_set_digest
    ledger_version
    liquidity_snapshot
    risk_snapshot

Now the system can reconstruct the exact environment in which the claim was issued.

Claims expire

A proof may be correct when issued and unsafe ten minutes later.

Suppose:

withdrawable_balance = 500000

was derived when liquidity was abundant.

Then several large withdrawals settle.

The original claim may no longer be safe.

Therefore economically actionable claims often need a validity window.

issued_at
valid_until

Or they need to bind to a specific state version:

valid_while:
    liquidity_version == 881

Once the referenced state changes, the claim must be reevaluated.

Freshness is part of proof semantics

Some claims age rapidly.

For example:

provider_healthy
available_liquidity
market_price
withdrawal_capacity

Others are effectively historical facts:

signature_created
ledger_entry_committed
transaction_included_at_block_881

The proof architecture should distinguish these.

A universal five-minute TTL is not semantics.

It is an act of surrender disguised as configuration.

Time-of-check to time-of-use

Proof-carrying state does not automatically solve TOCTOU problems.

Suppose:

14:00:00 claim says 500k withdrawable
14:00:01 another withdrawal reserves 400k
14:00:02 current request tries to withdraw 500k

The claim was valid.

The operation is no longer valid.

The execution boundary therefore needs to bind proof verification to state mutation.

For example:

verify claim
verify state_version
reserve funds
commit withdrawal

must occur atomically with respect to the authoritative ledger state.

Otherwise proof becomes a stale certificate.

State version binding

A claim can contain:

ledger_version = 88192

The consumer verifies:

current_ledger_version == 88192

before execution.

If not:

claim invalid for execution

This forces reevaluation.

For high-throughput systems, exact global versions may be too expensive.

The binding may instead reference:

account_version
balance_version
reserve_version
provider_capacity_version

The relevant state scope should be as narrow as correctness permits.

Reservations turn proof into commitment

Another approach is to issue claims only after reserving the underlying capacity.

Suppose the system decides:

500k withdrawable

It simultaneously creates:

WithdrawalCapacityReservation:
    amount: 500k
    account: acct_8821
    expires_at: 14:00:30

Now the claim does not merely describe capacity.

It owns a temporary portion of it.

This is stronger.

The consumer presents the reservation when executing the withdrawal.

Proof versus capability

This distinction is useful.

A proof says:

you satisfy the conditions

A capability says:

you are authorized to exercise this specific permission

For example:

proof:
    account has >= 500k authoritative funds

capability:
    withdrawal service may consume 500k
    before 14:00:30

Financial systems often need both.

Capability tokens

A capability might look conceptually like:

EconomicCapability:
    capability_id
    subject
    action
    amount
    asset
    proof_ref
    issued_at
    expires_at
    nonce
    issuer

It may be digitally signed:

signature = Sign(
    issuer_key,
    canonical_capability
)

Now a downstream service can verify:

issuer authenticity
integrity
expiration
scope

without trusting arbitrary caller-provided flags.

Capabilities must be single-use where necessary

Suppose the capability authorizes:

withdraw 500k

If it can be replayed twice, the proof system has invented a delightful new withdrawal multiplier.

Capabilities therefore need replay protection.

Possible mechanisms include:

single-use nonce
consumption record
idempotency key
ledger reservation

The authoritative state transition must ensure:

capability consumed <= authorized amount

Partial consumption

A 500k capability may permit:

withdraw up to 500k

If the user withdraws 200k, what happens to the remaining 300k?

Possible semantics:

capability fully consumed

or:

remaining authority = 300k

The choice must be explicit.

Partial capabilities require an authoritative remaining-capacity state.

Otherwise replay prevention becomes ambiguous.

Proof composition

Distributed financial operations require several independent claims.

A withdrawal might require:

funds_available
KYC_valid
withdrawal_policy_passed
destination_allowed
custody_authorized
liquidity_available

No single subsystem owns all these facts.

The final authorization is a composition:

WithdrawalAuthorized =
    FundsProof
    AND IdentityProof
    AND ComplianceProof
    AND LiquidityProof
    AND CustodyPolicyProof

The proof object can reference the component claims.

Composite proofs

Conceptually:

CompositeClaim:
    action: withdrawal
    components:
        funds_claim_991
        compliance_claim_441
        liquidity_claim_228
        custody_claim_771
    policy_digest: ...

The final claim is valid only while every required component remains valid.

This immediately introduces revocation.

Revocation

Suppose compliance approves a customer.

Five minutes later:

sanctions_status changes

Previously issued withdrawal capabilities may still exist.

The system needs a revocation model.

Possible strategies include:

short-lived capabilities
revocation lists
state-version invalidation
online validation at execution

Each has different latency and operational costs.

For high-risk financial actions, short expiration plus execution-time state verification is usually much safer than long-lived bearer authority.

Revocation is not deletion

If a claim becomes invalid, the historical claim should remain.

The system needs to know:

claim was valid from T1 to T2
revoked at T2
reason R

This preserves decision provenance.

The claim did exist.

It simply no longer grants present authority.

Reversal changes proof

Suppose settlement was reconciled.

A withdrawal capability was issued.

Then a valid reversal arrives before the capability is exercised.

The reversal should invalidate the economic permission.

The knowledge state becomes:

settlement occurred
reversal occurred

The capability state becomes:

revoked

Again, historical facts remain.

Current permission changes.

Proof chains

A complex financial permission may have a chain:

Bank Settlement Evidence
        |
        v
Settlement Claim
        |
        v
Available Balance Claim
        |
        v
Withdrawal Capability
        |
        v
External Settlement

If the original bank evidence later changes meaning because of a reversal, the platform can traverse the dependency chain.

This is where proof-carrying state meets value lineage.

Proof lineage

Every derived claim should preserve:

parent_claims
evidence_refs
policy_digest

The result is a claim graph.

For example:

bank_entry_441
    -> settlement_claim_882
        -> availability_claim_991
            -> withdrawal_capability_112

This graph answers:

Which permissions depended on this evidence?

That is a very powerful incident-response primitive.

Invalidating descendants

Suppose:

settlement_claim_882

is invalidated.

The system can identify descendants:

availability_claim_991
withdrawal_capability_112

If the capability has not been exercised:

revoke it

If it has already been exercised:

create compensation obligation

The architecture now distinguishes prevention from recovery.

Proof failure after action

This is inevitable.

No proof system can prevent later economic reality from changing.

Suppose:

withdrawal executed

and then:

upstream settlement reversed

The proof was valid under the information and policy available at execution.

The system still faces a loss.

Proof-carrying state does not eliminate risk.

It tells us exactly:

which evidence supported the action
which policy accepted the risk
which party sponsored the uncertainty

That transforms an unexplained loss into an attributable economic decision.

Proof classes and uncertainty budgets

Proof strength can connect directly to epistemic capacity.

Suppose:

Observed        weight 1.0
Corroborated    weight 0.6
Authoritative   weight 0.2
Reconciled      weight 0.0

Then 1M at Observed consumes more uncertainty budget than 1M at Authoritative.

A stronger proof releases epistemic capacity.

This creates a direct relationship:

evidence strengthens
    ->
proof class strengthens
    ->
uncertainty decreases
    ->
capacity returns

The architecture becomes internally coherent.

Proof-carrying settlement

Consider a settlement receipt:

SettlementReceipt:
    operation_id
    amount
    asset
    settlement_state
    proof_class
    reversal_class
    reversible_until
    evidence_set_digest
    policy_digest
    issued_at

Downstream services no longer ask:

is settled?

They ask:

is this settlement proof sufficient
for the action I want to perform?

That is a much safer API.

Proof-carrying liquidity

Liquidity is another obvious candidate.

Instead of:

available_liquidity = 20M

treasury could produce:

LiquidityClaim:
    asset: USD
    amount: 20M
    usable_for: same_day_settlement
    evidence:
        bank_balance_snapshot
        reserve_positions
        committed_outflows
    proof_class: authoritative
    state_version: treasury_881
    valid_until: 14:01:00

A settlement orchestrator can verify this claim before admitting additional commitments.

Liquidity proof must account for existing reservations

If:

liquidity = 20M

but:

already committed outflows = 15M

the usable liquidity is not 20M.

Therefore:

LiquidityClaim

must either represent net headroom or reference the reservations included in the calculation.

Otherwise several consumers may independently spend the same liquidity.

This is the economic equivalent of double allocation.

Proof-carrying guarantees

Earlier articles treated guarantees as capacity-bounded absorption nodes.

A guarantee can also issue proof-carrying capacity claims:

GuaranteeClaim:
    guarantee_id
    nominal_capacity
    effective_capacity
    backing_evidence
    policy_digest
    already_reserved
    remaining_capacity
    valid_until

Consumers can then reserve capacity instead of merely reading a number.

Proof-carrying compliance decisions

Compliance systems frequently return:

allowed = true

That is another dangerous boolean.

A stronger claim might include:

ComplianceClaim:
    subject
    action
    jurisdiction
    policy_digest
    evidence_refs
    decision
    issued_at
    expires_at

A downstream service now knows exactly which action was approved under which policy.

A generic approval cannot accidentally migrate into another context.

Scope prevents authority leakage

Suppose compliance approves:

allow_internal_transfer

A badly designed system may treat this as:

customer_compliant = true

and later allow external withdrawal.

Proof-carrying claims prevent this by binding permission to scope.

claim.action = internal_transfer

does not satisfy:

required.action = external_withdrawal

The claim fails closed without requiring every consumer to understand all compliance logic.

Cryptographic integrity

Proof objects are particularly useful across trust boundaries.

A service can sign a claim:

signature =
    Sign(
        issuer_private_key,
        canonical_claim
    )

Consumers verify:

Verify(
    issuer_public_key,
    canonical_claim,
    signature
)

This protects against mutation and unauthorized claim creation.

But again:

signature_valid

means:

authorized issuer produced this claim

It does not mean:

claim corresponds to reality

The evidence and issuer authority still matter.

Trust anchors

The proof system therefore needs trust anchors.

For example:

which service may issue liquidity claims?
which system may issue settlement claims?
which operator may override availability?
which key signs those claims?

Trust configuration becomes security-critical infrastructure.

If every service can issue:

withdrawable = true

with a valid signature, we have successfully cryptographically secured chaos.

Key rotation

Signed economic claims introduce key-management requirements.

The verifier must know:

which key was valid when claim was issued

Key rotation must preserve verification of historical claims.

That suggests:

issuer_id
key_id
issued_at

plus durable key history.

Revoked keys complicate semantics further.

A key revoked because of scheduled rotation is different from a key revoked because it was compromised.

Historical claims may remain valid in the first case and require review in the second.

Compromised issuer

Suppose the availability engine's signing key is compromised.

An attacker may have issued false withdrawal capabilities.

The platform needs to determine:

which claims were signed by compromised key
during affected interval

Proof-carrying state dramatically improves this investigation because claim identity and issuer provenance are explicit.

The same mechanism that creates trust also defines the blast radius when trust fails.

Proof persistence

Should proofs live forever?

Not necessarily.

Different data has different retention requirements.

The system may preserve:

claim metadata
policy digest
evidence digest
critical evidence
audit references

while archiving bulky raw observations separately.

The important property is that economically material historical decisions remain explainable for the required retention period.

Proof compression

At scale, carrying complete proof chains becomes expensive.

Suppose a balance depends on millions of reconciled transactions.

No consumer wants a million evidence references.

The proof needs compression.

One approach is checkpointing.

BalanceCheckpoint:
    account
    balance
    state_version
    evidence_root
    reconciled_through

Subsequent claims depend on:

checkpoint + delta evidence

instead of the entire history.

Merkle commitments

Evidence sets can be committed using a Merkle tree.

For example:

evidence_root = MerkleRoot(evidence_records)

The claim stores:

evidence_root

A later audit can prove inclusion of a particular evidence record without carrying the entire set.

This gives efficient tamper evidence.

It does not solve semantic correctness.

Still, it is useful infrastructure.

Proof checkpoints need authority

A checkpoint compresses history.

That makes the checkpoint issuer important.

If the platform accepts:

reconciled_balance = 50M

as a new root of trust, it needs to know which process was authorized to produce that checkpoint and what invariants were checked.

Otherwise compression becomes a way to forget inconvenient provenance.

Proof garbage collection

Once a stronger checkpoint subsumes older evidence, some operational lineage may be compacted.

For example:

millions of individual settlement claims
    ->
reconciled ledger checkpoint

The detailed evidence may move to archival storage.

The active control plane uses the checkpoint.

This keeps proof-carrying state practical at scale.

Formal properties

The model supports explicit invariants.

First:

Every economic permission
must reference a valid claim.

Second:

Every claim
must reference sufficient evidence
and an identifiable policy.

Third:

Every capability
must be scoped to a specific action.

Fourth:

No capability may authorize
more economic value
than the capacity reserved for it.

Fifth:

A claim derived from stale state
must not remain executable
after its validity condition fails.

Sixth:

Revocation must preserve historical provenance.

Seventh:

Every irreversible action
must be attributable to the proof context
that authorized it.

These are architectural properties, not dashboard preferences.

A Rust model

A simplified representation might look like:

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum ProofClass {
    Observed,
    Corroborated,
    Authoritative,
    Reconciled,
}

#[derive(Debug, Clone)]
pub struct EconomicClaim {
    pub claim_id: String,
    pub subject_id: String,
    pub claim_type: ClaimType,
    pub amount: u64,
    pub asset: String,
    pub proof_class: ProofClass,
    pub evidence_refs: Vec<String>,
    pub policy_digest: [u8; 32],
    pub state_version: u64,
    pub issued_at: u64,
    pub valid_until: u64,
    pub issuer_id: String,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum ClaimType {
    InternallySpendable,
    ExternallyWithdrawable,
    SettlementFinal,
    TreasuryUsable,
}

Then a capability:

#[derive(Debug, Clone)]
pub struct EconomicCapability {
    pub capability_id: String,
    pub claim_id: String,
    pub action: Action,
    pub amount: u64,
    pub asset: String,
    pub nonce: [u8; 32],
    pub issued_at: u64,
    pub expires_at: u64,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum Action {
    InternalTransfer,
    Trade,
    ExternalWithdrawal,
}

The exact types are less important than the separation.

A claim describes justified state.

A capability authorizes a specific use of that state.

Verification at execution

A withdrawal boundary might perform:

1. authenticate capability issuer
2. verify capability integrity
3. verify expiration
4. verify action scope
5. verify asset and amount
6. verify parent claim
7. verify claim proof class
8. verify referenced state version
9. verify capability has not been consumed
10. atomically reserve and consume authority

Only then does external settlement begin.

That sounds heavier than:

if balance >= amount

because it is.

The second implementation simply hides the same complexity in assumptions.

Failure semantics

Verification can fail for many reasons:

claim expired
claim revoked
state changed
proof class insufficient
capability already consumed
issuer no longer trusted
evidence conflict discovered

These are not generic authorization failures.

They have different recovery behavior.

For example:

state changed
    -> reevaluate

proof insufficient
    -> acquire stronger evidence

revoked
    -> reject

already consumed
    -> idempotent success or replay attack

The failure model should preserve those distinctions.

Proof acquisition can become part of orchestration

Suppose a withdrawal requires Authoritative, but the current balance is only Corroborated.

The orchestrator may request stronger evidence.

current proof insufficient
    ->
trigger reconciliation or provider query
    ->
new evidence arrives
    ->
claim upgraded
    ->
withdrawal continues

Proof acquisition becomes an active workflow.

This connects directly to epistemic capacity.

The system spends operational effort to acquire evidence because evidence unlocks economic authority.

Evidence has marginal value

Suppose two transactions are pending.

Transaction A:

amount = 100

Transaction B:

amount = 5M

Both need one additional authoritative observation.

If evidence acquisition capacity is constrained, resolving B may restore far more economic capacity.

The proof system can therefore drive reconciliation priorities.

Proof-carrying state across services

The biggest architectural benefit appears at service boundaries.

Instead of:

{
  "status": "completed"
}

a service returns:

{
  "claim_id": "claim_882",
  "claim": "settlement_final",
  "proof_class": "authoritative",
  "valid_until": "...",
  "state_version": 8841
}

The detailed proof can be retrieved or verified through a dedicated mechanism.

The downstream contract now communicates semantics instead of optimism.

Avoid turning proofs into distributed database joins

There is a trap here.

If every request requires synchronously walking ten services to reconstruct proof, the architecture becomes unusable.

Claims should therefore be materialized.

Evidence verification happens when the claim is issued.

Consumers verify the claim itself plus any state freshness requirements.

This is analogous to issuing a certificate after performing a deeper verification process.

The system trades repeated reconstruction for bounded trust in the claim issuer.

The issuer becomes a fault domain

Materialized claims introduce a new risk.

If the issuer is wrong, many consumers inherit the error.

This is unavoidable.

The architecture should therefore constrain each issuer's authority.

For example:

settlement_claim_service
    may issue settlement claims

availability_engine
    may issue availability claims

treasury_engine
    may issue liquidity claims

No service receives universal economic authority.

Separation of claim authorities

This creates a form of economic least privilege.

A service should be able to assert only the facts it owns.

For example:

custody cannot declare reconciliation complete

reconciliation cannot authorize custody signing

risk cannot alter ledger history

ledger cannot declare external settlement

This prevents architectural authority from leaking through convenient APIs.

Multi-party authorization

Some claims may require several authorities.

For example:

high-value withdrawal

could require:

availability claim
AND compliance claim
AND custody authorization
AND treasury liquidity claim

No single subsystem can authorize the operation alone.

This resembles threshold authorization at the architectural level.

The security property is significant.

Compromising one service may no longer be enough to create an economically valid action.

Cryptographic threshold claims

In higher-assurance systems, multiple authorities could co-sign a capability.

Conceptually:

Capability C

Signatures:
    Risk
    Treasury
    Custody

Execution requires:

valid_signatures >= threshold

This is not appropriate everywhere.

It increases latency and operational complexity.

For high-value operations, however, it can reduce single-service authority considerably.

Proof-carrying state and formal verification

This architecture creates useful formal boundaries.

For example, define:

ExecuteWithdrawal(c, s)

where:

c is a capability and s is current system state.

A safety property might be:

ExecuteWithdrawal(c, s)
implies
ValidCapability(c, s)

Then:

ValidCapability(c, s)
implies
SufficientFunds(c, s)
AND
SufficientProof(c)
AND
Unconsumed(c)
AND
AuthorizedIssuer(c)
AND
WithinValidityWindow(c)

The verification boundary is explicit enough to model.

Another invariant

Suppose Reserved(c) is the economic capacity reserved for capability c.

Then:

ExecutedAmount(c) <= Reserved(c)

For multiple capabilities over the same resource:

sum(Reserved(c_i))
<=
AvailableCapacity

This prevents double allocation.

Proof validity is not transaction success

A valid withdrawal capability means the operation is authorized to begin.

It does not mean external settlement will succeed.

This distinction must remain sharp.

authorization proof
!=
execution proof

After execution, another claim may be produced:

transaction_submitted

then:

transaction_included

then:

settlement_final

The proof chain evolves with the operation.

The transaction carries its own history of justified claims

A complex operation might therefore look like:

Intent
    ->
Authorization Capability
    ->
Funds Reserved
    ->
Custody Authorized
    ->
Signed
    ->
Submitted
    ->
Included
    ->
Operationally Final
    ->
Reconciled

Every stage is backed by a claim.

The transaction state is not one mutable status.

It is an accumulation of justified facts.

Incident reconstruction

Suppose the system later discovers a bad settlement.

Investigators can ask:

Which withdrawal capabilities depended on this settlement claim?

Then:

Which were exercised?

Then:

Which downstream settlements became irreversible?

Then:

Which compensation obligations must now exist?

This is vastly better than searching logs for a transaction ID and hoping distributed timestamps tell a coherent story.

Auditing

An auditor can inspect:

claim
evidence
issuer
policy
state version
action

rather than reconstructing causal history from application logs.

This does not remove the need for logs.

It changes their role.

Logs explain implementation behavior.

Proof-carrying state explains economic authority.

The cost

There is no free version of this architecture.

It adds:

claim storage
policy identity
evidence indexing
issuer trust management
revocation
key management
state versioning
capability consumption
proof retention

The design is justified where the economic cost of unexplained authority exceeds the operational cost of explicit proof.

Not every button in a fintech application needs a signed capability.

A 50-million-unit irreversible treasury movement probably deserves more than a boolean from Redis.

Architecture is allowed to discriminate by consequence.

A practical adoption path

A platform does not need to convert everything at once.

The highest-value boundaries are usually:

external withdrawal authorization
settlement finality
treasury liquidity
manual overrides
guarantee capacity
high-value custody operations

These are points where incorrect state becomes real external loss.

Start there.

Replace bare assertions with explicit claims.

Then progressively bind:

evidence
policy
state version
validity
issuer

The architecture can become stronger incrementally.

What proof-carrying state does not solve

It does not eliminate bad data.

It does not eliminate dishonest providers.

It does not eliminate policy bugs.

It does not eliminate reversals.

It does not create liquidity.

It does not make an external banking system deterministic.

What it does is prevent economic authority from becoming detached from the assumptions that justified it.

That is already a substantial improvement.

Conclusion

Distributed financial systems make economically significant assertions continuously.

Funds are available.

Settlement is complete.

Liquidity is sufficient.

The customer may withdraw.

The guarantee can absorb the loss.

The transaction satisfies policy.

Most systems transport these conclusions as fields, statuses, and booleans.

Their justification disappears at the service boundary.

Proof-carrying financial state preserves that justification.

Evidence supports claims.

Policies transform evidence into conclusions.

Claims carry scope, validity, provenance, and state context.

Capabilities transform claims into bounded authority.

Execution consumes that authority atomically.

The architecture does not require every service to understand every upstream system.

It requires every economically significant action to be traceable to a claim whose proof is appropriate for the consequence being authorized.

That gives us a stronger invariant:

No irreversible economic action
may occur merely because some upstream service
said "true".

The action must be backed by an explicit chain of authority:

evidence
    ->
claim
        ->
policy
            ->
capability
                ->
state transition

A ledger tells us what the system recorded.

Decision provenance tells us why it acted.

Epistemic capacity tells us how much uncertainty it can afford.

Proof-carrying state tells us why any particular economic permission deserves to exist at all.