FxCore

Update log

• 7 September 2026 - First edition. Drawn from the runtime-engine documentation, the semantic context's implemented scope, the Yellow Paper's admissibility kernel and authority model, the architecture programme's admission and authority chapters, and the White Paper's organ inversions. Verdict names and outcome names are given as the shape of the design; thresholds, defaults and profiles are not.

Short answer

FxCore is the third organ and the one that gives the protocol its name. Its promise is to judge admissibility before power. A claim built by FxIntent arrives powerless; FxCore decides whether it may proceed at all - under the protocol's native laws, under the account's own constitution, and against a catalogue of powers the protocol refuses to have - and it answers in one of two ways: an admitted candidate for the next organ, or a sealed denial that states exactly why.

Today, FxCore's implemented surface is precise and narrow. It normalises and seals a decoded body into an intent after an optional expected-network check. An offline admission oracle - a sealed surface on the development line - emits a three-verdict grammar: structurally valid but not admitted, denied, or deferred. Admission-boundary conformance vectors pin the boundary, and the local runtime carries an explicit gate whose name is its meaning: no transaction admission. The local line judges canonical construction; it does not admit anything into a network, because there is none.

The direction turns that oracle into the runtime kernel. The Yellow Paper freezes a canonical order of ten verdicts - syntax, signature, replay, constitution, capability, causality, effect, economic, risk and finality plane - such that two nodes evaluating the same claim emit byte-identical verdict sequences. The architecture programme gives admission its own outcome algebra - admitted, denied with reason, deferred with reason, conflicted with reference - and a rule that refusal precedence must be deterministic so that hostile tests can prove which guard fired. Underneath both sits one authority model: authority is scope times policy, composition cannot escalate, policy is necessary but never sufficient, and every evaluation fails closed. There are no roles. Capability is the only authority.

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

Where FxCore sits

   [1] FxWire -> [2] FxIntent -> [3] FxCore -> [4] FxCell -> [5] FxDAG
                                     ^                         -> [6] FxVM
                                     |                         -> [7] FxState
   after FxIntent (a typed claim), before FxCell (a causal unit) -> [8] FxBlock

Figure 1 - Step three of eight. Everything before FxCore is construction; everything after it is what an admitted claim is allowed to become.

The native semantic: a gate that explains yes and no

FxCore is where three of the native laws are enforced at once.

Claim before power - the input is a claim; the output is a judgment. Nothing FxCore receives is an instruction, and nothing it emits is an execution.

Evidence before computation - the kernel judges a claim together with its evidence, its declared effect set, the capabilities it invokes and the constitution it is bound to, and emits a verdict. It never computes what it can verify; verification is the whole of its work.

Denial is a first-class output - a refusal is not an error. It is a sealed, typed, reproducible result: this did not happen, for this exact reason, under this invariant. The White Paper's grammar of organs makes the point by contrast with the classic block, which the papers refuse to accept as a finality surface without denial evidence.

And beneath the three laws, one authority model. All authority is expressed as scope times policy: composing two authorities cannot escalate scope; satisfying a policy is necessary but never sufficient; every evaluation fails closed. There are no roles - no validator role, no admin, no gateway role - only sealed, scoped, expiring, revocable capabilities with provenance. Capability is the only authority, and FxCore is the organ that checks it.

   claim  +  evidence  +  declared effects  +  capabilities  +  constitution
                                   |
                                   v
                              FxCore judges
                                   |
              +--------------------+--------------------+
              v                                         v
      admitted candidate                          sealed denial
      (an FxCell may be built)                    (reason class public,
                                                   detail claimant-scoped)

   authority = scope x policy . composition cannot escalate
   policy is necessary, never sufficient . every evaluation fails closed

Figure 2 - The kernel's function and its two outputs. There is no third output; an intent that is neither admitted nor denied is deferred, and a deferral is itself a typed result.

What exists today

Normalisation and sealing. FxCore consumes the input FxWire decoded and seals it into an intent, after an optional check that the intent targets the expected network. Account validation, signature validation, nonce storage and replay protection are stated out of scope of this path - by design of the local line, which proves canonical construction before any live behaviour exists.

The admission oracle. A sealed surface on the development line - the sovereign admission oracle - already emits an offline verdict grammar with three outcomes: structurally valid but not admitted, denied, and deferred. The Yellow Paper names this surface as the lineage of the runtime kernel: the kernel is the runtime generalisation of a verdict grammar that exists, not an invention on paper.

The boundary, pinned. Admission-boundary conformance vectors, an explicit projection from the planning envelope to the canonical body, and audit guardrails against false implementation claims fix where construction ends and admission would begin.

The gate that denies. The local runtime carries a deterministic input envelope behind a gate named for what it does: no transaction admission. The line admits no transaction, and says so in the name of the object that would.

   today (offline)                       direction (runtime kernel)
   sovereign admission oracle            canonical verdict ladder
   +--------------------------------+    +--------------------------------+
   | structurally valid,            |    |  1 syntax     6 causality      |
   |   not admitted                 | -> |  2 signature  7 effect         |
   | denied                         |    |  3 replay     8 economic       |
   | deferred                       |    |  4 constitution 9 risk         |
   +--------------------------------+    |  5 capability 10 finality plane |
   sealed surface, conformance-pinned    +--------------------------------+
   admits nothing into a network         frozen order, byte-identical

Figure 3 - Lineage, not replacement. The three-verdict oracle exists; the ten-verdict ladder is its designed generalisation.

The direction

A frozen verdict order. The Yellow Paper freezes the canonical order in which a claim is judged: syntax, signature, replay, constitution, capability, causality, effect, economic, risk, finality plane. Two nodes evaluating the same claim emit byte-identical verdict sequences. The boundaries between stages are strict: validation does not imply admission; admission does not imply execution; an execution receipt does not imply finality; finality binds only the declared planes.

A cheap-reject tier. The first three verdicts refuse at near-zero cost and emit unsealed refusals. Sealed denial receipts exist only past the admissibility threshold. The design rule is that refusal is never an amplification vector: it must never cost the network more to say no than it cost the attacker to ask.

   verdicts 1-3   syntax . signature . replay
                  refuse at near-zero cost -> unsealed refusal
   ---------------------------- admissibility threshold ---------------
   verdicts 4-10  constitution . capability . causality . effect
                  economic . risk . finality plane
                  refuse with a sealed DenialReceipt
                  (boundary, invariant, reason class, evidence hash,
                   claimant-scoped detail)

Figure 4 - Two tiers of refusal. Cheap refusals stay cheap; sealed denials carry the evidence that makes them auditable.

Denial privacy and reproducibility. The reason class of a denial is public; the full detail is scoped to the claimant, and a sealed claim's content must not be reconstructable from its public denial. Denial categories are stable, versioned and reproducible locally; the direction names FxLab as the place to reproduce them and FxScan as the place to browse them - both product surfaces whose statuses on this portal are research and planned respectively.

An outcome algebra. The architecture programme gives admission its own typed outcomes: admitted; denied, with a reason; deferred, with a reason; conflicted, with a reference to the conflict. Unestablished may appear in pre-consensus evaluation, but it must be converted into deterministic behaviour before consensus - a validator cannot call an external service and disagree with another validator on the same committed intent. Admission checks are ordered and typed - grammar validity, chain and domain binding, signature transcript validity, replay and sequence validity, authority state, obligation completeness where required, resource budget, state preconditions, policy constraints - and refusal precedence is deterministic so that a hostile test can prove which guard fired first.

Staged, and kept clean. The implementation rule is staged: first a single-process admission path in a living node, then persistent state, then same-kernel simulation, then networked consensus. Mempool and order-flow policy are not allowed to leak into the base intent grammar prematurely.

Two constitutions. The organ inversion the papers call constitutional accounts makes the account a jurisdiction. An intent is admissible only if it satisfies both the protocol's constitution and the account's own - its admission policy, its replay scope, its session grammar, its spending and denial set, its recovery law - enforced by consensus, not by wallet software. Interactions between accounts become treaty-like: each side's constitution is checked deterministically. Phishing, blind signing and drainer approvals become refusable by the protocol instead of mitigable by an interface.

   protocol constitution        account constitution
   native laws, refused powers  admission policy, replay scope, session
   capability catalogue         grammar, spending and denial set, recovery
              \                        /
               \      both must pass  /
                v                    v
                   admitted  or  denied (which one failed is stated)

Figure 5 - Two constitutions, one verdict. Neither can be satisfied on the other's behalf.

The refusal that defines it

FxCore is the organ whose refusals are its product. The catalogue of powers the protocol refuses to have is not a policy document; in the direction it is evaluated per epoch and committed as a denial root beside the state root, so that a third party can verify not only what the network did but what it provably could not do. FxCore is the point where each refusal is applied to a claim. It refuses:

• Unauthorised authority - a claim invoking a capability its claimant does not hold, or that has expired or been revoked;
• Invalid account powers - a claim that the account's own constitution forbids, however valid it is under the protocol's;
• Missing evidence - a claim whose effect class requires evidence that is not attached, or attached at too weak a tier;
• Claims outside the constitution - anything whose effects cannot be stated in the closed algebra, or whose meaning cannot be audited before it runs.

What FxCore does not do

• It does not admit transactions on the local line. The gate that would is named no-transaction-admission, and it is complete.
• It does not validate accounts or signatures, store nonces or protect against replay on the local path. These are out of scope and not claimed.
• It does not execute. An admitted candidate becomes a cell for FxDAG to order and FxVM to execute; FxCore's authority ends at the verdict.
• It does not implement the ten-verdict ladder, the cheap-reject tier, denial privacy, the outcome algebra or constitutional accounts. These are design, stated as research or planned.
• It does not call external services during a judgment. In the direction that is a law, not a preference.

Verdict

FxCore is the organ that makes "proof before power" operational: a claim is judged - against the laws, against the account, against the catalogue of refused powers - and the answer, yes or no, is a typed result that explains itself. What exists is the lineage: an offline oracle with a three-verdict grammar, a pinned boundary, and a gate whose name is a refusal. What is designed is the kernel: ten verdicts in a frozen order, two tiers of refusal, privacy for denials, an outcome algebra with deterministic precedence, and two constitutions that must both be satisfied. The distance between them is the distance between a local line that proves construction and a network that does not yet exist - and that distance is stated, not hidden.

Frequently asked questions

Why is denial "first-class"?

Because in most systems a refusal is an error, an event or an application convention, and it disappears. In FxChain a denial past the admissibility threshold is a sealed, typed, reproducible result with a reason class and an evidence hash. What the protocol refused can be audited like what it accepted.

What is the difference between denied and deferred?

Denied means the claim fails a verdict and will fail it again identically. Deferred means the claim cannot yet be judged - a stricter evidence path is required, or a precondition is not yet established - and the deferral is itself a typed result. Neither is silence.

Does FxCore run code to decide?

No. It judges a claim, its evidence, its declared effects, its capabilities and its constitution, and emits a verdict. The organ that executes is FxVM, and the direction's rule for it is the same: verify what can be verified, compute only what cannot.

What does "no roles" mean in practice?

That no string such as validator, admin, gateway or reviewer grants anything. Authority is a capability: sealed, scoped, expiring, revocable, with provenance. FxCore checks the capability, never the label.

Can I see a denial today?

The offline oracle emits its three verdicts on the development line, and admission-boundary vectors pin them; neither is public. The direction names FxLab for reproducing denial categories locally and FxScan for browsing them; those surfaces are research and planned.

Sources and methodology

Drawn from the normalisation and runtime-boundary specifications in the protocol repository, the semantic context's implemented scope, the Yellow Paper's chapters on the axiom and native laws, the admissibility kernel and denial model, and formal objects, the architecture programme's chapters on intent and admission and on authority, and the White Paper's grammar of organs and organ inversions. Implementation claims are limited to what the specifications describe as implemented or sealed; design claims are attributed and carry the status research or planned. Verdict and outcome names are reported as the shape of the design; thresholds, defaults and candidate profiles are not.

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: FxIntent, the organ before; Technology for the full sequence; The acceptance discipline for the same doctrine applied to the protocol's own construction.