Update log
- 7 September 2026 - First edition. Drawn from the era and power map, the crossing acceptance records of the sealed development line, the closure record of the reconstruction family, and the White Paper's account of the earned-capability lifecycle. Figures shown on this portal come from the dated evidence snapshot on the home page; this dossier introduces none.
Short answer
Most software projects have a changelog: a list of what changed, written after the fact, editable at will. FxChain has something stricter. It has a sealed history. The line advances only by named crossings. Each crossing names its predecessor, states one objective, lists the powers it does not grant, and is closed by an acceptance record that binds the exact objects it accepted. Once an era is sealed, its bytes are frozen: a later era may carry meaning forward through a new artifact, but it never rewrites what an earlier era sealed.
The map that describes this is explicit about its own rank. It is descriptive, not authoritative: it creates no power, and if it ever diverges from the repository, the map must be corrected - never the repository. Its constitutional rule fits on one line: meaning moves via new artifacts; bytes stay frozen. Its corollaries fit on four: visibility is not authority; a declared fact is not an active capability; a counted authorisation is not a standing right; a sealed era cannot be reopened without a new Founder word and a new crossing.
Seven eras are sealed today, D0 to D6, each admitting one narrow power and listing the powers it still denies. Sealing an era freezes its bytes and fixes the power it admitted; it does not end work in its lineage. Later movements add artifacts inside a sealed era by new crossings - the persistence era's third movement, the reconstruction family, closed on 2 August 2026, and a fourth is not opened - without reopening the seal or rewriting a byte of it. The census of accepted crossings - the number the home page shows - is the count of these acts, each pointing at the one before it. What the sealed history does not do is as important: it does not make anything a network, it does not audit itself externally, and no successful crossing grants a reusable capability merely because a prior crossing proved one act.
What is established, what is in development, what is not claimed
| Claim | Status | Basis | Limit |
|---|---|---|---|
| Seven eras sealed, D0 to D6, each with a named admitted power and named denied powers | Proven today | Era and power map; sealed modules, frozen vectors and conformance tests | A local development line, not a network |
| The line advances only by named crossings, each with a predecessor and an acceptance record | Proven today | Crossing acceptance records on the line | Records are the line's own discipline, not an external audit |
| The constitutional rule: meaning moves via new artifacts, bytes stay frozen | Proven today | Era and power map, applied across every era | A rule of the line; its runtime generalisation is design |
| A source hierarchy for disputes: sealed modules first, the map last | Proven today | Era and power map | Applies to the repository's own record |
| A closure that separates a declared schedule from an executed one and gives each fact an owner | Proven today | Reconstruction-family closure record | The last fact - fully executed - is not provable from inside a run |
| The earned-capability lifecycle at runtime: powerless twin, vectored, audited, sealed, then activated scoped and revocable | Research | White Paper, inventions | Design; the method is practised on the line, the runtime object is not built |
| Shadow runtime and denial-bound evolution as the rule for every future power class | Research | White Paper | Design |
| Public reproduction of a seal by an outsider | Later gate | Foundations ledger | Not offered today |
| An external audit of the sealed line | Not claimed | Foundations ledger | None has taken place |
| A network, consensus, finality or a service | Not claimed | Every era's denied-powers column | None exists |
The constitutional rule
The rule is stated once in the map and enforced by construction everywhere else.
era N (sealed) era N+1
+----------------------+ +----------------------+
| bytes: FROZEN | | new artifact |
| meaning: recorded | ------> | carries meaning |
| powers: as admitted | never | forward, additively |
+----------------------+ edits +----------------------+
^
| a dispute is settled by the sealed bytes,
| not by the description of them
Figure 1 - Meaning moves via new artifacts; bytes stay frozen. A later era adds; it does not amend.
Four corollaries follow, and each one closes a door that ordinary engineering leaves open.
- Visibility is not authority. That a capability can be seen in the tree does not make it active.
- A declared fact is not an active capability. Declaring a schedule, a witness or a power is not executing it - the section on the closure below is the measured proof of how much that distinction matters.
- A counted authorisation is not a standing right. An authority spent once inside its crossing is evidence that a power was exercised, never an API for exercising it again.
- A sealed era cannot be reopened without a new Founder word and a new crossing.
What a crossing is
A crossing is the unit of advance. It is not a pull request in the usual sense, although it is carried by one; it is an act with a fixed anatomy.
crossing N
+------------------------------------------------------------+
| predecessor ......... crossing N-1 (named explicitly) |
| objective ........... one, stated |
| non-authorisations .. the powers this act does NOT grant |
| bound objects ....... exact commits, exact modules, vectors |
| acceptance record ... registers N as the unique successor |
+------------------------------------------------------------+
|
v
crossing N+1 names N as its predecessor ... and so on
Figure 2 - The anatomy of a crossing. The census on the home page counts these acts.
Two habits of the records are worth noticing. First, the non-authorisations are written before the objective is celebrated: a record of the reconstruction family lists, for one crossing, "no reconstruction, filesystem intake, operational engine, ... network, filesystem, database, RPC, node, consensus or state power" - and that is the crossing that opened the family. Second, the records distinguish activation from acceptance: a record present on an unmerged branch lets a candidate be judged by its own successor rule, but "ancestry activation is not governance acceptance"; only the Founder acceptance path grants that.
The consequence is a chain in which every link says what it is not. No row of the era map, and no crossing, grants a reusable capability merely because a prior act proved one; "a successful crossing proves only the power and scope named by that crossing."
The era map
The map describes seven eras. Each admits one narrow power and lists what remains denied; the denied column is always longer.
era role power admitted (narrow) still denied (examples)
--- -------------------------- --------------------------- ---------------------------
D0 denial and framing stable framing, explicit runtime, network, consensus,
negative boundaries finality, ambient mutation
D1 foundations versioned structural computation, transfer,
foundations persistence
D2 first computation one bounded computation standing compute right,
lineage, one verified root value movement, persistence
D3 continuity new artifacts carry frozen mutation of D2 bytes,
bytes and meanings forward standing authority
D4 first bounded authority a named, counted authority ambient authority,
exhausted inside its act delegation by implication
D5 first bounded motion one offline movement, a standing right to move,
receipted and sealed networking, admission
D6 first bounded persistence exactly one preserved a second artifact, truth
artifact, verified from storage, disk authority
Figure 3 - The era map in brief. Read the right-hand column first; it is the doctrine.
The lineage the map draws from these rows is deliberately narrow: D0 names what must not become power; D1 establishes stable foundations; D2 admits one bounded computation lineage; D3 carries meaning forward through additive artifacts; D4 admits counted authority without ambient authority; D5 spends counted authority on one offline movement; D6 spends counted authority on one preserved artifact. Nothing in that sequence is a platform. Each step is one act, bounded, and receipted.
Counted authority, exhausted keys and covenants
The map records that the motion era spent a small set of authority keys - grouped in three constitutional groups - and that the persistence era spent exactly one authorisation on exactly one artifact. The wording is careful: these are "evidence that specific powers were spent, not a reusable execution API." A key that has been exhausted proves that an act happened; it does not license the next one.
A covenant is the map's instrument for making that permanent: "a permanent boundary over an admitted power. It narrows the act; it does not enlarge it." The motion era binds movement to the exact offline transition lineage; the persistence era binds preservation to one artifact, one anchor, one carrier, and verify-or-deny reads and writes. This is the same grammar the storage constitution later adopts for any future engine, and the same grammar the FxState dossier describes from the organ's side.
The source hierarchy
When descriptions and code disagree, the map ranks the sources, and it places itself last.
1. sealed Rust modules (the bytes)
2. frozen vectors and conformance (the behaviour pinned)
3. crossing audit reports (what was examined, and how)
4. protocol specifications (what was meant)
5. the era and power map (the description of all of the above)
Figure 4 - The order used in disputes. The map "must be corrected" if it diverges from the repository.
This ordering is why the dossiers on this portal cite specifications and records rather than summaries, and why every claim table names its basis: the portal is a description, and a description ranks below the thing it describes.
A closure that corrected its own witness
The clearest illustration of the discipline is the act that closed the reconstruction family - the third movement of the persistence era - in August 2026. A closure, the record says, "that had to add a capability in order to declare an era finished would be an opening", so the closing crossing added no workspace member, no production source and no dependency. What it added was an accurate account of what the line's continuous integration proves.
The defect it found was in the line's own witness. The repository had declared a nightly schedule, asserted the declaration in a required check, and run that check green across many crossings. The number of runs actually triggered by the schedule over the whole period was zero. Two independent errors produced that result, and the record calls them the same error twice: the witness asked whether the text of a schedule appeared in a workflow file - a comment answers that - and nothing asked whether the workflow carrying the schedule was the one on the repository's default branch, the only one a forge scheduler consults. "Both are the category error of treating a DECLARATION as an EXECUTION."
fact kind who can establish it
--------------- ------------------------- ---------------------------------
DECLARED static, hermetic a structural parser of the file
ELIGIBLE forge-aware, read-only a read of the default branch
EVENT_OBSERVED forge-aware, in-run the witness, on a schedule event
FULLY_EXECUTED external, post-terminal nobody inside the run
Figure 5 - Four facts that one green tick had compressed. The last cannot be delegated to a job: a job cannot certify the success of the run still executing around it.
The closure separated the four facts permanently and gave each an owner that can actually establish it. Only then did it seal the family, and its record ends with what the seal does not establish: no public network, no permissionless consensus, no finality, no validator set, no mutable interface, no automatic state installation, no launch or deployment approval, and no successor family - "a witness proves that no artefact of either exists in the tree."
What sealed history does not do
- It does not make FxChain a network. Every era's denied column includes networking, consensus and finality.
- It is not an external audit. The records are the line's own discipline; an outside audit is listed as not claimed on the Foundations ledger.
- It does not grant reusable capabilities. An exhausted key proves an act, never a right.
- It does not let a description outrank the bytes. The map ranks itself last.
- Its runtime generalisation - the earned-capability lifecycle and the shadow runtime of the White Paper - is design.
Verdict
Sealed history is the engineering discipline seen from the outside: a line that advances only by named acts, each pointing at the one before, each listing the powers it does not take, and none able to rewrite what an earlier act sealed. The best evidence for it is the closure that found its own witness measuring the wrong thing and separated the four facts one green tick had compressed before it would seal anything. That is what "proof before power" looks like when the subject is the project's own history.
Frequently asked questions
Why not just keep a changelog?
A changelog records what changed and can be edited later. A sealed history records what was admitted, what was denied and what was bound, and it cannot be edited - only extended by a new act. The portal's changelog exists, but it describes the portal; the line describes itself through crossings.
What does "sealed" mean, precisely?
That an era's bytes are frozen and that a later era may only add artifacts. It does not mean audited by an outsider, and it does not mean deployed.
Can an era be reopened?
Not silently. The map requires a new Founder word and a new crossing, and the crossing would itself be sealed and recorded.
Where does the crossing count on the home page come from?
From the census of accepted crossing records on the line, each of which registers itself as the unique successor of the one before. The evidence snapshot states the date and the reference of the last one counted.
Is the map the authority?
No. It says so itself: sealed modules, frozen vectors, audit reports and specifications outrank it, in that order.
Sources and methodology
Drawn from the era and power map in the protocol repository, the crossing acceptance records of the sealed development line, the closure record of the reconstruction family, and the White Paper's account of the earned-capability lifecycle and the shadow runtime. Implementation claims are limited to what the records describe as sealed; design claims are attributed and carry the status research or later gate.
The records and the papers are not published on this portal and are not reproduced here. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier. Reference line: the closure discussed above is the crossing that the evidence snapshot names.
Related reading: The acceptance discipline for how a candidate is admitted; The replay domain for the family this closure sealed; FxChain Foundations for what independent reconstruction establishes.