FxVM

Update log

• 7 September 2026 - First edition. Drawn from the execution, effect, actor-model and resource-model specifications, the runtime-engine documentation, the architecture programme's chapter on execution, effects, parallelism and resource safety, the Yellow Paper's execution semantics, and the papers' account of the Judge-VM and twin organs. Effect-state and evidence-tier names are given as the shape of the design; budgets and profiles are not.

Short answer

FxVM is the sixth organ and the one where power, if it exists at all, is finally exercised. Its promise is to execute deterministically, with observed receipts. By the time a cell reaches FxVM it has been decoded, declared, judged, given a body and ordered; FxVM's job is not to invent anything but to run what was admitted, under exactly the access it declared, and to leave a receipt that says what actually happened.

Today the organ is a deterministic receipt harness. It consumes a block and the ordered cells that match it, refuses empty blocks, duplicate, missing or unexpected cells and any order mismatch, checks that each cell's identity matches its body before touching it, and emits one receipt per cell - each referencing the block and the cell, with an outcome digest derived from a deterministic transcript under its own hash domain. It executes no bytecode, runs no contract, mutates no state and provides no production semantics. The actor model and the resource model that will govern real execution are draft specifications, and say so.

The direction is a machine built around explicit effects and resource discipline rather than opaque mutation. Three effect states are mandatory - declared, observed, committed - and an observed effect outside the declared or authorised set produces a typed abort before any canonical mutation. Speculative workers may run concurrently, but the commit order and the resolution of conflicts are deterministic: parallel execution must not imply nondeterministic commitment. The Yellow Paper goes one inversion further and calls the organ the Judge-VM: a call is a claimed delta plus evidence, judged against the effect algebra, and the hot path is bounded by the cost of verifying evidence, never by the cost of running a program.

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

Where FxVM sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell -> [5] FxDAG -> [6] FxVM
                                                                            ^   -> [7] FxState
                                                                            |   -> [8] FxBlock
   after FxDAG (an order and its windows), before FxState (commitment of what was observed)

Figure 1 - Step six of eight. FxVM is where an admitted, ordered claim is finally run - and observed.

The native semantic: verify what you can; observe what you run

Two native laws define the organ, and one design law bounds it.

Evidence before computation. The protocol judges a claimed delta against evidence; it never computes what it can verify. FxVM is where that law meets the machine: in the direction, a contract call is a claim plus a delta plus evidence, and execution on the hot path is verification.

Declared is not observed. The architecture programme's law says a declaration is attributed intent and an observation is a measurement. FxVM is the organ that produces the observation - what a cell actually read, wrote and caused - and compares it with what the cell declared. The comparison is not a formality: its outcome is either a committed effect or a typed abort.

The hot path is bounded. A contract or actor cannot select unbounded work by handing the machine a giant nested payload. Compute units, state reads, state growth, proof verification, memory ceilings, call depth and any privacy-lane work are all budgeted.

   DeclaredEffect  (what the cell said it would cause)
          |
          v   execution, under declared access and a resource budget
   ObservedEffect  (what the machine measured)
          |
          +--- within the declared and authorised set ---> CommittedEffect
          |
          +--- outside it ---------------------------> typed abort,
                                                      before any canonical mutation

Figure 2 - The three effect states the direction makes mandatory. Only an observed effect that was declared and authorised may become a committed one.

What exists today

A harness, and only a harness. FxVM consumes a block and the ordered cells that match it. It emits one successful receipt per cell listed in the block. It refuses an empty block, a duplicate cell, a missing cell, an unexpected cell and any mismatch between the block's order and the cells supplied.

Integrity before execution. The harness rejects a block or a cell whose identity does not match its body before any execution, and the single-cell execution boundary validates the same integrity on its own. The low-level unchecked constructor, reserved for primitives and tests, cannot be used to slip past this boundary.

Receipts with a domain. Each receipt references the committed block and the current cell. Its outcome digest is derived from a deterministic transcript and hashed under a dedicated outcome domain, so that a receipt's digest can never be mistaken for the digest of any other object.

   FxBlock (ordered cell identities)  +  the matching FxCell values
        |
        v   refuse: empty . duplicate . missing . unexpected . order mismatch
        v   refuse: any identity != hash(body), block or cell
   one deterministic FxReceipt per cell
      { block reference, cell reference, outcome digest (transcript, outcome domain) }
        |
        x   no bytecode . no contract . no state mutation . no production semantics

Figure 3 - The harness as implemented. It proves that receipts can be produced deterministically from a sealed order before there is anything to execute.

Declarations without enforcement. Version zero of the effect declaration - resources by namespace, key and version, read and write access, sorted and duplicate-free - exists with a helper that flags conflicting accesses. It is a baseline for future access-set and dependency work. Nothing on the local line enforces it at execution, and the specification says so.

Two drafts. The actor model describes contracts as actors that own typed state, expose a message interface and are scheduled by the dependency graph carried by cells. The resource model describes accounting in compute, memory and storage units and their pricing. Both are drafts and are stated as research above.

The direction

Effects, not mutation

The architecture programme designs FxVM around explicit effects and resource discipline rather than arbitrary mutation. The current effect specification is declaration-only; the programme defines the path by which declaration becomes enforceable execution. Three effect states are mandatory - declared, observed, committed - and the executor may commit only effects authorised by the current intent, capability and policy context. Candidate effect families cover state reads, creation, update and deletion; resource minting, transfer and burning; capability consumption; event emission; and explicitly scoped references to claims and policies. Any new effect class must bring its own conservation and authority invariants.

An execution context carries the chain and protocol version, the policy in force, the authority context, the pre-state root, the declared access set, the resource budget and the execution profile. The machine emits a commitment to its execution trace and a typed outcome - never merely a boolean success.

Deterministic parallelism

Parallel execution is staged around access sets, under one critical invariant: parallel execution must not imply nondeterministic commitment. Speculative workers may run concurrently; the commit order and the resolution of conflicts are deterministic; and the runtime records enough to reproduce why two cells were run in parallel, retried, serialised or refused.

   speculate concurrently          commit deterministically
   worker 1: cell A   \            order and conflict resolution are
   worker 2: cell C    >  ---->    functions of declarations and the
   worker 3: cell E   /            committed inputs - identical on
                                   every node, and explained in the record

Figure 4 - Concurrency in the workers, determinism in the commit. The record can say why any two cells were parallel, retried, serialised or refused.

The abort receipt

The Yellow Paper makes the lifecycle of a broken declaration normative. The claim declares its access set; execution observes an access outside it; the cell aborts deterministically - the same outcome on every node, at a bounded point in the schedule; no state mutation of any kind occurs; the observed access set is sealed into an abort receipt with a divergence proof; the claimant receives an advisory suggested widening of the claim, which carries no authority and no promise of admission; the retry is budgeted and priced for the congestion it now causes; and repeated aborts consume per-account and per-resource budgets until a deterministic cooldown. The paper's own summary is that this is not blind retry but a controlled learning loop: deterministic, economic, resistant to spam, and evidence-producing - every abort is a sealed artifact.

The Judge-VM

The organ inversion turns execution into judgment. A call is a claimed delta plus evidence, judged as a function of the claim, the delta, the evidence and the version of the effect algebra. Evidence is tiered: deterministic replay is the completeness floor - every claim class is judgeable by replay alone; signed receipts sit above it; zero-knowledge proofs are discounted where verification is cheaper than replay; attested enclaves are admissible only in defined lanes and never as the sole root of trust. External signed receipts are never canonical on their own; they bind through reconciliation invariants. Hot-path cost is bounded by evidence verification, never by program execution. Computation happens wherever it is cheapest - client, solver, prover network, a privacy lane - and the consensus path verifies.

   classic VM                              Judge-VM
   run the program to discover             receive claim + delta + evidence
   its effects; cost = execution           judge against the algebra; cost = verification

   evidence tiers:  replay (floor)  <  signed receipts  <  zk proofs  <  attested enclaves
                    complete            medium              heavy logic     defined lanes only

Figure 5 - The inversion. The chain never computes what it can verify; the replay floor guarantees that everything remains judgeable.

A compatibility virtual machine - an EVM sidecar - is reserved. If introduced, it maps its execution into the protocol's effect and receipt semantics rather than redefining canonical state around another chain's assumptions, and it is the lowest evidence tier: replayed computation, isolated, behind an explicit state bridge.

Twin organs

The papers' bicameral inversion applies to FxVM as to every power-bearing organ: it ships with a non-authoritative observer twin, and organ-twin coherence facts are consensus objects. If the machine and its twin diverge on a coherence fact, the power fails closed for the scope of the divergence and emits a contradiction artifact - before losses, not after. FxSentinel, the observing intelligence, becomes merely the most sophisticated twin among many; its status on this portal is research.

The refusal that defines it

The White Paper's grammar of organs gives three refusals that land in FxVM: the smart contract becomes an actor with linear resources and declared effects, refusing synchronous reentrancy and implicit duplication; the compatibility machine is a sidecar at the lowest evidence tier, refusing the design prison; gas becomes a fee vector priced along separate dimensions, refusing one-dimensional congestion. The organ's own refusals follow.

• Nondeterministic behaviour. Any source of nondeterminism near the machine is classified - forbidden, normalised before the kernel, committed as an input, or operational-only - and an unclassified one on the consensus path is prohibited.
• Undeclared access. An observed access outside the declaration aborts the cell deterministically and leaves evidence. There is no silent widening.
• Runtime authority not earned upstream. Execution is not a place to invent power. The machine commits only effects authorised by the context under which the claim was admitted.

What FxVM does not do

• It does not execute bytecode, run smart contracts, mutate state or provide production semantics on the local line. It emits receipts.
• It does not enforce declared access or effects today. The declaration schema is version zero and declaration-only.
• It does not implement the three effect states, deterministic parallelism, the abort-receipt lifecycle, the Judge-VM's evidence tiers or twin organs. These are design, stated as research.
• It does not host a compatibility machine. The sidecar is reserved and, if it ever exists, is the lowest evidence tier.
• It does not decide admissibility or order. FxCore judges; FxDAG orders; FxVM runs what it is given, in the order it is given.

Verdict

FxVM is the organ where the protocol's refusal to invent power becomes a machine. What exists is a receipt harness that proves the shape of the thing - a sealed order in, one deterministic receipt per cell out, integrity checked at every boundary, nothing mutated - before any execution exists. What is designed is an executor of explicit effects whose parallelism cannot leak into its commit, whose broken declarations abort identically everywhere and leave evidence, and which verifies claimed deltas rather than running programs on the hot path. The organ's own advantage line is the whole doctrine in one sentence: execution is where admitted power is tested, observed and made replayable.

Frequently asked questions

Does FxVM run smart contracts?

Not today: it is a receipt harness. In the direction, contracts are actors with typed state and declared effects, and a call is judged as a claimed delta with evidence rather than run to discover what it does.

What is an observed effect?

A measurement of what execution actually read, wrote and caused, produced by the machine and compared with what the cell declared. The comparison is the mechanism: a match may commit, a mismatch aborts before any canonical mutation.

Why can parallel execution not be nondeterministic?

Because two nodes must commit identical state from identical inputs. Workers may speculate concurrently, but the commit order and the resolution of conflicts are functions of the declarations and the committed inputs, and the record explains why each cell ran, waited, retried or was refused.

What does "verify, do not compute" mean in practice?

That the hot path's cost is bounded by checking evidence - replay, receipts, proofs, attested lanes - rather than by running programs. Replay remains the floor, so every claim class can still be judged by recomputation when no better evidence is available.

Will there be an EVM?

A compatibility sidecar is reserved, not planned. If it is ever introduced, it maps into the protocol's effect and receipt semantics and sits at the lowest evidence tier, isolated behind an explicit bridge. It never becomes the semantic centre.

Sources and methodology

Drawn from the execution, effect, actor-model and resource-model specifications in the protocol repository, the runtime-engine documentation, the architecture programme's chapter on execution, effects, parallelism and resource safety and its design laws, the Yellow Paper's execution semantics, and the papers' account of the Judge-VM and twin organs. Implementation claims are limited to what the specifications describe as implemented or declaration-only; design claims are attributed and carry the status research or reserved.

The specifications and papers are not published on this portal and are not reproduced here; effect-state and evidence-tier names are reported as the shape of the design, budgets and profiles are not. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxDAG, the organ before; FxCell for the declarations execution is measured against; Technology for the full sequence.