FxState

Update log

• 7 September 2026 - First edition. Drawn from the state, witness, storage and receipt specifications, the semantic context's implemented scope, the era and power map, the Founder-ratified storage constitution, the architecture programme's chapters on state and on persistence and continuity, and the papers' account of evidence-native state. Object names and lifecycle states are given as the shape of the design; engine choices and parameters are not.

Short answer

FxState is the seventh organ and the one that remembers. Its promise is to commit transitions as evidence, not authority. It accepts only transitions that the organs before it have backed - a cell admitted by FxCore, ordered by FxDAG, executed by FxVM with a receipt - and it commits them in a form that can be replayed and audited. It does not decide; it records what was decided, with the proof trail attached.

Today the organ is a deterministic in-memory commitment. From a block and exactly one receipt per cell listed in it, FxState derives a typed state root; receipts are sorted by the canonical bytes of their cell identities for the root calculation, each must reference the committed block, duplicates are refused, and a block or receipt whose identity does not match its body is refused before commitment. There is no database, no archive, no replay store, no witness, no proof, no state synchronisation and no cold storage. The one thing that persists on the line is bounded by a constitution: exactly one authorised artifact - the genesis snapshot - may be preserved and verified against its frozen anchor, and nothing else may be written.

The direction inverts the ontology of state. The papers call it evidence-native state: the canonical objects are claims, verdicts, receipts and seals; state is a deterministic projection over sealed evidence, never a stored substance that is mutated; a balance is a provable fold; any stored cache is non-authoritative by type. The architecture programme gives the projection its objects - an object-centric state with explicit lifecycles and a typed delta that binds a pre-root to a post-root - and its most important law: no engine-owned representation enters the canonical preimage silently. Hot state, journal, checkpoint, archive and cold resurrection are different powers with different contracts.

What is established, what is in development, what is not claimed

Where FxState sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell -> [5] FxDAG -> [6] FxVM -> [7] FxState -> [8] FxBlock
                                                                                          ^
   after FxVM (receipts of what was observed), before FxBlock (the sealed capsule)

Figure 1 - Step seven of eight. FxState turns receipts into a committed root that FxBlock can seal.

The native semantic: state is a projection, not a substance

Every listed chain stores state as the primary object and derives proofs from it. The refoundation of the papers inverts that ontology, and FxState is the organ that carries the inversion.

The canonical objects are claims, verdicts, receipts and seals. State is a deterministic projection over sealed evidence. A balance is a provable fold over the history of seals; a witness is the natural way to read it; any two nodes must produce byte-identical projections from the same seal history and the same projection rules. Any stored cache is non-authoritative by type.

Canonical truth and projections are different species. The architecture programme states it as a law: dashboards, caches, indexes and analytical stores are reconstructible consumers, never silent sources of consensus truth. The state an application reads is a projection; the state the protocol commits is the fold.

Truth precedes storage. The storage constitution's first permanent covenant reverses the usual order: a storage engine does not define what is true; it is allowed to hold what has already been made true by the organs upstream.

   claims -> verdicts -> receipts -> seals          (canonical objects)
                              |
                              v   deterministic fold, versioned rules
                          state (a projection)
                              |
                              +--> witnesses (the natural read path)
                              +--> caches, indexes, dashboards (non-authoritative by type)

Figure 2 - The inversion. Nothing in the projection is a source; everything in it is derivable from sealed evidence, and provably so.

The consequences the papers draw are structural: stateless verification becomes native rather than a roadmap item; state growth becomes an archival market in which projection servers compete; regulators and auditors read projections with proofs; and the canonical core stays small forever.

What exists today

A root from a block and its receipts. FxState computes a typed state root from a block and exactly one receipt per cell listed in the block. Receipts are sorted by the canonical bytes of their cell identities for the root calculation; each receipt must reference the committed block; duplicate cell identities inside the block are refused. The hardening wave added the boundary the other organs share: a block or a receipt whose identity does not match its body is refused before commitment, and the unchecked constructor cannot bypass it.

   FxBlock (ordered cells)  +  one FxReceipt per cell (each references the block)
        |
        v   refuse: duplicate cell . receipt for another block . identity != hash(body)
        v   sort receipts by canonical cell-identity bytes
   FxStateRoot (typed, deterministic, in memory)
        |
        x   no database . no archive . no witness . no proof . no sync . no cold storage

Figure 3 - The commitment on the local line. Deterministic, typed, and entirely in memory.

What the root proves, and what it does not. The witness draft is unusually explicit for a planning document: the current state root proves deterministic local commitment for explicit inputs. It does not prove availability of historical state, object ownership, execution correctness beyond the harness's invariants, or production finality. Local execution snapshots and their conformance vectors pin the harness's outputs.

One persisted artifact, by constitution. The era map records the sixth era as first bounded persistence: exactly one authorised artifact - the genesis snapshot - may be preserved and verified against its frozen anchor. The powers still denied are listed beside it: a second artifact, reconstruction from the medium, ambient disk authority, startup bootstrap authority. The architecture index confirms the implementation is narrowly scoped, anchored preservation of one sealed artifact, and that the protocol does not yet implement general persistent state, a database-backed hot state, an archive, state synchronisation or general storage authority.

A constitution over storage. The Founder-ratified storage constitution organises the future of persistence into three rings - sovereign, projection, edge - and six planes - commitment, hot state, causal journal, cryo, projection, edge - under permanent covenants. It is the canonical, binding record for anything that later wants to persist. It is doctrine, not an engine.

The direction

Object-centric state and a typed delta

The architecture programme frees the state model from the mental constraint of addresses mapped to storage slots. The candidate universal container is an object with an identity, a type, a schema version, an object version, a lineage, a controlling authority reference, a canonical payload, a content commitment and a lifecycle state. Lifecycles are explicit - created, active, updated, consumed, tombstoned or superseded - and the object type registry declares which mutation class each type allows: some classes are linear resources, others immutable append-only records.

A state delta binds a pre-state root to a post-state root together with the read, create, update and delete sets, the resource deltas and the capabilities consumed. An executor cannot claim a post-root unless the delta is compatible with the declared effect algebra - which ties FxState back to the declarations made at FxIntent and FxCell.

A commitment the protocol owns

The commitment constitution is provider-independent. The physical engine may be integrated with an authenticated tree, or may sit below a protocol-owned commitment layer, but no engine-owned representation enters the canonical preimage silently. FxChain must be able to specify and independently recompute leaves, internal nodes and roots. Two families are kept for a later tournament - an integrated authenticated engine, and a protocol-owned commitment over a replaceable substrate - and the tournament begins with semantics and licence, not with benchmark speed. Before any production engine exists, a deliberately slow, in-memory commitment oracle should exist to provide independent roots, witnesses and absence proofs.

   protocol-owned commitment
   +--------------------------------------------------+
   | leaves, nodes and roots the protocol can          |
   | specify and recompute independently               |
   +---------------------+----------------------------+
                         |   nothing engine-owned enters the preimage silently
                         v
   replaceable storage substrate (engine A | engine B | ...)

Figure 4 - The commitment above the engine. The engine can be replaced; the preimage cannot be changed by it.

Different powers, different contracts

The persistence chapter names the law the D6 lineage discovered: preservation, durable publication, reconstruction, current state and cold resurrection are different powers. The target continuity pipeline runs from journal to segment to publication to checkpoint to head, and then - crash, restart anchor, reconstruction, verified resumed state. A publication is not a boolean: it moves through staged, written, synchronised, published, parent-durable and durably committed states, and it can be conflicted, corrupt or unestablished. A successful write system call is not a durability claim; file content, parent-directory metadata, rename semantics, overwrite refusal and restart observation are each evidenced separately where required.

Hot state is not historical continuity. The hot-state engine, the journal and the archive are separate: immutable history may migrate to segment or static-file storage while current authenticated state uses another engine; projections may use relational or columnar stores without becoming authoritative. FxCryo, a reserved plane, is the cold-resurrection layer: archival packages, manifests, historical commitments, proof material and deterministic restoration, independently verifiable without a live production database. Recovery is judged by outcome, not by reopening a file: crash a real durable node at controlled failure points, restart from persisted material, reconstruct, and obtain the identical canonical root and head - or a typed refusal when the persisted world is inconsistent.

   journal -> segment -> publication -> checkpoint -> head
                                                       |
                                    crash --> restart anchor --> reconstruction
                                                       |
                                    identical root and head, or a typed refusal

Figure 5 - The continuity pipeline. Recovery is a measured outcome; a file that reopens proves nothing by itself.

The refusal that defines it

FxState refuses three things, and each is a refusal to let storage become authority.

• Authority without receipts. A transition that no receipt backs is not a transition; it is an assertion, and the organ commits assertions from no one.
• State changes without replay material. A change that cannot be replayed from the evidence cannot be audited, and so cannot be committed. On the local line the receipts are the material; in the direction the delta and the witnesses are.
• Undocumented exceptions. A special case that is not on the record is not a special case; it is a hole. The storage constitution's covenants and the era map's explicit list of denied powers exist so that every exception is documented before it can exist.

What FxState does not do

• It does not persist. It has no database, archive, replay store, witnesses, proofs, synchronisation or cold storage. One authorised artifact - the genesis snapshot - is preserved, and nothing else.
• It does not decide. It commits what the previous organs decided and backed with receipts.
• Its root does not prove availability of history, ownership of objects, execution correctness beyond the harness, or finality.
• Object-centric state, the typed delta, the protocol-owned commitment, the continuity pipeline, evidence-native projections and FxCryo are design, stated as research, planned or reserved.

Verdict

FxState is the organ where the discipline of the whole sequence is finally written down, and the dossier's honesty is easiest here because the specifications wrote it first: the root proves deterministic local commitment for explicit inputs and nothing more; one artifact persists, under a constitution that lists the powers it does not grant. What is designed is the inversion that makes the small core possible - state as a projection over sealed evidence, a commitment the protocol owns above any engine, and persistence separated into powers that are evidenced one by one. The organ's own advantage line says why it matters: state is not just the result; it carries the proof trail that explains why the result was allowed.

Frequently asked questions

Is there a state database?

No. FxState is an in-memory commitment on the local line. The only persisted artifact is the genesis snapshot, preserved and verified against its frozen anchor under the sixth era's bounds.

What does "state is a projection" mean for a balance?

That a balance is not a stored number but a provable fold over the sealed history of claims, verdicts and receipts. Two nodes with the same seal history and the same projection rules produce the same balance, byte for byte, and can prove it.

Why keep the commitment separate from the storage engine?

So that the engine can be replaced without changing what the protocol committed. If an engine's internal representation could enter the preimage of a root, changing engines would change history. The law forbids it.

What is FxCryo?

A reserved doctrine plane for cold state: archival packages, frozen state, historical commitments and resurrection proofs that can be verified without a live database. It is design direction, not implemented, and the witness draft prepares its vocabulary without adding behaviour.

How is recovery proven?

By outcome. The acceptance target is to crash a durable node at controlled failure points, restart it from persisted material, reconstruct, and obtain the identical canonical root and head - or a typed refusal if the persisted world is inconsistent. Reopening a file proves nothing.

Sources and methodology

Drawn from the state, witness, storage and receipt specifications in the protocol repository, the semantic context's implemented scope, the era and power map, the Founder-ratified storage constitution and the architecture index, the architecture programme's chapters on object-centric state and on persistence, continuity, recovery and cold resurrection, and the papers' account of evidence-native state. Implementation claims are limited to what the specifications describe as implemented or ratified; design claims are attributed and carry the status research, planned or reserved.

The specifications, the constitution and the papers are not published on this portal and are not reproduced here; object and lifecycle names are reported as the shape of the design, engine choices and parameters are not. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxVM, the organ before; FxBlock, the organ after; FxChain Foundations for what independent reconstruction establishes about preserved history.