Technical dossiers
Long-form and dated. Each dossier states what is established, what is in development and what is not claimed, and draws the mechanism so that it can be followed rather than believed.
Protocol
Updated 2026-09-07 · 11 min read · Edition preview-01
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-07 · 13 min read · Edition preview-01
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-09-07 · 14 min read · Edition preview-01
FxCore
The admissibility kernel - judging a claim before it can become power
FxCore is the constitutional kernel. It applies the native laws, the account's own constitution and the catalogue of refused powers to a claim before that claim can reach execution, and it answers with an admitted cell candidate or a sealed denial that explains itself. Today an offline admission oracle emits a three-verdict grammar and the local line explicitly admits no transaction; the direction freezes an ordered ladder of ten verdicts that every node evaluates byte-identically.
Read the dossierUpdated 2026-09-07 · 12 min read · Edition preview-01
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-07 · 13 min read · Edition preview-01
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-09-07 · 15 min read · Edition preview-01
FxVM
The execution machine - executing deterministically, with observed receipts
FxVM runs admitted cells under their declared access, observes what actually happened and emits receipts for verification. Today it is a deterministic receipt harness that validates a block against its cells and emits one receipt per cell without executing bytecode or touching state; the direction makes it a machine of explicit effects - declared, observed, committed - whose parallelism never implies a nondeterministic commit, and which verifies what it can rather than computing it.
Read the dossierUpdated 2026-09-07 · 14 min read · Edition preview-01
FxState
The commitment layer - committing transitions as evidence, not authority
FxState accepts only the transitions the previous organs have backed with receipts, and preserves enough evidence for replay and audit. Today it is a deterministic in-memory commitment that derives a typed state root from a block and its receipts, with no database, no witnesses and no persistence beyond one anchored genesis snapshot; the direction inverts the ontology - state is a projection over sealed evidence, not a substance that is mutated - and separates hot state, journal, checkpoint, archive and cold resurrection into distinct contracts.
Read the dossierUpdated 2026-09-07 · 15 min read · Edition preview-01
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 dossierEngineering discipline
Updated 2026-09-07 · 17 min read · Edition preview-02
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 FxChain Mission Control 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-07 · 13 min read · Edition preview-01
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-07 · 15 min read · Edition preview-01
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 dossierDirection
Updated 2026-09-07 · 15 min read · Edition preview-01
Three planes and one small kernel
The target architecture of the FxChain Architecture & Protocol Programme, 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-09-07 · 9 min read · Edition preview-01
Receipts, denials and capsules
The evidence objects - what the protocol produces instead of a status flag
Where most systems return a status, 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-07 · 13 min read · Edition preview-01
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-09-07 · 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-07 · 11 min read · Edition preview-01
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-09-07 · 9 min read · Edition preview-01
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 today is a deterministic local kernel - it processes, seals and reconstructs, and it listens to nobody. The architecture programme defines the path from that kernel to a living node - a bounded socket, a signed intent, a transition, a receipt, a query - and beyond it a durable node, a consensus simulator, private and hostile devnets, and only then testnet and mainnet candidates, each a gate the line has not claimed. It also does something rarer - it makes the sovereign network itself a question for a tribunal, with simpler outcomes that must be allowed to win.
Read the dossierUpdated 2026-09-07 · 13 min read · Edition preview-01
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.