Skip to content
Engineering updateFinancial continuity, from the foundations.
Flowesome
FxChain · Programmes

How the protocol work is organised

Architecture connects native capabilities; assurance records what was examined; governed operations preserves the evidence of an act. These complementary programmes support the FxChain blockchain protocol, with separate delivery and acceptance boundaries.

Programme names and scoped statusesHistorical references preserved
01 · The vision

Govern. Prove. Operate.

A summary of the vision, not an inventory of delivered products. For a non-technical reader: change governance, verifiable assurance and controlled operations.

From verifiable foundations to native capabilities that accomplish work.

FxChain now has defined local profiles for continuity, consent, qualified calculation and their composition. Assurance and governed operations support this development; each organisation keeps its own decision authority.

01 · Govern

Sovereign Change Core (SCC)

Who may change what, and under which conditions.

Planned

02 · Prove

Sovereign Assurance & Attestation (SAA)

What was verified, on which version, under which rules and with which evidence.

Implemented locally

03 · Operate

Mission Control (MC)

How an operation ran, and what is kept so that it can be verified.

Implemented locally

Implemented locally · 13 October 2026

The 13 October native delivery has its own scope

Commitments continue after tested interruptions. Consent and function are checked together in the qualified cases; absent prerequisites remain recorded as conditional outcomes. A qualified numerical application produces results and settles its stages in a synthetic local model. A separately qualified composition brings these behaviours together.

Explore native capabilities

Formal acceptance pending

The delivered profiles are local and bounded. Human observation, formal acceptance and source publication remain open. The wider architecture keeps its own research and implementation gates.

Read the delivery account
02 · The programmes

What each programme does, and what its name must not be taken to mean

Two readings of the same work: an institutional one, in plain words, and a technical one that keeps every internal reference identifiable in its archives.

Programme 01 · Prove

Sovereign Assurance & Attestation (SAA)

Assurance and attestation of software versions, their controls and their evidence

Implemented locally

The assurance and attestation programme, born from the internal acceptance arc, binds a software version to its controls, its evidence and the conditions of its qualification; it closed on the development line on 28 September 2026. Its envisaged product evolution keeps the admission decision in the hands of each organisation.

SAA aims to make verifiable the identity of a software version, the controls applied to it and the evidence that supports its qualification.

SAA establishes the evidence; the operator keeps the decision.

Assurance
technical confidence supported by controls and evidence
Attestation
a statement attributed to an issuer about a precise subject and policy
Sovereign
the organisation keeps control of its trust policy and of its admission decision

Closed · 28 September 2026

Closed on the line: the closing commit was qualified locally, reviewed by a separate reviewer, integrated, and passed every hosted check before and after integration. Earlier failures stay on the record.

Read the closure

What the name does not mean

  • Not a state certification, an absolute guarantee or a universal authorisation to deploy.
  • Attestation and the capability to deploy remain distinct: a passport attests a result; the client or the node decides admission locally.
  • The public name is proposed for the future capability; in the archives the reference keeps its historical meaning.

Internal reference

Q372-SAA (historically "Successor Admission Amendment")

The acceptance discipline

Programme 02 · Operate

Mission Control (MC)

Governed Operations & Evidence Custody

Implemented locally

The Mission Control programme covers governed execution, the tracking of transitions and the verifiable custody of operational evidence. It aims to make responsibilities and outcomes explicit, without confusing observation, authority and action.

What matters is the scope of an operation, its steps, its responsibilities, its outcomes and the evidence that is kept.

The internal Mission Control lab retains operational steps and evidence for examination within the recorded scope.

Governed operations
an operation runs inside a declared scope, with named responsibilities and recorded steps
Evidence custody
the material that allows the operation to be verified is preserved, not merely logged

What the name does not mean

  • Not the user cockpit. FxDesk remains the chartered candidate for a human operational cockpit; Mission Control is the programme and its mechanisms.
  • No two competing cockpits, and no integration presented as already done.
  • An internal lab today; not a hosted service and not a product.

Internal reference

Q372-MC; a valid historical programme name in custody records

Cold rooms and evidence admission

Programme 03 · Architect & implement

Architecture & Protocol Programme (APP)

Target Architecture, Interoperability & Implementation Roadmap

In development

The architecture and protocol programme organises FxChain's target architecture and its staged implementation. The architectural reference V1.2-RC3 and the implementation plan RC3 V1.1 are distinct documents. The programme now includes locally implemented native profiles, while its wider architectural directions remain research or planned capabilities.

Within it, the envisaged governance capability is the Sovereign Change Core (SCC): a small core of typed authority, subject, obligation, observation, gate, witness, verdict and transition-receipt objects - who may change what, and under which conditions. Its antecedents are practised today as the acceptance discipline; the core itself has not been started, and by its own genesis law it cannot authorise its own birth.

This programme defines how the capabilities of FxChain must fit together, and in which stages they may be implemented and validated.

Target architecture
the shape the capabilities must take - shared kernel, planes and typed contracts - stated as laws before any code
Roadmap
ordered stages, each with its own validation, none activated by the plan alone
Sovereign Change Core (SCC)
Its antecedents - the acceptance discipline and the evidence lab - are practised today; the compact typed core that compresses them is planned, not built

Two dimensions of progress

In developmentImplementation activity
ResearchWider architecture direction

The first native profiles are implemented locally. SCC remains planned; the programme's status does not upgrade its individual capabilities.

What the name does not mean

  • "RC3" is a version reference of an internal document, not "FxChain Release 3", and no third operational network is delivered.
  • A plan alone delivers no capability: the implemented local profiles have their own qualification evidence and boundaries.
  • The local native delivery does not mean that SCC, a general virtual machine or a public network has been delivered.
  • The public explanations name target objects. They are not a released normative SDK schema or an executable integration guide.

Internal reference

Architecture: V1.2-RC3; implementation: RC3 V1.1

FxChain Foundations
03 · Names and references

Public names explain function; internal references keep history

Harmonising is not renaming the repository. Identifiers stay in archives, reports and manifests; the public names serve to explain what each programme does, with this explicit correspondence.

Public nameInstitutional descriptorInternal referenceStatus
Sovereign Assurance & Attestation (SAA)Assurance and attestation of software versions, controls and evidenceQ372-SAAImplemented locally
Mission Control (MC)Governed Operations & Evidence CustodyQ372-MCImplemented locally
Architecture & Protocol ProgrammeTarget Architecture, Interoperability & Implementation RoadmapV1.2-RC3; implementation RC3 V1.1In development
APP architecture directionWider target architecture and interoperabilityV1.2-RC3Research
Sovereign Change Core (SCC)Envisaged change-governance capabilityV1.2-RC3, change planePlanned
FxDeskChartered professional terminal; candidate human operational cockpitNaming charter (RFC-0001)Reserved
04 · Boundaries

What this page does not claim

  • Three programmes are not three commercial products; none is available as a service.
  • The public names are proposed presentation names. Under the architecture programme's own rule, a public successor name remains a candidate until the naming charter is changed by a separate authorised act.
  • Internal identifiers keep their historical meaning in archives, reports and manifests; this page does not rename them.
  • No state certification, no absolute guarantee, no universal authorisation to deploy, no third operational network.

Read the discipline behind SAA and MC

The acceptance discipline dossier explains, at the level of method, how a change earns its place on the sealed line - and what that does not establish.

The acceptance disciplineFxChain Foundations