FxCell

Update log

• 7 September 2026 - First edition. Drawn from the cell and effect specifications, the semantic context's implemented scope, the architecture programme's chapter on cells, the DAG and causal topology, the Yellow Paper's formal objects, and the V0.5 doctrine addendum. Object names and relationships are given; candidate field lists are described, not enumerated.

Short answer

FxCell is the fourth organ and the first one nobody outside the protocol ever writes. Its promise is to package a claim as a causal execution unit. An intent that FxCore has admitted is turned into a cell: a compact, sealed object that carries the claim's identity, what it depends on and what it declares it will touch, so that the two organs downstream - FxDAG, which orders, and FxVM, which executes - never have to discover any of that by running it.

Today a cell is exactly what the specification says: sealed from a canonical body under the cell's own hash domain, built through one builder that refuses an identity that does not match its body, created by FxCore from a sealed intent with the intent's identity inside it and a dependency list that is intentionally empty. Dependency discovery, conflict analysis and scheduling are stated as the responsibility of later work. Beside the cell sits a declaration schema for effects - resources named by namespace, key and version; access modes of read and write; sorted, duplicate-free declarations - that is declaration-only, and a family of inspect-only surfaces that expose those declarations as facts.

The direction calls the cell the universal economic atom of a causality-first protocol: FxChain is not block-first, and the block is the commitment of an order that the cells and the DAG produced. A target cell carries references to its intent, its authority and evidence context, its declared access set, its declared effect set, its causal parents, its constraints and a commitment over all of it - compact, deterministic, and never inlining governance or assurance machinery.

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

Where FxCell sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell -> [5] FxDAG
                                                   ^          -> [6] FxVM
                                                   |          -> [7] FxState
   after FxCore (an admitted claim), before FxDAG (ordering)  -> [8] FxBlock

Figure 1 - Step four of eight. The cell is the object that leaves the constitutional gate and enters the machinery.

The native semantic: causality is claimed before it is exercised

The refoundation of the papers derives declared access sets from the axiom in one line: causality is claimed before it is exercised; the DAG orders claims, not surprises. The cell is the object that carries the claim.

Two native laws meet in it. Claim before power - a cell is still a claim; being admitted has given it a body, not authority to run. One effect algebra - what a cell declares it will touch and cause is stated in the same closed taxonomy as every other claim, so that the organs downstream can derive, deterministically, what it needs, where it may conflict and what receipt it will leave.

   admitted claim
        |
        v
   +-----------------------------------------------------+
   |  FxCell                                             |
   |  . the intent it carries (by identity)              |
   |  . what it depends on (causal parents)              |
   |  . what it declares it will read and write          |
   |  . what effects it declares, and their bounds       |
   |  . a commitment over all of the above               |
   +-----------------------------------------------------+
        |                                  |
        v                                  v
   FxDAG orders it                    FxVM executes it
   from its declarations              under its declarations

Figure 2 - The cell as a contract with the organs downstream. Nothing they need is discovered by running it.

The V0.5 doctrine addendum states the consequence for the whole protocol: FxChain is causality-first, not block-first. The cell is the universal economic atom; the block is not the source of order but the commitment of a causal order that FxDAG produced. Everything that follows in the sequence is organised around that inversion.

What exists today

Sealed from a body. A cell is sealed from a canonical body, encoded canonically and hashed under the cell domain to derive its identity. Construction goes through the same builder as the intent; the unchecked constructor that skips the identity check is reserved for primitives, tests and already-verified data. Conformance vectors pin sample bodies and derived identities.

Created by FxCore, with empty dependencies. FxCore's normalisation creates the first cell from a sealed intent. The body's intent reference equals the sealed intent's identity, and the dependency list is intentionally empty. The specification says why in one sentence: dependency discovery, conflict analysis and scheduling remain the responsibility of later work. The line proves the object and its identity discipline before it proves anything about causality.

   sealed FxIntent (identity I)
        |
        v   FxCore normalisation
   FxCellBody { intent = I, dependencies = [] }
        |  canonical encoding, hash under the cell domain
        v
   FxCellId  --->  FxCell (sealed by the builder)
        |
        x   FxVM refuses a cell whose identity != hash(body)

Figure 3 - The cell on the local line. The identity is derived; the dependency list is empty on purpose; the next organs check the seal before touching the cell.

A declaration schema for effects. Version zero of the effect declaration names resources by namespace, key and version; it supports read and write access; declared accesses are sorted with no duplicate entries; optional dependency identifiers are sorted with no duplicates; empty namespaces, empty keys and duplicates are refused. A helper treats two accesses to the same resource as conflicting when either is a write. All of it is declaration-only: the specification is explicit that it is a baseline for future access-set and dependency work, not enforcement.

Facts before rules. Inspect-only admission sidecars carry effect declarations on intent-envelope inspection artifacts; an opt-in shadow dependency report reads them and exposes deterministic, non-authoritative facts. None of it orders, executes, mutates or grants.

The direction

The target cell. The architecture programme keeps the current owner until a successor is ratified and enriches the cell's relationship to its intent with explicit causal and effect context. A target cell references its intent, its authority context and its evidence or profile context, carries its declared access set and declared effect set, names its causal parents and constraints, and commits to all of it. The references are compact and deterministic; the cell must not inline governance or assurance machinery.

The formal object. The Yellow Paper's vocabulary is the same shape in fewer words: a cell is the causal unit - parents, intent reference, declared access, lane and the material from which its conflict key is derived. The conflict key is what lets FxDAG decide, deterministically, which cells commute and which contend.

Declared access as a contract. In the direction, execution against a resource the cell did not declare does not trap the network: the cell aborts deterministically, and its receipt carries the observed access set with a divergence proof, so that the claimant can resubmit with a widened, correct declaration. Legitimately dynamic access patterns - registries, pools - use typed, bounded namespace claims priced by state congestion; claims that cannot bound themselves at all are routed to a serialised lane and pay for their opacity instead of poisoning parallelism.

   declared access set                    what execution observed
   { read  a, write b }                    { read a, write b, write c }
                     \                      /
                      \  compared, per cell /
                       v                  v
        match: proceed            mismatch: abort deterministically,
                                  seal the observed set with a
                                  divergence proof, advise a widened
                                  claim - no state mutation of any kind

Figure 4 - The declaration is a contract. The cell that keeps it runs; the cell that breaks it aborts identically on every node, and leaves evidence.

The refusal that defines it

A cell refuses two things, and both are structural rather than judgmental.

• Hidden dependencies. A cell that depends on something it did not declare cannot be ordered safely, because FxDAG would order it from a lie. On the local line the dependency list is empty and declared so; in the direction, causal parents are part of the sealed body and part of its commitment.
• Claims that cannot declare enough structure. A claim whose access and effects cannot be stated in the algebra cannot be given a body that the downstream organs can trust. It is refused at FxCore, and the cell is never built.

What FxCell does not do

• It does not discover dependencies, analyse conflicts or schedule anything on the local line. Its dependency list is intentionally empty, and the specification says so.
• It does not enforce its declared access or effects. Version zero of the effect declaration is a schema and a helper, not an executor.
• It does not order or execute. FxDAG orders cells; FxVM executes them.
• It does not inline authority, evidence or governance material. In the direction it carries references and a commitment, never the machinery.
• No cell mutates state anywhere on the local line.

Verdict

FxCell is the organ where FxChain's claim about causality becomes an object. What is implemented is deliberately minimal and deliberately honest: a sealed body with a derived identity, created from an admitted intent, with a dependency list left empty until dependency discovery is real work rather than a field. What is designed is the atom of a causality-first protocol - a compact unit that declares what it depends on and what it will touch, so that ordering and execution never have to guess. The empty list on the local line is not a gap in the story; it is the story told at the right tense.

Frequently asked questions

Is a cell a transaction?

No. An intent is the claim a participant writes; a cell is what the protocol builds from an admitted intent so that it can be ordered and executed without surprises. One intent yields one cell on the local line; the direction keeps the relationship explicit.

Why is the dependency list empty?

Because the local line proves the object before it proves causality. A dependency that is discovered by running the cell is exactly the hidden dependency the organ refuses; declaring dependencies properly requires the access-set and conflict work that later waves own. Leaving the list empty and saying so is the honest state.

What happens when a cell touches something it did not declare?

In the direction: it aborts deterministically, mutates nothing, and its receipt seals the observed access set with a divergence proof. The claimant receives an advisory widened claim and may resubmit, within a budget. That is FxVM's part of the story, and it has its own dossier.

Can a cell carry authority?

No. It carries references to the authority context under which it was admitted. Authority was judged by FxCore and remains a capability; the cell is a body, not a permission.

What is a conflict key?

Material derived from the cell's declared writes from which FxDAG computes, deterministically, which cells contend for the same resources. Cells whose declared writes intersect form a conflict set; cells whose declarations do not intersect commute.

Sources and methodology

Drawn from the cell, effect and execution specifications in the protocol repository, the semantic context's implemented scope, the architecture programme's chapter on cells, the DAG and causal topology, the Yellow Paper's formal objects and execution semantics, the refoundation's derivation of declared access sets, and the V0.5 doctrine addendum. Implementation claims are limited to what the specifications describe as implemented, declaration-only or inspect-only; design claims are attributed and carry the status research.

The specifications and papers are not published on this portal and are not reproduced here; candidate field lists are described, not enumerated. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxCore, the organ before; FxDAG, the organ after; FxVM for what happens to a cell's declarations at execution.