How a declared action becomes an inspectable result
FxChain is a native blockchain protocol designed to check authority before execution, bound declared effects and retain evidence of the result. The component map explains those target responsibilities; local profiles establish a narrower scope.
Native execution is now concrete in defined profiles.
Implemented locallyServices, numerical work and common activation share a native path.
Recovery and reconstruction are qualified for the applicable native owners and the interruptions exercised. That scope does not establish a general virtual machine, global FxState persistence or distributed finality. The organ anatomy below retains the design and sealed-foundations scope of its own dossiers.
From message to sealed capsule
Each organ narrows ambiguity: transport becomes intent, intent becomes an admissible cell, cells are ordered, execution is observed, state is committed, and the final capsule is designed to seal both results and refusals. Select an organ to read what it takes in, decides, produces and refuses.
Target path of a declared action
- ClaimFxWire
- IntentFxIntent
- AdmissibilityFxCore
- Cell and orderFxCell · FxDAG
- ExecutionFxVM
- Receipt or denialFxVM · FxState
- CapsuleFxBlock
For a native transfer in the design, an FxIntent declares the intended movement and its constraints. FxCore normalizes it into an FxCell; FxDAG orders it; FxVM executes; FxState commits; FxBlock seals the result. This conceptual example does not claim a live transfer, issued asset or financial service.
Step 01 of 08 · Input boundary
FxWire
Receives outside messages without granting them authority.
FxWire is the protocol ingress fabric. It accepts external messages from products, nodes and future developer surfaces, then turns transport into a clean protocol input.
The mail room: it receives every message and lets none of them give orders.
First organ a message meets · before FxIntent
Read the FxWire dossier- Input
- Signed messages, product requests, peer traffic and deployment-specific envelopes.
- Decision
- Whether the message is well-formed enough to become an FxIntent candidate.
- Output
- A normalized ingress object ready for intent construction.
- Refuses
- Malformed transport, ambiguous sender context and messages that try to smuggle execution power through the network layer.
- Advantage
- Network plumbing stays beneath constitutional truth. The transport layer can carry claims, but it cannot decide them.
- Sealed foundations scope
- An offline decoder that turns canonical intent bytes into a bounded input for FxCore, with no sockets, no peers and no daemon.
Input, decision, output, refuses and advantage state the design of the organ. The last card reports the sealed-foundations scope of its dossier. The distinct native profiles above carry their own current qualification.
The eight organs at a glance
One row per organ, in the order a claim meets them: its design promise, its refusals and the sealed-foundations scope documented in its dossier. Select a row to open it in the sequence above.
| # | Organ | Promise | Refuses | Sealed foundations scope |
|---|---|---|---|---|
| 1 | Receives outside messages without granting them authority. | Malformed transport, ambiguous sender context and messages that try to smuggle execution power through the network layer. | An offline decoder that turns canonical intent bytes into a bounded input for FxCore, with no sockets, no peers and no daemon. | |
| 2 | Declares meaning before execution. | Open-ended power, missing constraints, expired instructions and claims whose meaning cannot be audited before execution. | An intent is sealed locally from a canonical body under a domain-separated hash. | |
| 3 | Judges admissibility before power. | Unauthorized authority, invalid account powers, missing evidence and claims outside the current protocol constitution. | The foundational admission profile is an offline oracle with three verdicts; it does not admit a transaction. Later native service profiles have separate scope notes. | |
| 4 | Packages a claim as a causal execution unit. | Hidden dependencies and claims that cannot declare enough structure to be ordered safely. | A cell is sealed under its own hash domain, with its dependencies deliberately left empty. | |
| 5 | Orders causality without pretending conflicts disappeared. | Silent reordering, extraction-prone ambiguity and conflicts buried as mere timing accidents. | The foundational profile orders explicit dependencies locally with byte-level tie-breaking. It does not establish distributed consensus. | |
| 6 | Executes deterministically with observed receipts. | Nondeterministic behavior, undeclared access and runtime authority not earned by the previous gates. | A deterministic receipt harness that validates a block against its cells and emits one receipt per cell, without executing bytecode or touching state. | |
| 7 | Commits transitions as evidence, not authority. | Authority without receipts, state changes without replay material and undocumented exceptions. | A deterministic in-memory commitment that derives a typed state root from a block and its receipts, within the foundational in-memory profile. Anchored preservation and later native profiles have their own evidence and do not imply a general database or public state service. | |
| 8 | Seals results and refusals together. | History that hides rejected claims, incomplete proof material and blocks that cannot explain their own boundaries. | A block is sealed under its own hash domain from a typed height and an ordered list of cells, assembled locally in the order FxDAG produced, with no consensus and no finality. |
Eight words the protocol uses precisely
The terms behind the sequence, defined once. They are used the same way on every page of the portal, and a term that exists only in the design says so.
- Claim
- A declared request that asks the protocol to consider an action under constraints, expiry and proofs. It enters powerless and is judged before anything executes.
- Admissibility
- The verdict of the constitutional kernel: whether a claim may proceed under native laws, account constitutions and refused powers. The wider account-constitution kernel is design. The foundational offline oracle emits three verdicts without transaction admission; later native profiles have separate evidence.
- Cell
- The causal unit that carries an admitted claim through ordering and execution, together with its dependencies and declared access.
- Window
- A set of cells that can be ordered together. Cells that commute run in an order-invariant window; conflicts stay explicit instead of being hidden by sequencing. Design; the local line orders cells deterministically from their declared dependencies.
- Receipt
- What execution actually observed: the material needed to re-derive a result rather than take it on trust. One per cell on the local line.
- Denial
- A refusal as a result. On the local line, a typed boundary; in the direction, an artifact sealed with its own root, so that what the protocol would not do can be indexed and audited like what it did.
- Capsule
- The sealed unit of a window: result root, receipt set, denial root and state witness committed together. Design; the local line seals blocks.
- Witness
- Additive evidence attached to sealed history. Later work adds witnesses; it never re-cuts what is sealed.
Every term the portal uses precisely, in one place: the glossary.
Where the discipline becomes an advantage
The sequence above is not academic. Each commitment is a strength an institution could lean on, and each card says how far it has been earned.
ISO 20022 rail vocabulary
Bank-rail events are to be modeled as claims the protocol can judge, with health receipts and a fallback proven before any dependency is accepted - never a legal fiction.
Provable refusals
The direction seals a denial as an artifact with its own root, so that refusal can be indexed and audited exactly like acceptance. The documented local organ profiles already expose typed refusal boundaries.
Deterministic and replayable
Within the examined local profiles, fixed inputs and rules support repeatable results and receipt comparison. Dated conformance runs qualify their recorded source versions.
Post-quantum posture
Cryptographic agility is designed into the plan rather than bolted on after a break - the boundary is named before it is needed.
Extraction-resistant ordering
In the direction, windows are order-invariant and conflicts are explicit economic objects, to make sequencing effects inspectable and testable. Today the local order is deterministic, from declared dependencies.
Evidence-tiered execution
In the direction, claims are judged against evidence tiers. Full replay is already the completeness floor of the local line, and stays beneath every optimization.
Why this is not just another smart-contract stack
The distinction is not cosmetic. FxChain moves authority earlier, where it can be judged before runtime. The comparison is with one exact model, call-and-execute contracts on a public chain that sells block space, not with every ledger; each FxChain column carries its status.
| Call-and-execute contracts on a fee-market chain | FxChain - documented local scope | FxChain - direction (research) | |
|---|---|---|---|
| Execution | A call-and-execute model interprets a submitted program; simulation and access controls may also constrain it. | The sealed foundations decode typed intents and judge them offline. Distinct local native profiles now execute qualified numerical work, services and staged synthetic payments. | A kernel of ten verdicts judges the claim before it may become power, and execution verifies evidence instead of running programs. |
| Failure | A reverting call can expose error data; the persistence and interpretation of that evidence depend on the chain and application. | The documented local organ profiles expose explicit typed refusal boundaries. | A denial sealed as a protocol artifact, with a public reason class, that can be indexed and audited. |
| Ordering | Where block space is sold, ordering is a race for inclusion: priority fees, builders, private order flow. | A deterministic order from declared dependencies, with a byte-level tie-break and typed refusals. | Order-invariant windows and explicit conflict handling aim to reduce sequencing advantages; this remains an architectural objective. |
A capsule seals more than a result
A block of accepted transactions tells you what was accepted, and nothing about what was refused. An FxChain capsule is designed to also preserve why a window was bounded, what execution observed and which claims were refused.
Result root
What changed after admitted execution.
Receipt set
What was observed while execution ran.
Denial root
What the protocol refused and why.
State witness
The replay material needed to audit the transition.
The evidence objects in depth - receipts, denials, abort receipts and capsules: read the dossier.
From anatomy to evidence
This page shows how a claim earns its way through the organs. FxChain Foundations shows what has been built, what the evidence supports and what it does not establish.