Who can authorise an action?
Start with the user-facing claim, then examine the authority boundary and its admission.
Resources · Dossiers
Technical dossiers
Choose an operational question, then follow the mechanism and its limits. Dossiers are dated technical accounts; their historical implementation scope is read alongside the current evidence index.
Dated scope and limitsMechanisms explainedInternal records, not an external audit
Start with a problem
Four reading paths
Choose the question you need to answer. Each path links the existing dossiers in a useful order.
What happened when the outcome is uncertain?
Separate observations, refusals and external claims before deciding whether a workflow can continue.
How can preserved history be checked?
Follow reconstruction, its storage boundaries and the checks that can reject a result.
What would justify deployment?
Read maturity, acceptance and deployment as distinct decisions with their own gates.
An edition describes the implementation and sources examined on its date. Statements about the foundational local harness do not define the scope of every later native profile. For current implementation, availability and evidence access, read what exists today.
01 · Series
Protocol
Updated 2026-09-21 · 12 min read · Edition preview-02
FxWire
The input boundary - receiving messages without granting them authority
FxWire is where the outside world meets the protocol. Doctrine gives it transport, packet validation, anti-spam, peer scoring, intent decoding and routing; today it is one deterministic thing - an offline decoder that turns canonical intent bytes into a bounded input for FxCore, with no sockets, no peers and no daemon. Its law is that it transports bytes and grants them no authority.
Read the dossierUpdated 2026-09-21 · 14 min read · Edition preview-02
FxIntent
Declared meaning - a transaction is a claim, not an order
FxIntent is the user-facing envelope of FxChain. Instead of sending raw code or an opaque call, a participant declares what is being asked, under which constraints, with which effects and until when - before any power to execute exists. Today an intent is sealed locally from a canonical body under a domain-separated hash; the direction generalises it into one claim family with a closed algebra of effects.
Read the dossierUpdated 2026-10-13 · 16 min read · Edition preview-03
FxCore
The admissibility kernel - judging a claim before it can become power
FxCore is designed to judge admissibility under native laws, account constitutions and refused powers. Its foundational offline oracle emits a three-verdict grammar and admits no transaction in that harness. Additional native workflows have their own qualified admission scope. The general runtime-kernel direction defines deterministic verdicts rather than presuming a public deployment.
Read the dossierUpdated 2026-09-21 · 13 min read · Edition preview-02
FxCell
The causal unit - giving an admitted claim a body, a context and a verifiable path
FxCell is the internal unit that carries an admitted claim through ordering and execution. It binds the claim's meaning, its dependencies and its declared access into one compact, sealed object. Today a cell is sealed under its own hash domain with dependencies deliberately left empty; the direction makes it the universal economic atom of the protocol, with declared access, declared effects and causal parents that FxDAG can order and FxVM can execute without surprises.
Read the dossierUpdated 2026-09-21 · 14 min read · Edition preview-02
FxDAG
The ordering carrier - ordering causality without pretending conflicts disappeared
FxDAG decides which cells can run together, which must wait, and which conflicts must be surfaced rather than hidden by sequencing. Today it is a deterministic local ordering with byte-level tie-breaking and no consensus at all; the direction makes it a causal transition graph in which independent cells commute, contested cells clear uniformly within a window, and position inside the window is worth nothing.
Read the dossierUpdated 2026-10-13 · 16 min read · Edition preview-03
FxVM
The execution machine - executing deterministically, with observed receipts
FxVM is designed to run admitted cells under their declared access and emit observed receipts. Its foundational implementation is a deterministic receipt harness without bytecode execution or state mutation. The additional native profiles include a separately qualified numerical application, without establishing a general virtual machine. The wider direction remains a machine of explicit effects and deterministic commitment.
Read the dossierUpdated 2026-10-13 · 15 min read · Edition preview-03
FxState
The commitment layer - committing transitions as evidence, not authority
FxState is designed to commit transitions backed by receipts and preserve their evidence. The foundational organ derives an in-memory state root; its historical preservation scope is one anchored genesis snapshot. Additional native workflow continuity is qualified separately, without establishing a general storage engine. The wider direction treats state as a projection over sealed evidence and separates preservation powers into distinct contracts.
Read the dossierUpdated 2026-09-21 · 16 min read · Edition preview-02
FxBlock
The sealed capsule - sealing results and refusals together
FxBlock is the last organ and the artifact the world verifies. Today a block is sealed under its own hash domain from a typed height and an ordered list of cells, assembled locally in the exact order FxDAG produced, with no consensus and no finality; the direction makes it a capsule that commits results, receipts and denial roots together, so that a third party can verify not only what the network did but what it provably could not do.
Read the dossier02 · Series
Engineering discipline
Updated 2026-09-28 · 17 min read · Edition preview-03
The acceptance discipline
How a change earns its place on the sealed development line
FxChain does not merge a change because its tests are green. A candidate is frozen, reproduced, attacked and adjudicated by separate roles before it is sealed - and a refusal is recorded as carefully as an acceptance.
Read the dossierUpdated 2026-09-07 · 18 min read · Edition preview-01
The evidence lab
How Mission Control (MC) runs a review that can be checked afterwards
A review is only worth what can be verified about it later. Mission Control runs reviews in rooms whose isolation is measured, records them with a chain that cannot be rewritten, and admits their evidence by rule - so that a green verdict can be refused when its evidence is unsound.
Read the dossierUpdated 2026-09-21 · 13 min read · Edition preview-02
Sealed history
How the line advances - named crossings, frozen bytes, and meaning that moves only through new artifacts
FxChain has no changelog in the usual sense; it has a sealed history. The line advances only by named crossings, each with a predecessor, an objective, a list of the powers it does not grant and an acceptance record; a later era may move meaning through a new artifact but never rewrites the bytes of a sealed earlier one. This dossier explains the constitutional rule, the seven eras and the powers each admitted and still denies, the census of crossings, the source hierarchy used in disputes, and the closing act that corrected its own witness before sealing the reconstruction family.
Read the dossierUpdated 2026-09-21 · 15 min read · Edition preview-02
The replay domain
Independent reconstruction as a sealed family - a boundary that reconstructs nothing, then an oracle, an engine, a tribunal and a read-only door
Reconstruction - rebuilding a preserved history and checking that it was rebuilt correctly - is not a feature in FxChain but a domain with its own sealed family of crossings. It began by naming a boundary that could not be used, defined a grammar for history units and a reference transition, then earned two independent implementations that are forbidden from linking each other, a tribunal that compares them and decides nothing, and a read-only door through which a node may ask. This dossier follows the chain and states what it proves and what it refuses to claim.
Read the dossier03 · Series
Direction
Updated 2026-09-07 · 15 min read · Edition preview-01
Three planes and one small kernel
The target architecture of the Architecture & Protocol Programme (APP), at the level of its laws
The architecture programme separates a runtime plane, a change plane and an assurance plane over a deliberately small shared kernel, forbids any implicit transfer of authority between them, keeps two kinds of evidence apart, and classifies every object on three independent axes. This dossier states those laws and the shape of the objects - not their fields.
Read the dossierUpdated 2026-10-25 · 10 min read · Edition preview-02
Receipts, denials and capsules
The evidence objects - what the protocol produces instead of a status flag
Instead of a status flag, FxChain is designed to produce evidence objects - receipts for what execution observed, denials for what it refused and why, abort receipts for what execution touched without declaring, and capsules that seal all of them under one certificate. Today receipts exist on the local line, one per cell, sealed under their own domain, and refusals are explicit typed boundaries at every organ; sealed denial receipts, chained denial roots, abort receipts and capsules are design. This dossier defines each object, what it is meant to prove, and what it is meant never to compress.
Read the dossierUpdated 2026-09-21 · 13 min read · Edition preview-02
The storage constitution
Truth precedes storage - the ratified law under which any engine may one day hold canonical state
Before FxChain chooses how canonical state will be stored, it wrote the law that any storage engine must obey. The Founder-ratified storage constitution of July 2026 rejected an engine-first path, restored the order law, grammar, oracle, families, gates, portability, escape, evidence, crossing and only then an engine, and fixed three rings, six planes and nine permanent covenants - the first of which is that truth precedes storage. It selects no engine and authorises no implementation. This dossier explains what it binds, what it presumes, how a candidate would be tried, and what it refuses to authorise.
Read the dossierUpdated 2026-10-25 · 10 min read · Edition preview-01
Six axes, never one status
The status grammar - why "done" is not a word the architecture allows itself
Every statement about FxChain is meant to be classified on six separate axes - how far it is implemented, where it is deployed, what its governance state is, what kind of truth it is, what is known about it, and how strongly it has been assured - and the architecture programme forbids compressing them into a single status. This dossier explains the six axes, the illegal combinations the grammar makes machine-detectable, why the portal's own five-word vocabulary is a deliberate projection of that grammar, and what the discipline costs.
Read the dossierUpdated 2026-09-21 · 12 min read · Edition preview-02
The authority algebra
Capability is the only authority - and authority can only ever get smaller
FxChain has no roles. Its direction defines authority as a typed set of effects a holder may still cause, issued with provenance and expiry, spent by use, and composable only by narrowing - never widened by a risk score, a status or an emergency. On the local line the first two forms of this already exist as sealed acts - a named, counted authority exhausted inside its crossing, and offline motion keys spent once and recorded. This dossier sets out the algebra, the separation of permanent power from temporary eligibility, the rule that a risk claim may constrain exercise but never expand a grant, and the duty that every change of power must carry.
Read the dossierUpdated 2026-10-13 · 9 min read · Edition preview-02
The living node
From a local deterministic kernel to a node that answers - and why a sovereign network is a disposition, not a presumption
FxChain has a deterministic local kernel and additional qualified native workflow profiles; no public network is active. The architecture programme defines the path from those local foundations to a living node, a durable node, a consensus simulator, private and hostile devnets, and only then testnet and mainnet candidates. Each deployment has its own gate. The sovereign network remains a disposition to establish, with simpler outcomes that must be allowed to win.
Read the dossierUpdated 2026-09-21 · 13 min read · Edition preview-02
The evidence algebra and contradiction escrow
Judging instead of computing, tiers of evidence, and how to keep working under contradiction without lying
FxChain's third law is that the protocol never computes what it can verify - a call is a claimed delta plus evidence, judged into a verdict. This dossier sets out the algebra behind that law - evidence tiers with deterministic replay as the floor, external receipts that never become canonical alone, a bounded evidence budget - and its most distinctive corollary - contradiction is escrowed rather than hidden. Unresolved conflicts are isolated with their blast radius made explicit, broken plan assumptions become amendment proposals rather than silent rewrites, and every incident must yield either a new invariant or a signed statement that no law could be extracted.
Read the dossierUpdated 2026-09-07 · 11 min read · Edition preview-01
Privacy by disclosure class
What is revealed, to whom, under which effect - and why a refusal must not leak the claim it refused
FxChain's direction treats privacy not as a feature bolted onto a transparent ledger but as an effect class declared by every claim - reveal, commit, prove or shield - from which a disclosure profile follows deterministically. Denials are public by reason class and private in detail; a sealed claim must not be reconstructable from its own refusal; heavy privacy computation is asynchronous and never blocks finality; compliance is expressed as claims and disclosure classes without placing legal judgement inside consensus. None of it runs today. This dossier states the doctrine, what the portal itself practises, and what is not claimed.
Read the dossierAsk for a dossier
Tell us which mechanism deserves this treatment next. An enquiry does not grant a licence, a production endpoint or a delivery date.