FxBlock

Update log

• 7 September 2026 - First edition. Drawn from the block and receipt specifications, the semantic context's implemented scope, the architecture programme's chapters on blocks, checkpoints and finality attachments and on receipts, denials and settlement truth, the Yellow Paper's formal objects and finality planes, and the White Paper's grammar of organs. Commitment and receipt-family names are given as the shape of the design; the exact block grammar is not frozen and is not reproduced.

Short answer

FxBlock is the eighth organ and the end of the sequence. Its promise is to seal results and refusals together. A classic block tells you what was accepted. An FxChain block - the papers call it a capsule - is designed to also preserve why a window was bounded, what execution observed, and which claims were refused, so that finality carries denial evidence rather than hiding it.

Today a block is exactly what its specification describes: sealed from a body under the block domain, the body a typed height and an ordered list of cell identities, assembled locally in the exact order FxDAG produced, with empty or duplicate lists refused. Receipts are sealed the same way under their own domain. FxState derives a state root from the block and its receipts; FxVM and FxState refuse any block or receipt whose identity does not match its body. There is no consensus, no validator production, no finality, no inclusion of a state root in the block, and no network.

The direction gives the block its target anatomy without freezing its grammar. The architecture programme names the candidate commitments - parent, causal frontier, ordered cells, pre- and post-state roots, receipts, effects, protocol context, a finality attachment - and two laws: a block is not automatically final (finality is attached by a consensus certificate, so the same deterministic construction can be exercised in a single node and a simulator before validators exist), and finality is not legal settlement. The Yellow Paper makes the capsule a finality surface committing state, receipts, data-availability and denial roots plus coherence roots, and chains the denial roots so that anyone can verify the chain's restraint since genesis by replaying them alone.

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

Where FxBlock sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell -> [5] FxDAG -> [6] FxVM -> [7] FxState -> [8] FxBlock
                                                                                                         ^
   after FxState (a committed root), the sealed end of the sequence: what the protocol is willing to remember

Figure 1 - Step eight of eight. Everything upstream produced evidence; FxBlock seals it.

The native semantic: finality carries denial evidence

The White Paper's grammar of organs replaces the block with the capsule - a finality surface committing state, receipts, data availability and denial roots - and names the refusal: finality without denial evidence. Two native laws meet in the organ.

Denial is a first-class output. A refusal past the admissibility threshold is a sealed, typed result. The capsule is where sealed denials are committed beside sealed results, so that what the protocol refused is as verifiable as what it did.

Finality is a function, not a number. Settlement lives on declared planes derived from the effect algebra, each with latency bounds, challenge windows, blast caps and evidence-tier floors; the caps are committed in the denial root. A block does not have one finality; a capsule seals the finality each claim declared.

   a classic block                        a capsule
   +---------------------------+          +--------------------------------------+
   | transactions accepted     |          | state root      what changed         |
   | state root                |          | receipts root   what was observed    |
   +---------------------------+          | DA root         what is available    |
   what happened                          | denial root     what could not happen|
                                          | coherence roots organ and twin agree |
                                          | certificate     under which quorum   |
                                          +--------------------------------------+
                                          what happened, and what provably could not

Figure 2 - The organ's advantage in one picture. The right-hand column is the doctrine of the whole protocol, sealed.

What exists today

Sealed from a body. A block is sealed from a body that carries a typed height and an ordered list of cell identities, encoded canonically and hashed under the block domain to derive its identity. Receipts are sealed from their own body under the receipt domain. Construction goes through the shared builder; the unchecked constructors are reserved for primitives, tests and already-verified data. Conformance vectors pin sample bodies and identities.

Assembled in FxDAG's order. Local assembly consumes FxDAG's ordering result and preserves it exactly. It refuses an empty list and a duplicate cell identity. It does not sort, and it does not implement consensus, validator production, finality, inclusion of a state root or networking.

Checked at every boundary. FxVM refuses a block or cell whose identity does not match its body before harness execution; FxState refuses a block or receipt with the same defect before commitment. The local state root is derived from the block and its receipts; on the local line it is not written into the block.

   FxDAG order (cell identities)
        |
        v   refuse: empty list . duplicate identity
   FxBlockBody { height, ordered cells }  -- hash under the block domain -->  FxBlockId
        |
        v   FxVM: one receipt per cell (receipt domain)
        v   FxState: harness state root from block + receipts
   sealed local FxBlock
        |
        x   no consensus . no validators . no finality . no root inclusion . no network

Figure 3 - The block on the local line: a sealed, ordered, verifiable local artifact, and nothing that requires a network.

The direction

The target anatomy

The architecture programme keeps the block as the auditable unit that binds an ordered transition result and specifies its target anatomy so that later crossings know what must be decided, without freezing the exact grammar. Candidate commitments are a parent reference, a causal frontier, a commitment over the ordered cells, the pre-state root and the post-state root, a receipts root, an effects root, the protocol context and a finality attachment. The programme is explicit about a temptation the design must resist: root proliferation. Each commitment must be justified by an independent verification or data-availability need.

A block is not automatically final. Finality is attached by a consensus-specific certificate. The same deterministic block construction can therefore be exercised in a single-node living node and in a simulator before any validator exists - which is the staging rule of the whole architecture applied to its last organ.

Checkpoints are not blocks. A checkpoint may accelerate restart, state synchronisation or light verification by committing a known-good state and lineage coordinate. Its creation and acceptance rules must prevent a convenient snapshot from silently becoming canonical history.

Finality is not legal settlement. A finality certificate establishes the consensus result under a validator set and an epoch. External domains may consume it as evidence; it claims no bank cash delivery, no securities settlement and no court enforceability.

The capsule and the denial root

The Yellow Paper's formal object is the capsule: epoch, state root, receipts root, data-availability root, denial root, coherence roots and a certificate. Epoch capsules crystallise finality; after a capsule certificate, history is irreversible, and a correction is a new claim, never a rewrite.

The denial root is chained. Each one commits the catalogue version, the epoch, the previous denial root, the genesis denial certificate sealed at block zero, a commitment over the verdicts of every no-authority invariant, and the hash of the versioned proof-engine catalogue used to evaluate them. A capsule is invalid if any verdict fails or is missing. Chaining lets a third party verify the chain's restraint since genesis by replaying denial roots alone; committing the proof-engine catalogue makes a silent change of the evaluation rules as impossible as a silent rewrite of history. The paper names the mechanism proof-engine continuity, and bounds its claim: what is proven is the continuity and integrity of the judge across every epoch - never a prophecy about future behaviour.

   genesis denial certificate  (sealed at block zero: the full no-authority catalogue)
        |
        v
   denial root (epoch 1) = commit( catalogue version, epoch, previous root,
                                    verdicts of every invariant, proof-engine catalogue )
        |
        v
   denial root (epoch 2) ...  each root binds the one before it

   replay the roots alone -> verify what the chain could not do, since genesis

Figure 4 - The chained denial root. Restraint becomes a consensus object, verifiable by anyone, epoch after epoch.

Finality planes

Plane assignment is a pure function of a claim's declared effects. Four planes - fast, standard, assurance, policy-bound - each fix a latency bound, a challenge window, a blast cap per epoch, a required evidence-tier floor, quarantine eligibility and fee dimensions; per-plane caps are committed in the denial root; a claim touching several planes settles on the strictest; the fast plane has a hard latency budget that slower planes cannot degrade. The paper's worked examples make the idea concrete: a retail low-value payment settles fast; an ordinary application interaction on the standard plane; a bridge mint or a large movement on the assurance plane; a regulated corridor or an institutional treasury flow on the policy-bound plane, which is distinct in kind - it evaluates more law before finality - and confers no privilege over the others. High blast-radius effects are born inside structural challenge windows that nothing, and no artificial-intelligence output in particular, can create, extend or shorten.

Receipts, denials and the truth of settlement

Receipts are a primary truth surface, and the architecture programme separates their families by plane: the runtime owns execution, admission, denial, recovery and finality receipts; the change plane owns transition, acceptance and closeout receipts; the assurance plane owns witness, finding and reproduction receipts. A minimal shared header carries identity, subject, version, reason and commitment; the semantics stay with the plane.

A denial is not merely a failed flag. It identifies the exact deterministic refusal boundary, the reason code, the subject and the relevant committed context, without exposing secrets unnecessarily; where disclosure is safe an actionable denial may name the applied rule, the failed obligation, the missing evidence class, the authority basis and a bounded remediation hint, and the programme separates a reconstructible reason from unbounded disclosure. The complete financial picture is split into a runtime settlement receipt, an external settlement claim and a settlement-truth projection, under non-compression laws the organ must never let a capsule blur:

   EXECUTED                 !=  FINALIZED
   FINALIZED                !=  EXTERNAL_RAIL_DELIVERED
   EXTERNAL_RAIL_DELIVERED  !=  LEGAL_EFFECT
   LEGAL_EFFECT             !=  ECONOMIC_COMPLETION
   MISSING_EVIDENCE         !=  FALSE
   INSTRUMENT_ERROR         !=  DOMAIN_FAILURE

Figure 5 - The non-compression laws of settlement truth. A capsule seals what the protocol established; it never claims what only an external domain can.

Where a profile needs a retrospective explanation, receipts may bind compact commitments to the lineage of the policy and the authority under which they were produced, so that an auditor can ask why a rule was active at a coordinate and walk the amendment lineage without modifying historical bytes.

The refusal that defines it

FxBlock refuses three things, and each is a refusal to let finality lie.

• History that hides rejected claims. A capsule without its denial root is a classic block, and the organ does not produce classic blocks.
• Incomplete proof material. A capsule whose invariant verdicts are missing, or whose receipts do not cover its cells, is invalid - on the local line by the boundary checks, in the direction by construction.
• Blocks that cannot explain their own boundaries. The causal frontier, the protocol context and the finality attachment exist so that a block can say what window it bounded and under which rules. A block that cannot is not sealed.

What FxBlock does not do

• It does not implement consensus, validator production, finality, state-root inclusion or networking on the local line.
• It is not final by itself, even in the direction: finality is a certificate attached by consensus, and no validator set exists.
• It does not claim legal settlement, cash delivery or enforceability. A finality certificate is evidence an external domain may consume, nothing more.
• The capsule, the chained denial root, finality planes, receipt families and the settlement-truth laws are design, stated as research.

Verdict

FxBlock closes the sequence with the object that makes the protocol's doctrine checkable from outside. What exists is a sealed local block - a height, an ordered list of cells, receipts under their own domain, integrity refused at every boundary - assembled in exactly the order the DAG produced and never touched by a network. What is designed is the capsule: results, receipts, availability and denials sealed together under a certificate, with denial roots chained back to genesis so that anyone can replay the chain's restraint. The organ's advantage line is the protocol's whole argument: a capsule records not only what happened, but what could not legitimately happen.

Frequently asked questions

Is an FxBlock final?

Not on the local line, where no finality exists, and not by itself in the direction either: finality is a certificate attached by consensus under a validator set and an epoch. The block construction is deterministic so that it can be exercised before validators exist.

What is a denial root?

A commitment, sealed in every capsule, over the machine-evaluated verdicts of the protocol's no-authority invariants for that epoch - zero mint outside authorised rules, zero mutation of finalised history, zero capability escalation, and the rest of the catalogue. Roots are chained, and a capsule is invalid if any verdict fails or is missing.

Why chain the denial roots?

So that a third party can verify the chain's restraint since genesis by replaying the roots alone, and so that a silent change of the evaluation rules is impossible: each root also commits the versioned catalogue of the judge that produced it.

Does finality mean my money moved?

No. Finality establishes the consensus result. Whether an external rail delivered, whether a legal effect followed and whether the economic transaction completed are separate dimensions, kept separate by law, and never claimed by a capsule.

What is a checkpoint?

A known-good state and lineage coordinate committed to accelerate restart, synchronisation or light verification. It is distinct from a block, and its rules exist to stop a convenient snapshot from silently becoming canonical history.

Sources and methodology

Drawn from the block, receipt and state specifications in the protocol repository, the semantic context's implemented scope, the architecture programme's chapters on blocks, checkpoints and finality attachments and on receipts, denials, conflicts and settlement truth, the Yellow Paper's formal objects, consensus semantics and finality planes, and the White Paper's grammar of organs and truth-layer inventions. Implementation claims are limited to what the specifications describe as implemented; design claims are attributed and carry the status research.

The specifications and papers are not published on this portal and are not reproduced here; the exact block grammar is not frozen and is not reproduced. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxState, the organ before; FxWire, where the sequence begins; Technology for the eight organs at a glance.