FxChain
The native protocol of Flowesome, designed to connect financial actions to explicit authority, bounded effects and inspectable evidence.
For builders, operations teams and institutions evaluating how actions and recovery decisions can remain controlled.
FxChain
The problem it is built for
The problem
An authorized request, its execution and an external financial effect are different facts. An absent response does not establish failure.
Access controls, approvals, idempotency, logs and reconciliation already address parts of this problem. Composing them across systems and interruptions requires explicit authority, evidence and continuing obligations.
The Flowesome answer
FxChain is designed to make these boundaries explicit: what may be done, what was observed, what remains unresolved and what permits a next action.
Proof before power is the project signature. Its practical aim is a controlled action and an explainable recovery decision; each implemented profile must establish its own properties and limits.
A target pipeline with separate responsibilities
This explains the target architecture. It is not a trace of a live transaction or a claim that all target behaviors are implemented.
- 1FxWire and FxIntent
- Receive an external message and describe the requested action and constraints.
- 2FxCore and FxCell
- Apply the relevant rules and form the internal causal execution unit.
- 3FxDAG
- Order FxCell objects under the defined causality and execution profile.
- 4FxVM and FxState
- Execute the ordered units and commit the supported state transitions.
- 5FxBlock
- Package verifiable block results; production finality requires future work.
Local foundations and their published scope
Canonical protocol objects
Local objects and deterministic construction rules provide a defined basis for inspection and conformance checks.
Bounded admission
The historical offline admission profile has a three-verdict grammar and admits no transaction. Broader account and authority designs remain separately scoped.
Deterministic local ordering
Defined inputs and ordering rules give a repeatable local result. This does not establish distributed consensus or an external financial fact.
Receipts and typed boundaries
Local validation and refusal boundaries have defined scope. Complete portable denial and capsule designs must be distinguished from those implemented profiles.
Historical sealed artifacts
The dated foundation record preserves the D0-D6 history. Hash integrity is distinct from completeness, freshness or external economic truth.
Native capability profiles
A separate local delivery describes continuity, consent, numerical execution and composition, with human observation, formal acceptance and source publication still distinct.
Where it sits, and why that matters
Flowesome builds the applications and integrations; FxChain provides their native protocol foundation. Each application and connector needs its own evidence rather than inheriting qualification automatically.
Adoption can involve local evaluation, integration with existing systems, a hybrid approach or a future native network. Their suitability and availability depend on the actual profile and adopted decisions.
Products
Foundation
FxChainWhat is real, stated plainly
Proven today
- Public architecture dossiers and scoped capability notes
- Published summaries of historical local engineering results
In development
- Public explanatory and evaluation paths
- The separately mandated native implementation, integration and verification work described in current updates
Later gates
- Developer-facing executable artifacts where separately authorized
- Integration and deployment profiles subject to their own prerequisites
Not claimed
- A live public network or production consensus
- A public financial service or supported product integration
- Automatic legal effect, external delivery or production readiness
Proven today, or practised on the lineIn development / qualifiedDirection: planned or researchLater gateNot claimed
Security and authority boundaries
Conditions and responsibilities that must hold for the applicable product or protocol profile.
- A repeatable local result does not establish the truth of an external provider event.
- Restored data alone does not establish the right to resume emission.
- A public explanation of a private implementation is not public source or independently reproduced evidence.
- The native roadmap, releases and deployments retain their own authorization and acceptance criteria.
Gates, not dates
- 01
Local protocol foundations
Implemented locallyHistorical canonical objects, deterministic profiles and sealed D0-D6 records, within their documented limits.
- 02
Bounded local continuity
Implemented locallyThe 13 October native delivery has separate local profiles; it does not establish general database persistence or production recovery.
- 03
Public evaluation material
In developmentArchitecture, status notes and usable reading paths on this portal.
- 04
Executable evaluation artifacts
PlannedTheir publication and quickstarts require their own confirmed release scope.
- 05
Network deployments
ReservedA future deployment requires the applicable technical, operational and authorization prerequisites.
Discuss a workflow about FxChain.
info@flowesome.com - we answer with what is provable today and what is staged for tomorrow.