FxChain Foundations
The native FxChain protocol foundations: bounded local processing, preserved history and reconstruction through separate paths, with their evidence and limits.
Explicit authority. Bounded effects. Inspectable results.
Flowesome builds applications and integration tools; FxChain is their native blockchain foundation. Its target protocol connects the authority to act, the consequences an action may cause and the evidence retained when it succeeds, is refused or remains unresolved.
Before an action, ask which mandate covers its recipient, amount, asset, fees and duration. During execution, distinguish what was requested from what was observed. After an interruption, retain the obligations and evidence needed to justify the next action. A missing response stays unknown until evidence resolves it.
Defined local profiles already exercise parts of this direction; their evidence does not establish the complete target architecture or a public network. Middleware integration, hybrid operation and a future native network are deployment paths with separate requirements.
Native capabilities extend the local work.
Implemented locallyUseful execution now has a reading page of its own.
The existing Foundations reading path remains intact: overview, reconstruction chapter, evidence and limits, then the comparison guide. Those pages preserve their own bounded reconstruction subject; the native profiles do not silently expand its receipt.
What has been built
A reading guide to implemented local reconstruction: its responsibilities, the evidence behind it and the limits of that evidence.
Reconstruction through separate paths
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.
One preserved history
Explicit starting boundary and bounded scope
Oracle path
An observation derived within the declared scope
Engine path
A separate observation of the same preserved history
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.
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
50/50
conformance checks
deterministic runs
Why a stored result is not an explanation
Three ways a preserved result can look complete and still explain nothing.
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.
Repeating the same code repeats the same mistake
Repeating one implementation under the same conditions can repeat a defect. A separate implementation offers another comparison path; varied inputs and external review provide other checks.
A digest identifies bytes, not correctness
Matching a trusted expected digest identifies the examined bytes. It does not establish their origin, freshness, completeness or the correctness of the process that produced them.
One history, two paths, an explicit comparison
Reconstruction lets a second implementation account for a stored result under explicit inputs, rules and reference commitments. Shared assumptions remain part of the evidence scope.
- 1
Preserve
A bounded history is kept with an explicit starting boundary.
- 2
Declare
The scope, the assumptions and the rules each path will apply are stated first.
- 3
Reconstruct
Separate oracle and engine implementations derive their own observations within declared rules and inputs.
- 4
Compare
The observations are confronted. Neither path is authoritative by default.
- 5
Report
Agreement, disagreement or refusal is recorded as what it is, never as a verdict.
What is real, stated plainly
Proven today
- Bounded reconstruction of a preserved history, implemented locally
- Separate reconstruction implementations: 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
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 dossierFxIntent
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 dossierFxCore
Admissibility
Judges admissibility before power.
Refuses: Unauthorized authority, invalid account powers, missing evidence and claims outside the current protocol constitution.
Read the dossierFxCell
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 dossierFxDAG
Ordering responsibility
Orders causality without pretending conflicts disappeared.
Refuses: Silent reordering, extraction-prone ambiguity and conflicts buried as mere timing accidents.
Read the dossierFxVM
Execution responsibility
Executes deterministically with observed receipts.
Refuses: Nondeterministic behavior, undeclared access and runtime authority not earned by the previous gates.
Read the dossierFxState
State commitments
Commits transitions as evidence, not authority.
Refuses: Authority without receipts, state changes without replay material and undocumented exceptions.
Read the dossierFxBlock
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 dossierFive questions this section answers
The order in which an evaluator can read the foundations, and where each answer lives.
- 1What has been built
What works today?
Bounded local reconstruction through separate implementations, with an explicit comparison and declared shared assumptions.
- 2Reconstruction chapter
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.
- 3Evidence & limits
What evidence can be examined?
A public scope note describing the subject, the method and the supported conclusion of an internal review.
- 4What the evidence does not establish
What does that evidence not establish?
No network, no finality, no throughput, no external audit and no certification of the latest branch.
- 5Discuss an evaluation
What can you actually request?
A bounded technical discussion. Not a licence, a production endpoint or a delivery date.
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.
Engineering discipline
Direction
Reference
Technical evaluation
Bring one preserved result, the rules that should explain it and a failure case. Compare what each path can establish and which observations remain unresolved.