Update log
- 7 September 2026 - First edition, compiled from the organ dossiers, the Foundations edition, the Technology page and the Direction series. Definitions are the portal's; where a word is also a term of art in the protocol's own documents, the portal's definition is the public reading of it.
Short answer
This portal uses ordinary words in bounded senses. A claim is not a marketing claim; a denial is not an error; a capsule is not a block with a nicer name; sealed does not mean audited. The tables below give the sense in which each word is used, and the dossier where it is developed. Where a term names something that exists only in the design, the table says so.
The line and its history
| Term | Meaning | Where |
|---|---|---|
| Sealed development line | The protocol repository as it advances by named crossings, with eras whose bytes are frozen once sealed. Local; not a network. | Sealed history |
| Era | A named stage of the line, D0 to D6, each admitting one narrow power and listing the powers it still denies. | Sealed history |
| Crossing | The unit of advance: one objective, a named predecessor, explicit non-authorisations, bound objects and an acceptance record. The census of crossings is the count shown on the home page. | Sealed history |
| Acceptance record | The document that registers a crossing as the unique successor of the one before and binds the exact objects it accepted. | The acceptance discipline |
| Covenant | A permanent boundary over an admitted power. It narrows the act; it never enlarges it. | Sealed history; The storage constitution |
| Exhausted key | A counted authority spent once inside its crossing. Evidence that a power was exercised, never a right to exercise it again. | The authority algebra |
| Source hierarchy | The order used in disputes: sealed modules, frozen vectors and conformance, audit reports, specifications, and last the descriptive map. | Sealed history |
| Evidence snapshot | The dated figures on the home page - eras, crossings, conformance - with their method, reference and verification date. Never a live counter. | Home; Foundations |
| Conformance vector | A frozen input and expected output that pins a behaviour of the line; a change that alters it is visible. | The evidence lab |
| Family | A group of crossings that together earn one bounded capability, such as the reconstruction family. | The replay domain |
The evidence objects
| Term | Meaning | Where |
|---|---|---|
| Claim | A declared request asking the protocol to consider an action under constraints, expiry and proofs. It enters powerless and is judged before anything executes. | FxWire; FxIntent |
| Admissibility | The verdict of the constitutional kernel: whether a claim may proceed under native laws, account constitutions and refused powers. | FxCore |
| Receipt | What execution actually observed: the material needed to re-derive a result rather than take it on trust. One per cell on the local line. | FxVM; Receipts, denials and capsules |
| Denial | A refusal as a result. On the local line, a typed boundary; in the direction, a sealed artifact with a public reason class and claimant-scoped detail. | Receipts, denials and capsules |
| Denial root | A chained commitment, in each capsule, over the machine-evaluated no-authority invariants of an epoch and the catalogue of the judge that evaluated them. Design. | FxBlock |
| Abort receipt | The sealed record of an execution that touched state it had not declared: nothing mutated, the observed set kept with a divergence proof. Design. | Receipts, denials and capsules |
| Capsule | The finality surface: state root, receipts root, data-availability root, denial root, coherence roots and a certificate, sealed together. Design; the local line seals blocks. | FxBlock |
| Witness | Additive evidence attached to sealed history. Later work adds witnesses; it never re-cuts what is sealed. | FxState; Foundations |
| Refusal | A path declining to admit or reconstruct the supplied material under its conditions. Preserved as an outcome, never resolved by voting. | Foundations; The replay domain |
| Settlement truth | The rule that executed, finalised, delivered, legally effective and economically complete are five different facts, and that missing evidence is not false. | Receipts, denials and capsules; Institutions |
The organs and execution
| Term | Meaning | Where |
|---|---|---|
| Organ | One of the eight responsibilities a claim meets in order: FxWire, FxIntent, FxCore, FxCell, FxDAG, FxVM, FxState, FxBlock. | Technology |
| Cell | The causal unit that carries an admitted claim through ordering and execution, with its dependencies and declared access. | FxCell |
| Window | A set of cells that can be ordered together. Cells that commute run in an order-invariant window; conflicts stay explicit. | FxDAG |
| Declared access | The state a claim says it will read and write. Execution outside it aborts deterministically. | FxCell; FxVM |
| Harness | The deterministic local execution environment of the line. Not a virtual machine for general programs. | FxVM |
| State root | The typed commitment FxState derives from a block and its receipts. It identifies a state; it does not make it legitimate. | FxState |
| Projection | Any state derived from sealed evidence - a balance, an index, a dashboard. Reconstructible and non-authoritative by type. | FxState; The storage constitution |
| Genesis snapshot | The one artifact the persistence era authorised to be preserved and verified against its frozen anchor. | FxState; Sealed history |
| Reconstruction | Rebuilding a bounded preserved history and comparing the result. Implemented locally as a family of crossings. | The replay domain; Foundations |
| Oracle path and engine path | The two independent reconstruction implementations: one adjudicates a single unit, the other a bounded sequence; neither links the other. | The replay domain |
| Tribunal | The comparison of the two paths. It reports agreement, disagreement and asymmetric refusal; it decides nothing. | The replay domain |
| Living node | The planned first node: bounded socket, signed intent, transition, receipt, query. Not built. | The living node |
Authority
| Term | Meaning | Where |
|---|---|---|
| Capability | The only form of authority in the direction: sealed, scoped, expiring, revocable, with provenance. There are no roles. | The authority algebra |
| Mandate | A bounded grant under which a holder - a person, an institution, an agent - may act: scope, amount, time. The key is not the mandate. | FxIntent; Institutions |
| Effect set | The typed consequences a claim declares - value, authority, state, time, privacy, external. Finality plane, fees, receipt shape and audit view derive from it. | FxIntent; Privacy |
| Typed meet | The composition of two authorities: narrower on shared coordinates, never wider, and incomparable when dimensions cannot be compared. | The authority algebra |
| Eligibility | The temporary state of an authority's exercise - eligible, held, conflicted, unestablished - as distinct from its permanent power. | The authority algebra |
| Duty delta | The duties created, transferred, satisfied, breached, expired or disputed by any change of authority. Authority without it is incomplete. | The authority algebra |
| Sovereign Change Core | The envisaged compact typed core for governed change. Its antecedents are practised; the core is planned, not started. | Programmes |
Evidence and assurance
| Term | Meaning | Where |
|---|---|---|
| Proof before power | The founding axiom: no power exists before its truth has been observed, sealed and audited in a non-authoritative form. | Home; About |
| Powerless twin | The first form of every power: exercised with zero authority, producing evidence, before any activation. | Sealed history; The evidence algebra |
| Evidence tier | The admissible forms of evidence, with deterministic replay as the floor and proofs and receipts above it. Design. | The evidence algebra |
| Contradiction escrow | Keeping an unresolved conflict bounded and visible - resource, authority, evidence, dependency radius - until explicit authority resolves it with a receipt. Design. | The evidence algebra |
| Falsifier | The test that would reject a claim. The acceptance discipline requires candidates to carry their own. | The acceptance discipline |
| Negative control | A check that must fail when the thing it guards is removed; the proof that a green run measured something. | The evidence lab |
| Hostile review | A review whose job is to break the candidate, with its own controls, before acceptance. | The acceptance discipline |
| Six axes | The status grammar: implementation stage, deployment scope, governance state, truth role, epistemic status, assurance level. Never compressed into one word. | Six axes, never one status |
| Status vocabulary | The portal's projection of the six axes: research, implemented locally, in development, planned, reserved; and the claim scope proven today, in development, later gates, not claimed. | Site-wide |
The direction
| Term | Meaning | Where |
|---|---|---|
| Three planes | The runtime plane, the change plane and the assurance plane: who executes, who governs change, who proves. | Three planes |
| Programmes | The three named programmes: Sovereign Assurance and Attestation; Governed Operations and Evidence Custody; the Architecture and Protocol Programme. | Programmes |
| Finality plane | One of the declared settlement planes a claim's effects place it on, each with its own latency, challenge window and caps. Design. | FxBlock |
| Reserved plane | A doctrine plane named in the direction and not implemented: FxSeal, FxChronos, FxEffect, FxCryo, FxHypervisor, FxMirror, FxPrism, FxCodex, FxKinesis. Always status reserved. | Three planes |
| Storage constitution | The ratified law over storage: rings, planes, covenants, presumption, oracle and tribunal. No engine selected. | The storage constitution |
| Adoption zero | The first rung of the adoption ladder: offline verification and portable denials with no network prerequisite. Planned. | Developers |
| Deployment-necessity tribunal | The gate that decides whether a sovereign network is warranted at all, with simpler dispositions that may win. Design. | The living node |
| Node ladder | From the deterministic local kernel to a living node, a durable node, a simulator, devnets, and testnet and mainnet candidates. Only the first rung exists. | The living node |
How to read a status on this portal
The colour code, wherever a status dot appears: green is proven today; yellow is in development or qualified; pale blue is direction - planned or research; grey is a later gate; a hollow dot is not claimed.
Every product, module and claim carries one of five statuses - research, implemented locally, in development, planned, reserved - and every dossier opens with a table whose status column uses the claim scope: proven today, in development, planned, research, later gate, reserved, not claimed. The two vocabularies are projections of the six-axis grammar and lose information on purpose; the dossier's Basis and Limit columns restore what the word drops. When a page does not state something, the portal does not claim it.
Sources and methodology
Compiled from the dossiers on this portal, the Foundations edition, the Technology page and the site plan. Definitions are the portal's public reading of terms whose authoritative definitions live in the protocol's specifications and papers, which are not published here. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this glossary.
Related reading: Technology for the eight organs; FxChain Foundations for the reading path; Programmes for the three names.