Skip to content
Products

FxTrade

Markets and trading infrastructure for the ecosystem.

FxTrade

Planned
Powered by FxChain
Product blueprint

A market surface where every fill has a proof trail

FxTrade is the planned market layer for orders, sealed windows, execution receipts and institutional audit. It turns trading into a sequence the protocol can explain.

Typical flow

  1. 1A participant submits an order intent with explicit constraints.
  2. 2FxCore checks admissibility and account authority before market execution.
  3. 3FxDAG places admitted orders into deterministic windows and surfaces conflicts.
  4. 4Execution produces receipts for fills, misses and refused paths.
  5. 5The product displays the trade as evidence-backed settlement material.

Order intent

Orders are represented as constrained claims: side, size, price logic, expiry, venue rules and admissibility requirements.

Sealed windows

Execution windows are designed to reduce extraction by hiding exploitable ordering until the window boundary is earned.

Provable fills

Fills carry evidence about what matched, what conflicted and which ordering window produced the result.

Audit export

Desk and compliance surfaces can consume receipts instead of screenshots or operator-only database records.

Truth vector

An order is five facts, not a fill

FxTrade is designed so that ordering, filling and settling are never compressed into one line on a screen.

01
Declared
An order is an intent with constraints and expiry; it enters powerless.
02
Ordered in its window
Cells that commute run together; conflicting orders form an explicit set with a deterministic rank.
03
Filled
A receipt of what execution observed, never a promise of what will settle.
04
Settled on the protocol
Executed and finalised remain two facts, on the plane the order declared.
05
Delivered on a rail
A custodian or bank delivering is an external claim, bound by reconciliation, never assumed.
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

  • Nothing - no exchange, no order book, no listings

In development

  • Nothing yet - market design is staged behind chain deployments

Later gates

  • Market design over FxChain ordering semantics
  • Institutional access surfaces

Not claimed

  • No trading service of any kind today
  • No volume, no pairs, no market data
  • No regulatory authorization - and none implied

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

The problem

Market infrastructure runs on opaque matching: you cannot prove your order was treated fairly, and extraction (front-running, reordering) is ambient.

Fills are records in someone’s database. Disputes reduce to trust in the operator.

The Flowesome answer

FxTrade is designed above a foundation where ordering windows are order-invariant, conflicts are economic objects and every fill is provable.

Sealed claim windows are designed to resist extraction structurally - with non-extraction certificates rather than promises - and a forced-inclusion lane keeps intermediaries optional.

Capabilities

Designed capabilities - nothing here is shipped

Provable fills

Every fill carries evidence: what matched, under which window, against which claims.

Sealed windows

Claims sealed until window boundaries - extraction resisted by structure, certified rather than promised.

Optional intermediaries

A forced-inclusion lane so solvers and routers remain conveniences, never gatekeepers.

Institutional surfaces

Market access designed for desks that need audit trails, not screenshots.

FxTrade is a staged design. No exchange operates, no order book exists, nothing is listed and no volume exists. This page describes intent, bounded by the claim scope above.
Place in the network

Where it sits, and why that matters

FxTrade is the market layer of the network, built strictly above FxChain ordering and settlement.

It composes with FxWallet for user access and with FxBank where regulated rails meet market flows.

Products

FxWalletFxTradeFxBankFxPayFxSentinelFxLabFxScan

Foundation

FxChain
Boundaries

Security and authority boundaries

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

  • No trading service launches before its regulatory posture is explicit and public.
  • Markets follow chain deployments; they never run on trust in an operator.
  • Market data published one day will be provable data - or not published.
Staged roadmap

Gates, not dates

  1. 01

    Market design

    Planned

    Trading semantics over provable ordering and fills.

  2. 02

    Devnet markets

    Reserved

    Experimental markets on a running deployment.

  3. 03

    Public markets

    Reserved

    Only behind explicit regulatory boundaries.

Talk to us about FxTrade.

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