FAQ

Flowesome is the project building financial applications, tools and integrations around FxChain, its native blockchain protocol. The four main application directions are FxWallet, FxTrade, FxPay and FxBank: a wallet, trading platform, payments platform and programmable banking platform under research. Their dedicated pages describe complete products, their intended use and their current availability. This presentation order is not a ratified launch calendar. Proof before power remains the shared principle.

FxChain is a native, non-EVM blockchain protocol under development. Its target architecture connects explicit authority, bounded effects and inspectable evidence: who may act, which consequences are allowed and what remains observable after an interruption. Eight components share the intended path from FxWire through FxIntent, FxCore, FxCell, FxDAG, FxVM and FxState to FxBlock. The Technology page separates these target responsibilities from the foundational local observations; native execution profiles have their own qualification and pending acceptance.

A claimed capability needs evidence for its precise subject and scope before broader authority or availability is inferred. The local development record uses bounded acts, stated exclusions and acceptance records; sealed subjects retain their original bytes and corrections are additive. On the portal, an implementation, a design, a published explanation and an operated service have separate statuses. A successful local check does not by itself activate a financial product or qualify its integrations.

Local implementation and a public distributed network are different milestones. The dated foundations include preservation and reconstruction through separate implementations. The 13 October 2026 native delivery also reports service, numerical and common-activation profiles, with synthetic payments and bounded interruption cases; formal acceptance remains pending. Those results do not establish public validators, distributed consensus, production finality or an operated financial service. Node and deployment stages retain their own dependencies and qualification.

The 28 September 2026 foundations snapshot records seven sealed eras, 372 accepted crossings and 50 of 50 hosted jobs on two recorded runs of the assurance closing commit, dev 11c96351. These are historical figures for that source, not standing CI status. The 13 October local native delivery has a different subject and formal acceptance remains pending. The 21 October engineering update describes systemic design and an M1 integration objective. The What exists page separates their availability, checks and public reading links.

The figures describe a dated source snapshot, rather than a live counter or a measure of product availability. The shared evidence reference is 28 September 2026, dev 11c96351: seven sealed eras, 372 accepted crossings and 50 of 50 hosted jobs on each of two recorded assurance runs. The What exists index and Foundations reading path retain that context. The 13 October local delivery and 21 October design work do not silently update those historical counts.

The published records describe internal acceptance, hostile checks and reviews with separated project roles. At the 28 September 2026 assurance closure, the recorded source passed the stated local checks and two hosted runs. Reconstruction through separate implementations can expose differences, but shared assumptions or development conditions can remain. These records do not establish an external professional security audit, public reproduction by an outsider or the status of every later commit. Read the relevant scope note for the subject and method.

The protocol repository as it advances: by named crossings, with eras whose bytes are frozen once sealed. A later era may carry meaning forward through a new artifact; it never rewrites what an earlier era sealed. The Sealed history dossier explains the constitutional rule, the anatomy of a crossing and the era map.

They are four main Flowesome application directions, powered by FxChain. FxWallet is the planned wallet and personal financial application for accounts, assets, readable actions and authorisations. FxTrade is the planned trading platform for orders, execution and settlement. FxPay is the planned payments platform and merchant services, including payment journeys, receipts, refunds, disputes, reconciliation and continuity. FxBank is the programmable banking platform under research, with a long-term neobank ambition and separate partner and licensing requirements. No live financial service is offered. This order presents the range, rather than ratifying a release schedule.

The portal does not offer a live FxWallet, FxTrade, FxPay or FxBank financial service. You can read their dedicated product pages and the evidence for the local protocol profiles they may consume. A product needs its own integrated behaviour, usable access, operational responsibilities and any applicable partners or permissions. Protocol qualification does not automatically qualify a product or its connectors. The status index and roadmap distinguish those steps without promising launch dates.

No. There is no token, no sale and no investment product of any kind associated with the Flowesome Network. Economic-security research exists in the architecture programme as research, authorising nothing.

It is a way to keep distinct facts visible, rather than compressing them into one status. The payment-evidence example has six facts: Signed, Executed, Finalised, Delivered on the external rail, Legally effective and Economically complete. A technical signature alone does not establish legal consent. The historical settlement model describes the five downstream facts after Signed. These facts are not automatic sequential stages, and are separate from the six-axis project assessment and the scope of an engineering proof. Unknown is not false or safe.

FxChain explores a shared native grammar connecting authority, bounded effects, evidence, refusals and unresolved obligations across systems. Existing ledgers, payment rails and operating procedures already provide controls such as approvals, idempotence, logs and reconciliation. A useful comparison must define one workflow, the same inputs and failure cases, and a competent conventional baseline. The Institutions page distinguishes local mechanisms from research and unqualified institutional integration; it does not establish universal superiority or complete coverage.

The rule that executed, finalised, delivered on an external rail, legally effective and economically complete are five different facts, that missing evidence is recorded as missing rather than as false, and that an instrument error is not a domain failure. A capsule seals what the protocol established and never claims what only a rail, a court or a counterparty can. The Receipts, denials and capsules dossier develops it.

The public route today is a bounded design and evaluation conversation; this does not announce an active pilot or available hosted service. Bring one workflow and one failure case. Agree which decisions should be justified, which outcomes remain unresolved and how to compare false refusals, manual work, integration cost, added risk and evidence quality with your existing procedure. Exposure and duration should be measured only where the available inputs support them. Any pilot needs its own scope, responsibilities and access.

Describe one workflow, its authority constraints, the evidence you can observe and a failure that makes recovery difficult. Include relevant types of systems or counterparties without sending customer records, credentials, private keys or confidential documents. Use the technical evaluation route on the Contact page or info@flowesome.com. The first discussion can identify a bounded comparison and its evidence requirements; it does not grant an integration, licence or launch commitment.

The portal does not offer a released public SDK, deployed RPC endpoint or public testnet. It does publish explanatory documentation: the dossiers, Technology, native-capability pages and Foundations scope notes. The Developers page is an evaluation path today. A usable public execution tool would need an identified version, an accessible package, instructions and a clear statement of what has actually been reproduced; a download alone would not prove reproducibility.

Adoption zero is the planned offline verification route in the architecture programme: a command-line and browser tool for examining a sealed history, receipts, portable denials and committed verdict inputs against declared rules and expected reference commitments. Its purpose is to let a reader perform a check on their own machine. The portal currently provides explanatory notes rather than a released verifier package or installation command. The artifact, verifier implementation and trusted starting commitments each have their own assumptions.

Check the Developers page, the What exists status index and the dated changelog for the access and scope actually available. A published design or news date does not establish an executed release or a received implementation. The Contact page is available for a bounded evaluation enquiry. The roadmap states evidence gates; a future planning estimate would need an explicit basis, assumptions and status, rather than being presented as a guaranteed delivery date.

You can inspect the published explanations, claim tables, dated source references, methods and limits, and challenge their internal consistency. The public comparison and finance-operations illustrations use synthetic data and do not execute the FxChain core. The scope notes describe reported private checks; reading them is not independently reproducing those checks. A public reproduction would require the relevant source or verifier, inputs, declared rules and expected commitments, with its own recorded result.

Long-form, dated technical documents in four series: the eight protocol organs, the engineering discipline (acceptance, the evidence lab, sealed history, the replay domain), the direction (planes, evidence objects, the storage constitution, six axes, authority, the living node, the evidence algebra, privacy) and a glossary. Each opens with a short answer and a claim table, draws its mechanism in figures, states what it does not establish, and ends with its sources.

Read each claim together with its subject, date, basis and limit. Implemented locally describes an examined local scope, rather than a deployed service. In development describes ongoing work; research and planned identify different kinds of future work, not universal grades on one maturity scale. Reserved identifies a named future direction. Qualified retains an explicit restriction, such as a synthetic comparison case. Not evaluated is neither passed nor failed; not applicable needs a reason for that profile.

Not yet. Both are maintained internally and will be sealed as editions aligned with the architecture programme, with their digests published when they are; the dossiers are their public reading in the meantime. Object names and the shape of the design are reported; grammars, fields and parameters are not.

A target architecture can be substantial without all of its capabilities being implemented or available. The project assessment separates technical maturity, deployment, decisions, truth class, knowledge state and assurance rather than collapsing them into a single score. Those axes are distinct from a payment-evidence vector or the scope dimensions of a proof. Local implementation, its integration, formal acceptance, public reproduction and service operation each need evidence appropriate to that step.

Flowesome is the project presented through this portal: work on the native FxChain blockchain protocol, application directions and integration tools. The public evidence notes identify dated subjects, methods and limits; they do not substitute for information about a contracting party or its responsibilities. Use the About and Contact pages, or info@flowesome.com, to discuss the relevant people, scope and responsibilities for a specific evaluation.

info@flowesome.com, or the Contact page, which routes technical evaluations, institutional conversations and builder interest. Replies state what is provable today and what is staged; an enquiry grants no licence, endpoint or delivery date.

There is no token, no public sale and no investment product, and nothing on this portal is an offer. Investment enquiries from institutions or individuals are considered case by case, in writing: info@flowesome.com. The reply states what the record supports today and what is staged; it grants nothing by itself.

A bounded unit of advance in the sealed development record, with a named predecessor, an objective, the powers it does not grant and an acceptance record. Its scope and source matter more than the count. The What exists index retains the dated census, while the Sealed history dossier explains the anatomy. A crossing count is not a throughput measure, a product release count or evidence of production readiness.

A gate identifies the evidence and decision needed before a capability may advance. The roadmap prioritises these dependencies and does not commit to launch dates. Planning estimates can still be useful when their basis, assumptions, uncertainty and status are stated; an estimate is not acceptance or a release guarantee. A past news date also does not, by itself, prove the execution or qualification date of the result it describes.

Record the affected subject, evidence and limits; reproduce the failure where possible, then qualify a correction through its applicable checks. The reconstruction closure documented a witness that had checked a schedule declaration rather than actual scheduled execution, and retained that correction in the record. A defect discovered after sealing requires an additive correction, rather than rewriting frozen history. Historical verdicts and a later superseding claim remain separate facts.

M1 brings the current native engineering work into one integrated milestone. The team has deepened its foundations through design work on states, evidence, obligations, resource lifetimes and clear explanations, alongside received reliability corrections. The implementation mandate requires complete code connected to actual callers and verified together. Full qualification and formal reception complete that delivery path.

The team works on the relationships at the roots of the system: how facts support an action, which obligations survive it, what resources their full lifetimes require and how the result can be explained to its consumers. In-depth design review joins these questions into one coherent approach. M1 carries the necessary foundations into implementation; the FxPay research direction explores their future product relevance.

FxPay is a planned payments platform and merchant-services product: payment and collection journeys, receipts, refunds, disputes and reconciliation. Its continuity research asks which already-authorised next action is justified when a provider response is incomplete or missing, within explicit financial exposure limits and with lasting obligations retained. That design is one part of the product vision. Provider integration, comparative operating value and an available merchant service need their own qualification.

The engineering review studied public technical documentation, including Stripe’s, and compared the design questions with existing payment and orchestration mechanisms. This grounds creative work in real operating rules and helps make the intended contribution precise. The work is documentary research, with implementation results and measured comparative value assessed through their own evaluation.

They make individual contributions inspectable. A private terminal-evidence component records 646 assertions, while a separate targeted caller and state correction was checked through 59 finite controls, including five synthetic acceptance cases and 54 expected refusals. Each result keeps its own subject and evidence, allowing integration to build on precise contributions rather than a combined score.

The design examines captures, outstanding holds and possible late effects together. In a hypothetical 40 EUR order, two 40 EUR holds counted alongside one 40 EUR capture produce 120 EUR of modelled exposure, challenging an assumed 80 EUR bound. This analytical example helps sharpen the design’s limits and reasoning; it describes a model rather than a provider’s actual accounting or an observed payment.

The defined evaluation framework compares useful supported action, safety, unnecessary blocks and full lifecycle cost under equivalent evidence, authority and operating rules, with independent expected results. This gives the design a concrete route to demonstrate an engineering contribution alongside competent existing procedures. The reviewed direction is the current contribution; measured prototype and service results belong to subsequent qualification.

Precise execution states, bounded internal SDK contracts, usable evidence and clear explanations give future tools a coherent technical basis. The current work serves M1 implementation and integration; public SDKs, reproduction packages, endpoints and deployments follow their own release stages. The developer page and roadmap describe those stages separately.