FxWire

Update log

• 7 September 2026 - First edition. Drawn from the protocol's normative specifications, the runtime-engine documentation, the architecture programme's transport chapter and the Yellow Paper's ingress chapter. Statuses follow the portal's discipline: what the offline harness proves, what the direction designs, what is reserved.

Short answer

FxWire is the first organ a message meets. Its promise is narrow and load-bearing: it receives outside messages without granting them authority. A frame that FxWire accepts becomes a claim for the protocol to judge; it never becomes an order, and nothing about having been transported gives it power.

Doctrine assigns FxWire the whole network layer - transport, packet validation, anti-spam, peer scoring, decoding of intents, quality of service, metrics and routing. What exists today is deliberately smaller: a deterministic offline decoder that takes canonical intent-body bytes, applies fixed byte limits, and returns a decoded input for FxCore. It opens no socket, runs no peer-to-peer networking, routes no peer and starts no daemon. It also does not seal intents - that is FxCore's act - and it stays independent of FxCore by construction.

The direction, stated by the architecture programme in one sentence, is the lesson of the transport work carried forward: FxWire transports bytes. It does not grant those bytes state authority. Everything designed around it - a canonical wire envelope, peer sessions, bounded ingress, typed synchronisation, post-quantum handshakes - is a way of keeping that sentence true under load and under attack.

What is established, what is in development, what is not claimed

Where FxWire sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell
        ^                                        ->  [5] FxDAG -> [6] FxVM
        |                                        ->  [7] FxState -> [8] FxBlock
   first organ a message meets; nothing before it, FxIntent after it

Figure 1 - Step one of eight. FxWire has no predecessor inside the protocol; everything it produces is handed to FxIntent construction.

The native semantic: a frame is a claim

Every organ of FxChain is a derivation from one axiom - no power exists before its truth has been observed, sealed and audited in a non-authoritative form - and from the native laws that follow it. FxWire is the organ that makes the first law physical.

Claim before power. Nothing enters the protocol as an order; everything enters as a claim to be judged. FxWire is where "everything" first arrives, so it is where the rule is either kept or lost. The Yellow Paper states the consequence for ingress directly: every accepted frame becomes a claim, never an order.

Valid signature is not authority. The architecture programme's law separates authenticity, authorisation, admission, execution and finality into different judgments. At the transport layer this reads: a peer that advertises a capability has advertised it, not been granted it. Capability advertisement is not authorisation to vote, to mutate or to serve privileged data.

The hot path is bounded. Remote input cannot select unbounded memory, recursion, proof work, state growth or iteration. For FxWire that means bounding before decoding: a message must be cheap to refuse before it is allowed to become expensive to read.

   outside                 FxWire                    inside
   bytes  ---------->  bound  ->  decode  ->  normalise  ---------->  a claim
                         |            |
                         v            v
                      refused      refused
                      (too large,  (malformed,
                       too fast)    ambiguous sender)

   nothing that crosses this line carries authority; it carries a claim

Figure 2 - The wall FxWire maintains. Refusal happens as early and as cheaply as possible; what gets through is a claim, not an instruction.

What exists today

The current implementation is exactly what the normative specification says and nothing more.

• Decoding, not networking. FxWire decodes canonical intent-body bytes and returns a decoded input. It applies fixed byte limits. It does not open sockets, run peer-to-peer networking, route peers or start a daemon.
• A decoder with one producer. The decoded input type is produced by a single decoder and has no public constructor outside its own crate. Nothing else in the codebase can manufacture a "decoded" input that did not pass through FxWire.
• Independence from FxCore. FxCore consumes the decoded input and seals it into an intent. FxWire does not seal, and FxCore does not decode. The boundary between the two organs is a type, not a convention.
• Conformance vectors. The ingestion path is pinned by vectors. They are explicitly not final devnet wire-compatibility vectors: the bytes a future network will carry are deferred to a dedicated crossing.

   canonical intent-body bytes
        |
        v   fixed byte limits
   FxWireDecoder  --->  FxWireDecoded  --->  FxCore (seals an FxIntent)
        |
        x  no socket . no peer . no routing . no daemon . no sealing

Figure 3 - The offline ingestion path as implemented. The decoded input can only come from the decoder; sealing belongs to the next organ.

Three planning documents extend the picture without changing runtime behaviour, and are stated as such in the repository: private-ingress concepts for a reserved plane (FxSeal), a canonical wire-envelope plan, and an integration strategy for a versioned intent envelope. Each is docs-only. None adds encrypted ingress, sessions, cryptography, networking or FxWire behaviour.

The direction

The architecture programme's transport chapter describes what FxWire must become when a network exists, and it does so as a set of constraints rather than a feature list.

A canonical wire envelope. A frame will eventually carry a protocol version, a message class, a message identity, a session or channel reference, a payload length, a payload commitment and the payload bytes or a reference to them. The final binary grammar is deferred to its own crossing, precisely because early vectors are not final.

Peer sessions. A session binds a peer's identity, its protocol capabilities, the grammar versions negotiated, its resource budgets and its anti-replay session state. None of that binds authority.

Aggressively bounded ingress. Connection counts, concurrent frames, bytes per frame, decompression ratios, proof sizes and message rates are all explicit limits. Backpressure is structural, not advisory. A remote peer cannot cause the node to allocate from an unbounded length field.

   connection count   -> concurrent frames  -> bytes per frame
   -> decompression ratio -> proof size     -> message rate
   each bound is explicit and checked before the next, more expensive step

Figure 4 - The ingress ladder. Every rung is a limit a hostile peer meets before the node spends anything on it.

Typed synchronisation. Headers and blocks, checkpoints, state chunks and finality material each have their own protocol. A state-sync response is verified against a checkpoint or root before installation. "A peer said this is current" is never sufficient.

Scoring stays operational. Peer scoring and quarantine remain operational controls unless explicitly promoted to consensus semantics. The network may drop or deprioritise an abusive peer, but an opaque local score can never change canonical ordering.

Static first. The first distributed milestone uses static peers and private identities. Discovery, NAT traversal, public bootnodes and permissionless peer policy come later, after basic multi-process determinism is proven.

The Yellow Paper adds the cryptographic posture: strict bounded parsing with early rejection before allocation; a modern transport with a fallback and optional kernel-bypass paths for attested gateways; crypto-agility from day one, with hybrid handshakes and hybrid signatures behind a versioned algorithm registry so that migration needs no hard fork; and privacy lanes that run asynchronously and return their results as evidence, never blocking capsule progress. All of it is design, and it is stated in the table above as research.

The refusal that defines it

The White Paper describes each organ by the refusal that defines it. For the network layer the refusal is the one that keeps every other organ honest: FxWire refuses to let transport become authority. In practice that is three concrete refusals.

• Malformed transport is refused before it is understood, so that understanding cannot be weaponised.
• Ambiguous sender context is refused, because a claim whose claimant cannot be bound is not a claim the kernel can judge.
• Smuggled execution power - a message shaped to be treated as an instruction by virtue of where it came from - is refused by the type system: the only thing FxWire can produce is a decoded input that FxCore will judge.

What FxWire does not do

• It does not open sockets, run a peer-to-peer network, route peers or start a daemon. There is no live network, no discovery and no public peer.
• It does not seal intents. Sealing is FxCore's act, and the two organs stay independent.
• It does not implement the canonical wire envelope, peer sessions, bounded ingress beyond fixed byte limits, typed synchronisation or post-quantum handshakes. These are designed and stated as research or planned.
• It does not implement private ingress. FxSeal is a reserved doctrine plane: design direction, not implemented.
• It never lets a peer score change canonical ordering.

Verdict

FxWire is small today and is meant to stay narrow forever: a boundary whose only job is to turn bytes into claims cheaply and to refuse everything else early. Its implementation is a decoder with fixed limits and a single producer; its direction is a transport layer bounded at every rung and separated from authority by type. The organ proves one thing about the whole protocol before anything else exists: the network can carry claims, and it cannot decide them.

Frequently asked questions

Is FxWire a network stack?

Not yet, and not in the usual sense. Today it is an offline decoder. In the direction it is a bounded transport layer with typed sessions and synchronisation - but even then it remains a mechanism beneath the protocol's grammar, never the grammar itself.

Why refuse before decoding rather than after?

Because a message that is expensive to read is an attack surface. The ladder of explicit bounds means a hostile peer meets a limit before the node spends memory, proof work or time on it.

Can a well-behaved peer earn more authority?

No. Peer scoring is operational: it can affect priority and quarantine, never canonical ordering or authority. Authority in FxChain is a capability, judged by FxCore, and no transport behaviour grants one.

What is FxSeal?

A reserved doctrine plane for encrypted intent privacy and sensitive order-flow protection at ingress. It is design direction and not implemented; it may be named only as reserved.

When does the network arrive?

No date is stated anywhere on this portal. The direction sequences static peers with private identities before discovery, and multi-process determinism before permissionless policy.

Sources and methodology

Drawn from the FxWire specification and the intent specification in the protocol repository, the runtime-engine documentation, the semantic context's canonical and implemented pipelines, the architecture programme's transport and synchronisation chapter, and the Yellow Paper's chapter on wire, post-quantum and privacy lanes. Implementation claims are limited to what the specifications describe as implemented; design claims are attributed to the programme or the paper and carry the status research, planned or reserved.

The specifications and papers are not published on this portal and are not reproduced here. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: Technology for the full sequence; FxIntent, the organ that follows; The three programmes for the public names and references.