DEV Community

Cover image for Proof-Carrying Financial State: Making Economic Permissions Verifiable
Mayckon Giovani
Mayckon Giovani

Posted on

Proof-Carrying Financial State: Making Economic Permissions Verifiable

#distributedsystems #fintech #security #systemdesign

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
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

That proves something useful.

It does not prove:

transaction_settled = true
Enter fullscreen mode Exit fullscreen mode

Likewise:

blockchain_inclusion = confirmed
Enter fullscreen mode Exit fullscreen mode

does not necessarily prove:

customer_funds_unconditionally_withdrawable = true
Enter fullscreen mode Exit fullscreen mode

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

A proof-carrying model therefore scopes claims precisely.

Instead of:

transaction_ok
Enter fullscreen mode Exit fullscreen mode

use claims such as:

signature_authorized
transaction_submitted
transaction_included
settlement_operationally_final
settlement_reconciled
funds_internally_transferable
funds_externally_withdrawable
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For example:

bank settlement observed
    ->
settlement_authoritative
    ->
external_withdrawal_allowed
Enter fullscreen mode Exit fullscreen mode

But another operation may require less:

processor accepted
    ->
settlement_operational
    ->
balance_display_allowed
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Now the permission boundary is explicit.

A developer adding a new withdrawal path cannot merely check:

balance > amount
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This is much more precise than:

available_balance = 100000
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A withdrawal service requiring authoritative backing can immediately derive:

max_withdrawable = 80000
Enter fullscreen mode Exit fullscreen mode

A treasury system requiring reconciliation-grade evidence sees:

deployable_liquidity = 60000
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

But if independent calculations produce:

observed = 100
authoritative = 90
reconciled = 110
Enter fullscreen mode Exit fullscreen mode

the projection is inconsistent.

If proof classes are hierarchical, an invariant should hold:

reconciled
<= authoritative
<= corroborated
<= observed
<= ledger_balance
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Each evidence object contains:

source
claim
subject
source_time
observed_at
coverage
authority
integrity metadata
Enter fullscreen mode Exit fullscreen mode

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,
            ...
        )
    )
Enter fullscreen mode Exit fullscreen mode

The claim then contains:

evidence_set_digest
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The system concludes:

operationally_final
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

not evidence alone.

This is why:

policy_version = v12
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

Then:

Claim =
    Evaluate(
        evidence_set,
        policy_digest
    )
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Conceptually:

DecisionContext:
    policy_digest
    evidence_set_digest
    ledger_version
    liquidity_snapshot
    risk_snapshot
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Or they need to bind to a specific state version:

valid_while:
    liquidity_version == 881
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Others are effectively historical facts:

signature_created
ledger_entry_committed
transaction_included_at_block_881
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The consumer verifies:

current_ledger_version == 88192
Enter fullscreen mode Exit fullscreen mode

before execution.

If not:

claim invalid for execution
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

It simultaneously creates:

WithdrawalCapacityReservation:
    amount: 500k
    account: acct_8821
    expires_at: 14:00:30
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A capability says:

you are authorized to exercise this specific permission
Enter fullscreen mode Exit fullscreen mode

For example:

proof:
    account has >= 500k authoritative funds

capability:
    withdrawal service may consume 500k
    before 14:00:30
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

It may be digitally signed:

signature = Sign(
    issuer_key,
    canonical_capability
)
Enter fullscreen mode Exit fullscreen mode

Now a downstream service can verify:

issuer authenticity
integrity
expiration
scope
Enter fullscreen mode Exit fullscreen mode

without trusting arbitrary caller-provided flags.

Capabilities must be single-use where necessary

Suppose the capability authorizes:

withdraw 500k
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The authoritative state transition must ensure:

capability consumed <= authorized amount
Enter fullscreen mode Exit fullscreen mode

Partial consumption

A 500k capability may permit:

withdraw up to 500k
Enter fullscreen mode Exit fullscreen mode

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

Possible semantics:

capability fully consumed
Enter fullscreen mode Exit fullscreen mode

or:

remaining authority = 300k
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

No single subsystem owns all these facts.

The final authorization is a composition:

WithdrawalAuthorized =
    FundsProof
    AND IdentityProof
    AND ComplianceProof
    AND LiquidityProof
    AND CustodyPolicyProof
Enter fullscreen mode Exit fullscreen mode

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: ...
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The capability state becomes:

revoked
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The result is a claim graph.

For example:

bank_entry_441
    -> settlement_claim_882
        -> availability_claim_991
            -> withdrawal_capability_112
Enter fullscreen mode Exit fullscreen mode

This graph answers:

Which permissions depended on this evidence?
Enter fullscreen mode Exit fullscreen mode

That is a very powerful incident-response primitive.

Invalidating descendants

Suppose:

settlement_claim_882
Enter fullscreen mode Exit fullscreen mode

is invalidated.

The system can identify descendants:

availability_claim_991
withdrawal_capability_112
Enter fullscreen mode Exit fullscreen mode

If the capability has not been exercised:

revoke it
Enter fullscreen mode Exit fullscreen mode

If it has already been exercised:

create compensation obligation
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

and then:

upstream settlement reversed
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Downstream services no longer ask:

is settled?
Enter fullscreen mode Exit fullscreen mode

They ask:

is this settlement proof sufficient
for the action I want to perform?
Enter fullscreen mode Exit fullscreen mode

That is a much safer API.

Proof-carrying liquidity

Liquidity is another obvious candidate.

Instead of:

available_liquidity = 20M
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Liquidity proof must account for existing reservations

If:

liquidity = 20M
Enter fullscreen mode Exit fullscreen mode

but:

already committed outflows = 15M
Enter fullscreen mode Exit fullscreen mode

the usable liquidity is not 20M.

Therefore:

LiquidityClaim
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Proof-carrying compliance decisions

Compliance systems frequently return:

allowed = true
Enter fullscreen mode Exit fullscreen mode

That is another dangerous boolean.

A stronger claim might include:

ComplianceClaim:
    subject
    action
    jurisdiction
    policy_digest
    evidence_refs
    decision
    issued_at
    expires_at
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

A badly designed system may treat this as:

customer_compliant = true
Enter fullscreen mode Exit fullscreen mode

and later allow external withdrawal.

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

claim.action = internal_transfer
Enter fullscreen mode Exit fullscreen mode

does not satisfy:

required.action = external_withdrawal
Enter fullscreen mode Exit fullscreen mode

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
    )
Enter fullscreen mode Exit fullscreen mode

Consumers verify:

Verify(
    issuer_public_key,
    canonical_claim,
    signature
)
Enter fullscreen mode Exit fullscreen mode

This protects against mutation and unauthorized claim creation.

But again:

signature_valid
Enter fullscreen mode Exit fullscreen mode

means:

authorized issuer produced this claim
Enter fullscreen mode Exit fullscreen mode

It does not mean:

claim corresponds to reality
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

Trust configuration becomes security-critical infrastructure.

If every service can issue:

withdrawable = true
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Key rotation must preserve verification of historical claims.

That suggests:

issuer_id
key_id
issued_at
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Subsequent claims depend on:

checkpoint + delta evidence
Enter fullscreen mode Exit fullscreen mode

instead of the entire history.

Merkle commitments

Evidence sets can be committed using a Merkle tree.

For example:

evidence_root = MerkleRoot(evidence_records)
Enter fullscreen mode Exit fullscreen mode

The claim stores:

evidence_root
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

Second:

Every claim
must reference sufficient evidence
and an identifiable policy.
Enter fullscreen mode Exit fullscreen mode

Third:

Every capability
must be scoped to a specific action.
Enter fullscreen mode Exit fullscreen mode

Fourth:

No capability may authorize
more economic value
than the capacity reserved for it.
Enter fullscreen mode Exit fullscreen mode

Fifth:

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

Sixth:

Revocation must preserve historical provenance.
Enter fullscreen mode Exit fullscreen mode

Seventh:

Every irreversible action
must be attributable to the proof context
that authorized it.
Enter fullscreen mode Exit fullscreen mode

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,
}
Enter fullscreen mode Exit fullscreen mode

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,
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Only then does external settlement begin.

That sounds heavier than:

if balance >= amount
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Transaction B:

amount = 5M
Enter fullscreen mode Exit fullscreen mode

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"
}
Enter fullscreen mode Exit fullscreen mode

a service returns:

{
  "claim_id": "claim_882",
  "claim": "settlement_final",
  "proof_class": "authoritative",
  "valid_until": "...",
  "state_version": 8841
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This prevents architectural authority from leaking through convenient APIs.

Multi-party authorization

Some claims may require several authorities.

For example:

high-value withdrawal
Enter fullscreen mode Exit fullscreen mode

could require:

availability claim
AND compliance claim
AND custody authorization
AND treasury liquidity claim
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Execution requires:

valid_signatures >= threshold
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

where:

c is a capability and s is current system state.

A safety property might be:

ExecuteWithdrawal(c, s)
implies
ValidCapability(c, s)
Enter fullscreen mode Exit fullscreen mode

Then:

ValidCapability(c, s)
implies
SufficientFunds(c, s)
AND
SufficientProof(c)
AND
Unconsumed(c)
AND
AuthorizedIssuer(c)
AND
WithinValidityWindow(c)
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

For multiple capabilities over the same resource:

sum(Reserved(c_i))
<=
AvailableCapacity
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

After execution, another claim may be produced:

transaction_submitted
Enter fullscreen mode Exit fullscreen mode

then:

transaction_included
Enter fullscreen mode Exit fullscreen mode

then:

settlement_final
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

Then:

Which were exercised?
Enter fullscreen mode Exit fullscreen mode

Then:

Which downstream settlements became irreversible?
Enter fullscreen mode Exit fullscreen mode

Then:

Which compensation obligations must now exist?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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".
Enter fullscreen mode Exit fullscreen mode

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

evidence
    ->
claim
        ->
policy
            ->
capability
                ->
state transition
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)