The storage constitution

Update log

• 7 September 2026 - First edition. Drawn from the ratified storage constitution and its continuation gate in the protocol repository, the era and power map, the state and witness specifications, and the architecture programme's chapters on state and on persistence and continuity. Ring, plane and gate names are reported as doctrine; no engine, format or parameter is.

Short answer

Most systems choose a database first and discover its truths later: what its internal ordering means, what its absence proofs prove, what a page identity is worth, what happens when the vendor changes. FxChain's persistence era admitted exactly one preserved artifact and then stopped, and before the line could go further the Founder wrote a constitution over storage - ratified in July 2026, documentation only, "no engine selected, no implementation authorised".

It begins with a correction. A commodity database-selection path had started: engine selection before commitment law, product allowlists inside security witnesses, speed-first comparison, storage treated "as a catalogue of familiar infrastructure products", an engine's internal representation treated as implicit protocol truth. The Founder rejected it and restored the native order: law, then grammar, then an independent oracle, then architecture families, then truth gates, then witness portability, then operational escape, then measured evidence, then a future Founder crossing - and only then engine authorisation.

On that order the constitution fixes three rings (sovereign, projection, edge), six planes (commitment, hot state, causal journal, cryo, projection, edge) and nine permanent covenants, the first of which is the whole doctrine in three words: truth precedes storage. A storage engine is "an authorised capability, never an ambient substrate"; nothing engine-owned may become canonical by implication; every sovereign read is verified against an expected commitment; derived state is reconstructible and disposable by law; consensus alone distributes canonical authority; cold state is sovereign only when it can be resurrected and proven; engine replacement requires both semantic portability and operational escape.

What it is not: a database, an engine, a module, a type or a format. Its own status block says so, and it ends with a list of what it does not authorise - every named engine, a custom production store, state rent, expiry, new formats, new hash domains, a single new dependency.

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

The correction, and the order it restored

The constitution records why it exists. The rejected drift was not a bad engine; it was the order in which an engine was being considered - before the protocol had defined the law of canonical storage. The restored order reads as a staircase, and it is the same staircase every other capability on the line has climbed.

   law
    -> grammar
        -> independent oracle
            -> architecture families
                -> truth gates
                    -> witness portability
                        -> operational escape
                            -> measured evidence
                                -> future Founder crossing
                                    -> only then: engine authorisation

Figure 1 - The restored order. Engine authorisation is the last step, not the first.

The constitution describes the correction plainly: it "prevented a generic infrastructure route, selected no competing storage engine, and raised the required level of originality, sovereignty, and proof." The persistence era remained sealed; the pending storage work remained suspended; the merge remained blocked.

Rings and planes

The doctrine organises storage by what a piece of state is - truth-bearing, derived, or user-side - and by what it does.

   RINGS                                PLANES
   +-------------------------------+    commitment      the protocol-owned roots
   | sovereign ring                |    hot state       current authenticated state
   |   truth-bearing, proof-bound, |    causal journal  the ordered history
   |   consensus-relevant          |    cryo            cold, resurrectable state
   +-------------------------------+    projection      reconstructible read models
   | projection ring               |    edge            user-side secrets and caches
   |   reconstructible read models |
   +-------------------------------+    "doctrine-level descriptions only":
   | edge ring                     |    no module, crate, type, format,
   |   user-side secrets, caches,  |    capability, authority, runtime
   |   metadata, interaction state |    behaviour or implementation permission
   +-------------------------------+

Figure 2 - Three rings, six planes. The names bind meaning; they create nothing.

The separation carries the architecture programme's law that canonical truth and projections are different species: dashboards, caches, indexes and analytical stores are reconstructible consumers, never silent sources of consensus truth. The projection ring is where an application reads; the sovereign ring is where the protocol commits; the edge ring is where a user's secrets live and never become anyone else's authority.

The permanent covenants

Nine articles are "permanent until a new era word". They are short, and each closes a door that database-first design leaves open.

1. Truth precedes storage.
2. Nothing engine-owned - representation, invariant, proof geometry, absence rule, page identity, compression strategy, internal ordering - may become canonical by implication.
3. Canonical commitment and witness grammars remain protocol-owned, independently specified, independently implementable and independently recomputable.
4. A sovereign storage engine is an authorised capability, never an ambient substrate.
5. Every sovereign read is verified against an expected commitment.
6. Derived state is reconstructible and disposable by law.
7. Consensus is the sole distributor of canonical authority; no distributed database replaces consensus.
8. Cold state is sovereign only when it can be deterministically resurrected and proven against an expected root.
9. Engine replacement requires both semantic portability and operational escape.

Read together they say one thing: an engine may hold what the protocol has made true, and may never define it. The second covenant is the sharpest, and the FxState dossier meets it from the other side: "no engine-owned representation enters the canonical preimage silently."

The presumption and the two families

The constitution does not pretend neutrality between designs. Protocol-owned commitment over an interchangeable substrate carries the rebuttable sovereignty presumption. The other family - an integrated authenticated engine, where the engine's own tree is the commitment - may overcome that presumption "only through measured evidence and complete satisfaction of all truth, witness, migration, operational-escape and sovereignty gates", proving independent grammar ownership, independent root recomputation, engine-independent witnesses, semantic migration, operational escape, witness portability, acceptable sovereignty census results, and "materially superior performance after every truth gate. Performance alone never compensates for truth capture, witness capture or exit capture."

   family B (presumed)                       family A (must rebut)
   protocol-owned commitment                 integrated authenticated engine
   +-----------------------------+           +-----------------------------+
   | roots the protocol can      |           | the engine's tree is the    |
   | specify and recompute       |           | commitment                  |
   +--------------+--------------+           +--------------+--------------+
                  |                                         |
                  v                                         v
   replaceable substrate (engine A / B / ...)  must prove: grammar ownership,
                                               root recomputation, portable
                                               witnesses, migration, escape,
                                               and only then performance

Figure 3 - The presumption. The burden of proof sits with the design that would let an engine define truth.

The oracle and the tribunal

Before any engine is tried, the laboratory uses "a pure, deterministic, deliberately slow, in-memory commitment oracle". It is not a database, not a production engine, not runtime authority, not consensus, not filesystem authority. And it is not trusted on its own word: "the oracle must itself be independently recomputed before it may adjudicate storage candidates", with one pure reference implementation, one independent recomputation, and a frozen reviewer-computed corpus of expected commitments. The replay-domain dossier shows the same rule applied to reconstruction - the judge is recomputed before it judges.

Candidates then pass a tribunal, in a fixed order. First, admission: licence eligibility, provenance, maintainer concentration, dependency census, release and security maturity, unsafe and foreign-interface census, native-build and operational-assumption census, grammar expressibility. Results attach to exact immutable pins - repository, commit, version, complete licence text, dependency lock, features, build profile, toolchain - "not merely project or product names". Then the families are compared before implementations. Then the truth gates, all eliminatory:

   truth gates (eliminatory, in order)
   . same canonical transcript -> same state root
   . same root -> same witness validity
   . no silent corruption
   . no publication of unflushed state
   . complete deterministic export
   . cross-engine import preserves the exact root
   . cold resurrection proves the expected root
   . recovery never invents state
   . the approved validator hardware envelope is respected
   . witness portability
   . operational escape
                          |
                          v   only after every gate passes:
   performance scoring: proofs first, then crash recovery and cold
   resurrection, then write amplification and endurance, then latency,
   then auditability and code surface, then supply-chain sovereignty,
   then portability and operational simplicity

Figure 4 - Truth before speed. "Truth is mandatory and is never compensated by performance."

The workloads the tribunal must run read like the organs' own vocabulary: batch commitment of cells, declared read and write sets, authenticated reads, proof generation, absence proofs, speculative sessions, one-writer canonical commitment, snapshot export, cold resurrection, complete migration, state-sync serving, revision pruning, dust stress, tombstone churn, adversarial key geometry, crash and power-loss trials, cold and live escape, hardware-envelope trials.

State lifecycle and governance

Two short articles keep the economics out of the engine: state rent, expiry, pruning, tombstones and resurrection rights "are protocol and economic semantics, not engine-local policies", and "no engine may silently expire, reinterpret, reclaim or transform canonical facts." Two more keep vendors out of the constitution: no vendor or engine name is constitutional, and the laboratory roster is amendable and non-constitutional. Foreign-interface, unsafe and operational privilege are reported through four census categories rather than hidden.

Production selection, finally, requires all of: measured evidence; an explicit Founder ruling; a future crossing; a decision record; an exit proof; a hostile audit; a complete conformance rerun. That is the later gate this portal reports.

What the constitution does not authorise

The ratification ends with a list, and the list is the doctrine's honesty: no adoption of any named engine, no custom production store, no state rent, no time-to-live, no cryptographic tombstones, no actor-scoped commitment, no dual-engine production, no continuous canonical publication, no new state, witness or export format, no new hash domain, no new dependency. Any later ratified difference in a truth-bearing dimension invalidates previous truth-gate results and requires a complete rerun.

   authorised today                         not authorised
   +------------------------------+         +----------------------------------+
   | the doctrine (this record)   |         | any named engine . a custom store|
   | one preserved artifact (D6)  |         | state rent . TTL . tombstones    |
   | off-repository Draft V0 work |         | new formats . new hash domains   |
   |   (non-binding, no V1 bytes) |         | new dependencies . dual engines  |
   +------------------------------+         +----------------------------------+

Figure 5 - What the ratification permits, beside what it withholds. The right-hand column is longer, as always on this line.

What the storage constitution does not do

• It selects no engine and integrates none. Draft work is off-repository and creates no protocol artifact.
• It creates no module, crate, type, format, capability or runtime behaviour; the rings and planes are names for meaning.
• It does not reopen the persistence era: one artifact remains the only thing preserved.
• It does not make cold state real. FxCryo is a reserved plane; resurrection is a gate a candidate must pass, not a capability the line has.
• It is not a performance benchmark. Scoring begins only after every truth gate.

Verdict

The storage constitution is the persistence question asked in the right order. Instead of choosing an engine and discovering what it silently decides, the line wrote down what any engine must never decide - the preimage of a root, the validity of a witness, the meaning of absence, the moment of durability, the right to expire a fact - and made those permanent covenants before a single candidate was named. Its presumption puts the burden of proof on the design that would let storage define truth, its oracle is recomputed before it judges, and its tribunal scores speed only after truth. On the local line it governs exactly one preserved artifact. That is the point: the law exists before the power, and the power will be small when it comes.

Frequently asked questions

Which database does FxChain use?

None. The local line preserves one authorised artifact under the persistence era's covenants; the constitution names no engine and authorises none. Named engines appear in it only in the list of what is not authorised.

Why write a constitution before choosing?

Because an engine chosen first decides things by implication - its ordering, its absence proofs, its page identities, its compression - and those decisions become protocol truth nobody voted on. The correction the constitution records was made to stop exactly that.

What is the "rebuttable presumption"?

That a protocol-owned commitment above a replaceable substrate is presumed the sovereign design. An engine whose own tree is the commitment may overcome the presumption only by measured evidence and every truth, witness, migration, escape and sovereignty gate - never by speed.

What is FxCryo?

A reserved doctrine plane for cold, resurrectable state. In the constitution it is the cryo plane and the gate "cold resurrection proves the expected root". It is design direction, not implemented.

When will an engine be selected?

At a later gate the constitution defines - measured evidence, an explicit Founder ruling, a future crossing, a decision record, an exit proof, a hostile audit and a complete conformance rerun - and not before. No date is claimed.

Sources and methodology

Drawn from the ratified storage constitution and its continuation gate in the protocol repository, the era and power map, the state and witness specifications of the local line, and the architecture programme's chapters on object-centric state and on persistence, continuity, recovery and cold resurrection. Quotations are from the constitution. Implementation claims are limited to what the records describe as sealed or ratified; design claims carry the status planned, research, reserved or later gate.

The constitution and the papers are not published on this portal and are not reproduced here; rings, planes, gates and covenants are reported as doctrine, and no engine, format or parameter is. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxState for the organ this law governs; The replay domain for the recomputed judge; Three planes for the doctrine planes around it.