The living node

Update log

• 7 September 2026 - First edition. Drawn from the architecture programme's chapter on completing the blockchain architecture, its node ladder, common trunk and deployment-necessity tribunal, the reconstruction family's node-integration record, and the era and power map. Ladder identifiers appear only as a reference line.

Short answer

Every era of the line has denied "networking" and "consensus". What exists today is the bottom rung of a ladder the programme draws explicitly: a deterministic local kernel. One step above it stands the living node: "bounded socket, signed intent, transition, receipt, query" - the smallest thing that can be called a node because it accepts a claim from outside itself and answers with evidence. Above that: a durable node that survives a crash and reconstructs exactly; a consensus simulator running the same kernel under hostile schedules; a private three-node devnet; a hostile devnet with partitions, equivocation and corruption; a public testnet candidate; a mainnet candidate. The programme instructs itself to "define private devnet, hostile devnet, public testnet, and mainnet gates without claiming any of them exist today."

The second half of the direction is the unusual one. The programme's common trunk "must produce useful capabilities even if a sovereign chain is rejected", and after it stands a deployment-necessity tribunal whose possible outcomes include closing evidence gaps only, a simple mode built on the offline verifier and an evidence toolkit, a hybrid supervisory deployment, bounded pilots with no default winner - and a sovereign branch that is "justified, not authorised", inert until a separate Founder act. Before that decision the programme even asks itself which useful product "survives if the sovereign L1 thesis is rejected".

Today, one measured fact stands between the kernel and the living node: the line already carries a bounded, loopback-only, read-only local-control transport with a state-authority firewall as its seam. The reconstruction family used it as its door. "The port exists and the connection does not."

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

The ladder

   N0  deterministic local kernel ............ today
   N1  living node ........................... socket -> signed intent
                                              -> transition -> receipt -> query
   N2  durable node .......................... journal -> checkpoint
                                              -> crash/restart -> exact reconstruction
   N3  consensus simulator ................... same kernel, hostile schedules
   N4  private three-node devnet ............. real processes, convergence, resync
   N5  hostile devnet ........................ partitions, equivocation, churn,
                                              corruption, data-availability failure
   N6  public testnet candidate .............. release, operations, economics,
                                              external reproduction
   N7  mainnet candidate ..................... security, legal, economic,
                                              governance and operational gates

Figure 1 - The node ladder. Only the first rung exists; the programme forbids claiming any other.

Two features of the ladder matter more than its length. The first is one kernel: the programme requires "one shared transition kernel used by the local node, simulator, validator, independent oracle, replay tool, and state-sync verifier". The simulator does not run a model of the node; it runs the node. That is the staging rule of the whole architecture - exercise the deterministic construction before validators exist - applied to consensus. The second is the order of definitions: "define the consensus problem before selecting an algorithm family", and "define safety, liveness, synchrony, adversary, and recovery assumptions explicitly". No algorithm is named because no problem has yet been stated with enough precision to choose one honestly.

The living node, precisely

The living node is deliberately small. A bounded socket: an interface with declared limits, not an open port. A signed intent: the claim the FxIntent dossier describes, with its constraints, expiry and proofs. A transition: the kernel's deterministic processing, unchanged from the local line. A receipt: what execution observed. A query: the ability to ask the node what it holds, read-only. Nothing about consensus, peers or finality appears at this rung, and nothing should: the living node is a single process that can be asked and can answer with evidence.

   outside                     living node (one process)
   -------                     ------------------------------------------
   signed intent  --socket-->  admissibility -> cell -> order -> execute
                                     |                              |
   receipt        <-----------  sealed receipt  <-------------------+
   query          --socket-->  read-only view of committed state

Figure 2 - The smallest node. It accepts, judges, executes, answers - and cannot be told what to believe.

What already exists is the door. The reconstruction family measured, before designing its node integration, that the line carried "a bounded, loopback-only, read-only local-control transport" whose service seam is called the state-authority firewall. It refused to build a second one - "the read-only guarantee would have two owners, and one of them would eventually be wrong" - and connected reconstruction through the existing seam with "no socket, no address, no listener and no frame". The living node will pass through the same door, and the transport's rule will still hold: a request that would mutate has no representation.

The durable node and beyond

The next rung is where the storage constitution becomes operational: a journal, a checkpoint, a crash at controlled failure points, a restart, and reconstruction to "the identical canonical root and head - or a typed refusal when the persisted world is inconsistent". The programme lists what must be defined to get there - durable authenticated state, causal journal, checkpoint, crash recovery, reconstruction, and "storage-engine escape without violating the Storage Constitution" - and the FxState dossier describes the pipeline.

Above it, the definitions the programme requires before any network exists read like a syllabus of everything a chain usually improvises: a bounded transport with anti-amplification and eclipse resistance; deterministic admission and a transaction pool that never becomes canonical truth; validator identity, epochs, reconfiguration, quorum, fork choice, equivocation evidence and finality certificates; authenticated roots, witnesses, data availability, light clients, archive, pruning and resurrection; resource metering and denial-of-service economics "before a general-purpose VM expands"; genesis, chain and network identity, upgrades and non-retroactivity; reproducible releases, provenance, runbooks, incident response, backup, restore and exit; and the economic-security research "while authorising none".

The tribunal that may say no

This is the part of the direction that is hardest to find anywhere else. The programme's common trunk - truth and schemas, the capability graph and a public truth release, canonical grammar and determinism closure, the authority and denial kernel, the living node with the offline verifier, the durable node with an exit drill, and a hostile laboratory with two reconstruction engines and a no-migration institutional pilot - "must produce useful capabilities even if a sovereign chain is rejected." After it comes a gate: the deployment-necessity tribunal.

   common trunk (useful even if no chain is ever deployed)
        |
        v
   DEPLOYMENT NECESSITY TRIBUNAL
        |
        +--> evidence unestablished .... close evidence gaps only; no branch selected
        +--> simpler mode sufficient ... adoption zero and one: verifier, evidence SDK
        +--> hybrid mode preferred ..... supervisory deployment, shared evidence service
        +--> no single mode dominates .. bounded pilots, each with an effect ceiling,
                                         a budget and a re-tribunal trigger; no default winner
        +--> sovereign L1 justified .... eligible, NOT authorised: implementation blocked
                                         until a new, detached Founder act
        +--> Founder decision required . branch selection blocked

Figure 3 - Six dispositions, and the sovereign chain is only one of them. Nothing here presumes a network.

The constraints attached to each disposition are as telling as the list. A simpler mode carries "no hybrid network implied, no sovereign network implied". Bounded pilots require that "each pilot has an effect ceiling", a cost, time and authority budget, and a trigger to re-open the tribunal, with "no default winner". And the sovereign branch, even when justified, is "eligible, not authorised": "implementation blocked, new detached Founder act required". The programme's list of questions it must answer includes the one most projects never ask: "What useful adoption-zero product survives if the sovereign L1 thesis is rejected?" - and: "Which sealed tribunal calibration proves that a simpler deployment can win?"

The same humility governs its own governance: the Sovereign Change Core "must not become an eternal prerequisite that prevents the Living Node". Discipline is not allowed to become the reason nothing ships.

What the living node does not do

• It does not exist. Today's rung is the deterministic local kernel and a loopback-only, read-only door.
• It does not presume a network. The tribunal may dispose towards a verifier and an evidence toolkit, and the programme requires that outcome to be a real one.
• It selects no consensus algorithm; the problem is to be defined first.
• It authorises no validators, staking, issuance or fees.
• It claims no devnet, testnet or mainnet, by explicit instruction.

Verdict

The living node is where the doctrine will first meet a stranger: a socket with declared limits, a signed claim, a deterministic transition, a receipt, a read-only answer. The ladder above it is long and the programme refuses to skip a rung or to name one that does not exist. But the deepest fact in this direction is not the ladder; it is the tribunal at its foot, which can rule that the right deployment of FxChain is a verifier and an evidence toolkit rather than a chain, and which keeps the sovereign network "eligible, not authorised" until a Founder act separate from the plan says otherwise. A project that builds a gate its own thesis can fail is doing something different from selling a network.

Frequently asked questions

Is there a testnet?

No, and the programme instructs the roadmap to define the gates for private devnet, hostile devnet, public testnet and mainnet "without claiming any of them exist today". The roadmap page lists them as gates.

What is the first thing that will listen?

The living node: a bounded socket accepting signed intents and answering with receipts and read-only queries. It is planned as the first product rung, alongside the offline verifier.

Which consensus algorithm will FxChain use?

None has been chosen. The programme requires the consensus problem, and the safety, liveness, synchrony and adversary assumptions, to be defined explicitly before an algorithm family is selected, and the same kernel to run in a simulator under hostile schedules before validators exist.

Could FxChain end up not being a chain?

The programme allows it. The deployment-necessity tribunal has dispositions in which a simpler mode - offline verification and an evidence toolkit - is sufficient, and the common trunk must be useful in that case.

What exists today between the kernel and the network?

A loopback-only, read-only local-control transport with a state-authority firewall, through which the reconstruction family is answerable to a node-side caller. Mutation has no representation on it.

Sources and methodology

Drawn from the architecture programme's chapter on completing the blockchain architecture, its node ladder, common trunk and deployment-necessity tribunal, the reconstruction family's node-integration record, and the era and power map. Quotations are from those sources. Implementation claims are limited to the kernel and the transport the records describe; every rung above is design and carries the status planned, research or not claimed.

The programme is not published on this portal and is not reproduced here; the ladder and the dispositions are reported as shape. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier. Reference line: node ladder N0 to N7, common trunk P0 to P6, gate G1.

Related reading: The replay domain for the door that exists; The storage constitution for the durable rung; Roadmap for the gates as the portal states them; Developers for adoption zero.