Skip to content
Engineering updateFinancial continuity, from the foundations.
Flowesome
Network

From protocol foundations to coherent financial systems

Follow the engineering progression from sealed protocol foundations to integrated native capabilities and future financial services. Each stage connects its design, implementation scope and qualification.

Proven today, or practised on the lineIn development / qualifiedDirection: planned or researchLater gateNot claimed

Engineering progression · M1

Build the foundations. Connect the whole.

The engineering team’s in-depth design work brings a systemic perspective to M1: evidence, obligations, resources and explanations are considered together, across the complete lifecycle. The implementation mandate carries this thinking into code, actual callers and integrated verification, with received reliability increments as building blocks.

Implementation & integrationSystemic design
Reliability increments
Engineering progressionSource corrections and component preparation received.
Delivery disciplineBring the stronger caller checks, terminal evidence and independent comparison into the integrated implementation, preserving the evidence of each increment.
Systemic foundations
Engineering progressionSelected for complete M1 implementation.
Delivery disciplineUnite state, evidence and obligations with lifetime resource accounting and usable causal explanations wherever the actual M1 path requires them. Reuse complete work and connect the real callers.
Native integration
Engineering progressionDelivery objective: complete behaviour in context.
Delivery disciplineCompose genuine inputs, applicable authority, evidence custody and the full lifecycle of each operation into the native implementation.
End-to-end qualification
Engineering progressionDelivery objective: integrated verification.
Delivery disciplineVerify the financial scope and thirteen phases on the relevant native platform and receiver environment, with independent results, measured resources and terminal evidence.
M1 reception
Engineering progressionComplete acceptance criteria preserved.
Delivery disciplineBring the integrated results, their evidence and the required formal receptions together under the original milestone criteria.
This is the current implementation direction. Complete M1 qualification and reception are recorded through their own results. The established 28 September snapshot and 13 October local delivery remain separately documented below.
Explore the engineering

Closed on the record

The established foundations

News and closures

  1. Development line sealed through era D6

    eras D0-D6 · changelog of 16 July 2026

  2. Independent reconstruction closed

    merge d98d7364 · crossing Q-372

  3. Sovereign Assurance & Attestation closed

    dev 11c96351 · runs 36392880837 and 36399021626

Delivered locally

First native capabilities delivered locally

Continuity after interruption, consent leading to completed work, qualified calculation with staged synthetic settlement, and their composition have been implemented and exercised in defined local profiles. They are a new delivery alongside the established foundations, with their own evidence and acceptance conditions.

Implemented locallyFormal acceptance pending

Human observation

Observe the delivered behaviours in the local profiles and record what was actually seen.

Formal acceptance

Complete the distinct reception acts; a local qualification is not the acceptance act itself.

Publication and integration

Proceed under the applicable source-publication and integration conditions. No public release is claimed here.

Further bounded local work may proceed in parallel when its own conditions are met.

Explore native capabilities Read the delivery account

The direction is native work: execution, resources, calculation and composition, supported by evidence.

The architectural reference and the implementation plan describe different layers of the programme. The directions below preserve their own gates. A delivered local profile does not by itself deliver a general virtual machine, a durable node or a public deployment.
01 · The eras

Seven sealed eras, one narrow power each

Each era admitted one power and listed the powers it still denies. The right-hand column is the doctrine.

  1. D0

    Denial and framing

    Sealed

    Power admitted: Stable framing, explicit negative boundaries, offline facts.

    Not granted by this historical act Runtime, network, consensus, finality, ambient mutation.

  2. D1

    Foundations

    Sealed

    Power admitted: Versioned structural foundations later eras may reference.

    Not granted by this historical act Computation, transfer and persistence authority.

  3. D2

    First computation

    Sealed

    Power admitted: One bounded computation lineage: first computed result, verified root.

    Not granted by this historical act A standing compute right, value movement, persistence.

  4. D3

    Continuity

    Sealed

    Power admitted: New artifacts carry frozen bytes and meanings forward.

    Not granted by this historical act Mutation of D2 bytes, standing authority.

  5. D4

    First bounded authority

    Sealed

    Power admitted: A named, counted authority represented and exhausted inside its crossing.

    Not granted by this historical act Ambient authority, delegation by implication.

  6. D5

    First bounded motion

    Sealed

    Power admitted: One offline movement authorised, applied, receipted and sealed.

    Not granted by this historical act A standing right to move, networking, admission.

  7. D6

    First bounded persistence

    Sealed

    Power admitted: Exactly one preserved artifact, the genesis snapshot, verified against its anchor.

    Not granted by this historical act A second artifact, truth from storage, disk authority.

Persistence era · First movement

Genesis snapshot preservation

Sealed and byte-frozen.

Implemented locally

Persistence era · Second movement

Storage architecture

Closed conceptually under the ratified storage constitution; not implemented, no engine selected.

Research

Persistence era · Third movement

Independent reconstruction

Twelve crossings, closed on 2026-08-02: boundary, taxonomy, grammar, oracle, engine, tribunal, read-only door, closure on an honest witness. Its assurance act closed on 2026-09-28.

Implemented locally

Persistence era · Fourth movement

Not opened

The recorded foundations baseline admits no fourth movement; this historical closure is not a census of later native work.

Reserved
Sealed means bytes frozen and powers fixed. Work continues inside a sealed era by additive movements, each a crossing; none reopens a seal. Read Sealed history.
02 · The node ladder

From the local kernel towards a deployed node

An architectural direction, read separately from the delivered local native profiles. Only the first rung of this deployment ladder is established; later rungs keep their research and opening conditions.

  1. N0

    Deterministic local kernel

    Implemented locally

    The foundational local profile: eight components, sealing, one preserved artifact and two-path reconstruction. Native owners have their own later profiles.

    Gate Sealed on the development line; the rung every later one builds on.

  2. N1

    Living node

    Planned

    Bounded socket, signed intent, transition, receipt, read-only query: the smallest thing that can be asked and answer with evidence.

    Gate Target integrated node rung, beyond the documented loopback local-control transport. Public verification and node integration retain separate qualification.

  3. N2

    Durable node

    Planned

    Target integrated durable node: journal, checkpoint, crash and restart, reconstruction to an expected root and head, or a typed refusal. This is broader than recovery exercised for individual local native owners.

    Gate Governed by the storage constitution; recovery is judged by outcome, never by reopening a file.

  4. N3

    Consensus simulator

    Research

    The same kernel under hostile schedules: partitions, equivocation, reordering, delay, crash and recovery, as frozen transcripts.

    Gate The consensus problem is defined before any algorithm family is selected.

  5. N4

    Private three-node devnet

    Research

    Real processes, convergence, restart, resync.

    Gate Requires matching expected roots across the declared hostile schedule corpus, with the remaining fault assumptions explicit.

  6. N5

    Hostile devnet

    Research

    Partitions, equivocation, churn, corruption, data-availability failure.

    Gate Adversarial evidence sealed before any public surface.

  7. N6

    Public testnet candidate

    Not claimed

    Release, operations, economics, external reproduction.

    Gate Not claimed. The deployment tribunal decides whether a network is warranted at all.

  8. N7

    Mainnet candidate

    Not claimed

    Security, legal, economic, governance and operational gates.

    Gate Not claimed. A sovereign chain stays eligible, not authorised, until a separate Founder act.

03 · The common trunk

Shared foundations for staged implementation

The architectural reference's common trunk remains a reading of the target dependencies. The local native delivery above carries its own qualification and does not close every stage in this trunk.

  1. P0

    Architecture direction and implementation plan

    In development

    Architecture & Protocol Programme: the V1.2-RC3 architectural reference and the RC3 V1.1 implementation plan organise distinct stages of the work.

    Gate Implementation activity is under way; the wider target architecture remains research and each capability keeps its own scope.

  2. P1

    Capability graph and public truth release

    In development

    The current capability graph, a closed concept registry, and the public truth release this portal carries.

    Gate Twenty-one dossiers, Foundations, a dated evidence snapshot; the papers follow as sealed editions.

  3. P2

    Canonical grammar and determinism closure

    Planned

    Codec, transcript, cryptographic suite, protocol time, units, precision, rounding, compatibility.

    Gate Frozen as conformance families before anything above it.

  4. P3

    Authority, duty, denial and effect kernel

    Planned

    Authority as a typed effect set, duty delta, denial objects, accounting, resource and consequence bounds, conflict isolation.

    Gate Every object with a concept contract and its falsifiers.

  5. P4

    Living node, minimum wallet and offline verifier

    Planned

    The first rung that answers a stranger, and the first artefact a stranger can run: adoption zero.

    Gate A target dependency in the architecture reference. The assurance closure alone neither implements nor activates the node, wallet or public verifier.

  6. P5

    Durable node and exit drill

    Planned

    Authenticated state, journal, crash recovery, and the proof that the engine can be left.

    Gate Truth gates before performance; the storage constitution governs.

  7. P6

    Hostile laboratory and no-migration pilot

    Planned

    Two reconstruction engines, a pilot capsule, rail adapters, delivery ambiguity, and a pilot that requires no migration.

    Gate Useful even if a sovereign chain is never deployed.

04 · The deployment tribunal

A gate that can rule against a network

After the trunk, a tribunal decides whether a sovereign network is warranted. Five dispositions, and the sovereign chain is only one of them.

1

Evidence unestablished

Close evidence gaps only; no deployment branch selected.

2

Simpler mode sufficient

Adoption zero and one: verifier and evidence toolkit; no network implied.

3

Hybrid mode preferred

Supervisory deployment and a shared evidence service.

4

No single mode dominates

Bounded pilots, each with an effect ceiling, a budget and a re-tribunal trigger; no default winner.

5

Sovereign chain justified

Eligible, not authorised: implementation stays blocked until a new, detached Founder act.

No disposition has been reached. The tribunal is design (research); nothing on this page presumes a network.
05 · The adoption ladder

What an outsider can hold, rung by rung

The first rung is an artefact, not a network: a verifier that runs with no chain, no token and no migration.

  1. 0

    Adoption zero: verify offline

    Planned

    A command-line and browser verifier for a sealed history, its receipts and commitments, on your machine, against declared rules and expected reference commitments.

    Gate Planned public verification route; the portal links explanatory notes today. A usable release requires its own package, instructions and reproduction evidence.

  2. 1

    Evidence SDK and reconciliation

    Research

    A no-migration institutional evidence toolkit, adapters and reconciliation-grade receipts.

    Gate After adoption zero proves that an outsider can verify.

  3. 2

    Private supervisory nodes

    Research

    Institutional and supervisory nodes with shared settlement workflows.

    Gate Only under a hybrid disposition of the tribunal.

  4. 3

    Sovereign execution

    Not claimed

    FxChain execution as a network, only where measured necessity is established.

    Gate Not claimed.

06 · The programmes

Govern, prove, operate: where each programme stands

Sovereign Assurance & Attestation (SAA)

Makes verifiable the identity of a software version, the controls applied to it and the evidence behind its qualification. Closed on 28 September 2026: qualified locally, reviewed separately, integrated, and green on two hosted runs.

Implemented locallyRead more

Mission Control (MC)

Governed operations and evidence custody: measured review isolation, custody of what a review examined, rule-based admission.

Implemented locallyRead more

Sovereign Change Core (SCC)

The compact typed core that compresses the change-governance work practised today. Not started; cannot authorise its own birth.

PlannedRead more

Architecture & Protocol Programme (APP)

Implementation proceeds under RC3 V1.1, with the first native profiles delivered locally. Wider architecture direction remains research; SCC remains planned. Architectural and implementation document editions are distinct.

In developmentRead more
07 · The products

Every surface follows the chain, behind its own gates

These are application directions and their capability dependencies. Presentation order does not ratify a release sequence or launch date; each integration and product needs its own qualification.

SurfaceGate 1Gate 2Gate 3Gate 4
FxChainProtocol foundationsImplemented locallyPublic proof surfacesIn developmentDeveloper previewPlannedDeploymentsReserved
FxWalletDesignPlannedPrototype on devnetReservedPublic releaseReserved-
FxTradeMarket designPlannedDevnet marketsReservedPublic marketsReserved-
FxPayPayment designPlannedDevnet flowsReservedLive paymentsReserved-
FxBankResearchResearchSandbox with aliasesPlannedRegulated partnersReservedOwn permissionsReserved

FxPay design vision

Planned

Payment continuity, designed from the foundations

The team’s research approaches payments at their roots: which useful, already-authorised action can the evidence support, within explicit financial exposure limits? Capacity for lasting duties and reusable evidence complete this design direction, with the aim of making continuity a property of the system itself.

Systemic design
Design progressionDesign direction reviewed.
Engineering objectiveConnect useful authorised action, explicit financial exposure, capacity for lasting duties and reusable evidence in one design. Challenge it against counterexamples and competent existing procedures.
Safety and useful progress
Design progressionEvaluation framework defined.
Engineering objectiveEvaluate justified actions, exposure, operational continuity and full lifecycle cost together, with equivalent evidence and independent expected results.
Provider integration
Design progressionA planned product stage.
Engineering objectiveTranslate the design into a particular integration through its applicable rules, permissions, evidence and control, then implement and qualify it.
Service delivery
Design progressionFxPay remains planned.
Engineering objectiveBring product implementation, operations, regulatory requirements and release qualification together for the intended merchant service.

This reviewed design direction informs the planned FxPay product. Implementation results, provider integrations and service availability follow their own qualification stages; the necessary M1 foundations belong to the current M1 implementation mandate.

Explore FxPay Explore the design vision
08 · The papers and this portal

Public proof surfaces

White Paper 1.8 and Yellow Paper 1

Maintained internally; the dossiers are their public reading.

Research

Edition 1.9

Both papers realigned on the architecture programme, now that the assurance programme has closed; digests published.

Planned

Edition 2.0

Sealed at the closure of the architecture programme; digests published; the White Paper considered for publication.

Planned
This portal is itself a public proof surface, in development: twenty-one dossiers, Foundations, a dated evidence snapshot and a changelog. What exists today is stated in one screen.
09 · Not on this roadmap

What you will not find here

  • A calendar. A date is a claim about the future the evidence cannot support.
  • A token, a sale or an investment product.
  • A devnet, testnet or mainnet announced as existing.
  • A licence, a regulated service or a partner logo.
  • A rung skipped: each opens only when its gate is proven.
  • A number outside the dated evidence snapshot.

Follow the gates as they are earned

The changelog records every closure factually, the day it lands on the line.

ChangelogWhat exists today