Skip to content
FxChain · Technical documentation

FxChain Foundations

The implemented local foundations of FxChain for deterministic processing, verifiable preservation and independent reconstruction - with their evidence and limits made explicit.

Editorial previewScope reviewed 2026-09-06Internal review, not an external auditNot a product release
01 · Purpose

What has been built

A reading guide to implemented local reconstruction: its responsibilities, the evidence behind it and the limits of that evidence.

Independent reconstruction

Implemented locally

Rebuild a bounded history through separate paths, then compare their observations without giving either path authority by default.

Keeping a history, reconstructing its state and comparing observations are distinct responsibilities. A technical evaluation must examine both a result and the conditions under which it was obtained.

This section explains those responsibilities, states what evidence supports them and marks - just as carefully - what that evidence does not establish.

Reconstruction responsibilities
1

One preserved history

Explicit starting boundary and bounded scope

2

Oracle path

An observation derived within the declared scope

2

Engine path

A separate observation of the same preserved history

3

Comparison without automatic authority

Agreement, disagreement or refusal - no default winner

Conceptual responsibility map, not a live execution trace. Agreement does not establish universal correctness.

02 · Development line

Where the foundations sit

The reviewed reconstruction foundations belong to the same sealed development line the rest of the portal reports on. The figures are a dated snapshot, not a live counter.

7

protocol eras sealed

D0-D6

372

capability crossings

sealed development line

48/48

conformance checks

deterministic runs

Development snapshot of the sealed development line at 2026-08-02, verified 2026-09-07. These are dated development figures - not live network statistics, and not a statement about the current continuous-integration status.
03 · The problem

Why a stored result is not an explanation

Three ways a preserved result can look complete and still explain nothing.

01

Reading back is not accounting for

A stored result confirms what was written. It does not show that the sequence behind it is complete, that the same rules were applied, or that an independent path would reach the same state.

02

Repeating the same code repeats the same mistake

Running one implementation twice reproduces its assumptions, its input defects and its misread rules. Only a separate path can disagree.

03

A digest identifies bytes, not correctness

A hash proves that material is unchanged. It does not prove that a process ran correctly, nor that the material was sufficient to begin with.

04 · The approach

One history, two paths, an explicit comparison

Reconstruction turns a stored result into something that can be examined without trusting its producer.

  1. 1

    Preserve

    A bounded history is kept with an explicit starting boundary.

  2. 2

    Declare

    The scope, the assumptions and the rules each path will apply are stated first.

  3. 3

    Reconstruct

    Two independent paths - oracle and engine - each derive their own observation.

  4. 4

    Compare

    The observations are confronted. Neither path is authoritative by default.

  5. 5

    Report

    Agreement, disagreement or refusal is recorded as what it is, never as a verdict.

Claim scope

What is real, stated plainly

Proven today

  • Bounded reconstruction of a preserved history, implemented locally
  • Two independent reconstruction paths: an oracle path and an engine path
  • An explicit comparison that reports agreement, disagreement or refusal
  • Continuity and state-commitment checks on the reconstructed material
  • Internal acceptance and differential review records for the examined scope

In development

  • This public explanation of the foundations
  • Alignment of the public vocabulary with the protocol organs

Later gates

  • A public reproduction package with source and materials
  • An independent external audit of the reviewed scope
  • Re-review against the latest development baseline
  • Any deployment: devnet, then testnet, then mainnet

Not claimed

  • No distributed network and no consensus finality
  • No production throughput and no financial-service availability
  • No regulatory compliance and no licence
  • Agreement between paths is not proof of universal correctness

Proven today, or practised on the lineIn development / qualifiedDirection: planned or researchLater gateNot claimed

05 · Responsibilities

Where reconstruction sits among the protocol organs

A conceptual map of the eight named responsibilities. It is not an execution order, a trace of a running deployment or evidence about any single organ.

FxWire

Input boundary

Receives outside messages without granting them authority.

Refuses: Malformed transport, ambiguous sender context and messages that try to smuggle execution power through the network layer.

Read the dossier

FxIntent

Declared meaning

Declares meaning before execution.

Refuses: Open-ended power, missing constraints, expired instructions and claims whose meaning cannot be audited before execution.

Read the dossier

FxCore

Admissibility

Judges admissibility before power.

Refuses: Unauthorized authority, invalid account powers, missing evidence and claims outside the current protocol constitution.

Read the dossier

FxCell

Causal unit

Packages a claim as a causal execution unit.

Refuses: Hidden dependencies and claims that cannot declare enough structure to be ordered safely.

Read the dossier

FxDAG

Ordering responsibility

Orders causality without pretending conflicts disappeared.

Refuses: Silent reordering, extraction-prone ambiguity and conflicts buried as mere timing accidents.

Read the dossier

FxVM

Execution responsibility

Executes deterministically with observed receipts.

Refuses: Nondeterministic behavior, undeclared access and runtime authority not earned by the previous gates.

Read the dossier

FxState

State commitments

Commits transitions as evidence, not authority.

Refuses: Authority without receipts, state changes without replay material and undocumented exceptions.

Read the dossier

FxBlock

Preserved capsule

Seals results and refusals together.

Refuses: History that hides rejected claims, incomplete proof material and blocks that cannot explain their own boundaries.

Read the dossier
06 · Reading map

Five questions this section answers

The order in which an evaluator can read the foundations, and where each answer lives.

  1. 1

    What works today?

    Bounded local reconstruction of a preserved history, through two independent paths, with an explicit comparison.

    What has been built
  2. 2

    What concrete problem does it address?

    A stored result that cannot account for itself: it can be read back, but not examined without trusting its producer.

    Reconstruction chapter
  3. 3

    What evidence can be examined?

    A public scope note describing the subject, the method and the supported conclusion of an internal review.

    Evidence & limits
  4. 4

    What does that evidence not establish?

    No network, no finality, no throughput, no external audit and no certification of the latest branch.

    What the evidence does not establish
  5. 5

    What can you actually request?

    A bounded technical discussion. Not a licence, a production endpoint or a delivery date.

    Discuss an evaluation
07 · Further reading

The dossiers beyond the organs

Every dossier states what is proven today, what is in development and what is not claimed. The organ dossiers are linked above; these develop the discipline, the direction and the vocabulary.

Technical evaluation

Discuss a bounded subject, its method and its evidence. An enquiry does not grant a licence, a production endpoint or a delivery date.