Skip to content
Products

FxChain

A constitutional protocol for financial truth. The foundation of the Flowesome Network.

Read FxChain Foundations

FxChain

Implemented locally
Powered by FxChain
Truth vector

One claim, five facts

A claim that enters FxChain leaves five separate facts behind it, each with its own organ and its own evidence.

01
Received
FxWire accepts the message without granting it any authority.
02
Admitted, or refused
FxCore judges admissibility; a refusal is a typed result with a reason, not an error.
03
Ordered
FxDAG places the cell in its window; conflicts stay explicit instead of hiding in sequence.
04
Executed
FxVM runs deterministically and emits one receipt per cell: what was observed, not what was promised.
05
Sealed
FxBlock seals results and refusals together; on the local line, a block; in the direction, a capsule.
A design vector, not a service: it shows which facts this surface is built to keep apart. Its status is the claim scope below.
Claim scope

What is real, stated plainly

Proven today

  • Protocol foundations implemented and sealed on the development line
  • Deterministic conformance runs on every change
  • Constitutional documents: axiom, native laws, refused powers

In development

  • Public proof surfaces (this portal)
  • Developer-facing artifacts

Later gates

  • Developer preview: documentation and specifications
  • Staged deployments: devnet, then testnet, then mainnet

Not claimed

  • No live mainnet or public RPC
  • No validators, no token, no metrics
  • No production finality claims

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

The problem

Blockchains optimize for power first: throughput, expressiveness, compatibility. Trust is assumed to follow. It rarely does - users are asked to believe before anything is proven.

TradFi offers institutional discipline but opaque trust: you must believe the institution. DeFi offers verifiability but unbounded power: the code can do anything, including fail catastrophically.

The Flowesome answer

FxChain does not ask for trust - it exposes what can be proven. Its axiom: no power exists before its truth has been observed, sealed and audited in a non-authoritative form.

Every runtime authority is preceded by its powerless twin, and the network can prove, at all times, what it cannot do. It is not a stack of optimized blockchain organs - it is a constitutional machine that decides when a claim may become power.

Capabilities

What the foundations already do

Native laws

A constitutional layer every mechanism must satisfy before it is allowed to exist.

Claims judged before power

Transactions declare meaning first; an admissibility kernel and account constitutions judge them before anything executes.

Deterministic execution

Declared access, deterministic scheduling and observed-access receipts - the same inputs always produce the same truth.

Denials as artifacts

What the protocol refuses is sealed alongside what it commits. Refusals are provable, not implied.

Sealed history

Eras D0-D6 sealed byte-identical; later work adds witnesses, it never re-cuts what is sealed.

Conformance discipline

Deterministic conformance runs gate every change; the current run is green across all checks.

These capabilities are implemented and sealed on the development line, verified by deterministic conformance runs on every change. They are not deployed on any public network.
Place in the network

Where it sits, and why that matters

FxChain is the base of the Flowesome Network. Every product above it - wallets, markets, rails, tools - consumes the chain and inherits its discipline.

Nothing precedes the foundation: no product ships ahead of the capability it depends on, and no deployment happens before its gate.

Products

FxWalletFxTradeFxBankFxPayFxSentinelFxLabFxScan

Foundation

FxChain
Boundaries

Security and authority boundaries

What this product will not do, stated before what it will.

  • Sealed history is never re-cut - additions are witnesses, not rewrites.
  • No deployment activates before its gate is proven; dates are never the trigger.
  • Organ specifications become public with the developer preview, not as marketing.
  • Compatibility with prior art is reuse of known results - never identity.
Staged roadmap

Gates, not dates

  1. 01

    Protocol foundations

    Implemented locally

    Constitutional core, organs and sealed eras D0-D6.

  2. 02

    Persistence and storage constitution

    Implemented locally

    Durable state under the same discipline: additive witnesses, write-once genesis artifacts.

  3. 03

    Public proof surfaces

    In development

    This portal, statuses everywhere, factual changelog.

  4. 04

    Developer preview

    Planned

    Documentation, specifications and first artifacts for builders.

  5. 05

    Deployments

    Reserved

    Devnet, testnet, mainnet - each activates only when earned.

Talk to us about FxChain.

info@flowesome.com - we answer with what is provable today and what is staged for tomorrow.