How FxChain turns claims into power
FxChain is a constitutional machine: a claim enters powerless, earns admissibility, executes deterministically and is sealed with evidence. The important part is not speed first - it is knowing exactly when power is allowed to exist.
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 seals both results and refusals. Select an organ to read what it takes in, decides, produces and refuses.
One transaction, end to end
- ClaimFxWire
- IntentFxIntent
- AdmissibilityFxCore
- Cell and orderFxCell · FxDAG
- ExecutionFxVM
- Receipt or denialFxVM · FxState
- CapsuleFxBlock
A payment, for instance: the message becomes a declared intent, is admitted or refused, becomes a cell ordered in its window, executes with a receipt, and is sealed - together with the refusals of that window - into the capsule. Each organ below is one share of that path.
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.
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.
The eight organs at a glance
One row per organ, in the order a claim meets them: what each one promises and what it refuses. Select a row to open it in the sequence above.
| # | Organ | Promise | Refuses |
|---|---|---|---|
| 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. | |
| 2 | Declares meaning before execution. | Open-ended power, missing constraints, expired instructions and claims whose meaning cannot be audited before execution. | |
| 3 | Judges admissibility before power. | Unauthorized authority, invalid account powers, missing evidence and claims outside the current protocol constitution. | |
| 4 | Packages a claim as a causal execution unit. | Hidden dependencies and claims that cannot declare enough structure to be ordered safely. | |
| 5 | Orders causality without pretending conflicts disappeared. | Silent reordering, extraction-prone ambiguity and conflicts buried as mere timing accidents. | |
| 6 | Executes deterministically with observed receipts. | Nondeterministic behavior, undeclared access and runtime authority not earned by the previous gates. | |
| 7 | Commits transitions as evidence, not authority. | Authority without receipts, state changes without replay material and undocumented exceptions. | |
| 8 | Seals results and refusals together. | History that hides rejected claims, incomplete proof material and blocks that cannot explain their own boundaries. |
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.
- 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.
- 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.
- Receipt
- What execution actually observed: the material needed to re-derive a result rather than take it on trust.
- Denial
- A refusal sealed as an artifact 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.
- 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 concrete strength an institution can lean on.
ISO 20022 rail vocabulary
Bank-rail events are modeled as claims the protocol can judge - with health receipts and a proven fallback, never a legal fiction.
Provable refusals
A denial is a sealed artifact with its own root - refusal can be indexed and audited exactly like acceptance, not lost in a silent revert.
Deterministic and replayable
Every result carries the receipts to re-derive it, and deterministic conformance runs gate every single change.
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
Windows are order-invariant and conflicts are explicit economic objects, so sequencing cannot quietly become an advantage.
Evidence-tiered execution
Claims are judged against evidence tiers, and full replay stays the completeness floor 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.
| A classic smart-contract stack | FxChain | |
|---|---|---|
| Execution | Smart contracts usually receive a call and execute code. | FxChain receives a claim, gives it meaning, then decides whether it may ever become power. |
| Failure | Failure is often a revert, an event or an application-side convention. | Denial is a protocol artifact: refusal can be sealed, indexed and audited. |
| Ordering | Ordering is often treated as a race for inclusion. | Ordering is a constitutional surface: commutation, conflicts and windows are explicit. |
A capsule seals more than a result
A classic block tells you what was accepted. 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.