Receipts, denials and capsules

Update log

• 7 September 2026 - First edition. Drawn from the receipt and block specifications of the local line, the era and power map, the Yellow Paper's formal objects, admissibility kernel and abort lifecycle, the White Paper's laws and inventions, and the architecture programme's chapter on receipts, denials, conflicts and settlement truth. Object names are given as the shape of the design; their exact grammars are not reproduced.

Short answer

A status flag compresses. "Success" hides whether the money moved, whether the law followed, whether the evidence was ever present. "Failure" hides whether the claim was malformed, refused by rule, or simply missing a proof. FxChain's direction replaces the flag with objects, each of which says one thing and proves it.

• A receipt records what execution observed - for a cell, under a block, with the observed access and the result - and is sealed under its own hash domain. Today, on the local line, FxVM emits exactly one per cell and FxState derives the state root from them.
• A denial is a refusal as a result. The White Paper's fourth law: "A refusal is not an error; it is a sealed, typed protocol result: this did not happen, for this exact reason, under this invariant." Today refusals are explicit typed boundaries at every organ, and the very first era of the line is named denial and framing; sealed denial receipts with a public reason class and claimant-scoped detail are design.
• An abort receipt records an execution that touched state it had not declared: the cell aborts deterministically, nothing mutates, and the observed set is sealed with a divergence proof - design.
• A capsule is the finality surface: state root, receipts root, data-availability root, denial root, coherence roots and a certificate, sealed together - design.

The common thread is the architecture programme's law of settlement truth: executed is not finalised, finalised is not delivered, delivered is not legally effective, legally effective is not economically complete, missing evidence is not false, and an instrument error is not a domain failure. Each object exists so that none of those distinctions can be lost.

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

Receipts: what execution observed

On the local line a receipt is a small, sealed fact: for one cell, under one block, this is what the harness observed. The specification pins its shape: receipts are sealed from a body under their own domain, one per cell listed in the block, each referencing the block it belongs to; FxState refuses a receipt whose identity does not match its body and derives the state root from receipts sorted by the canonical bytes of their cell identities. The FxVM dossier describes the emission; the FxState dossier the commitment.

   cell --> harness execution --> receipt (sealed, receipt domain)
                                     |  one per cell, references the block
                                     v
                       receipts sorted by cell identity --> state root

Figure 1 - The receipt on the local line: deterministic, typed, one per cell, and the only input to the root besides the block.

The direction keeps the receipt as a primary truth surface and separates its families by plane: the runtime owns execution, admission, denial, recovery and finality receipts; the change plane owns transition, acceptance and closeout receipts; the assurance plane owns witness, finding and reproduction receipts. A minimal header - identity, subject, version, reason, commitment - is shared; the semantics stay with the plane, because a receipt that meant the same thing everywhere would mean nothing precisely anywhere. And the Yellow Paper's boundary law is strict: "validation does not imply admission; admission does not imply execution; an execution receipt does not imply finality; finality binds only declared planes."

Denials: a refusal is a result

The line's first era is named denial and framing: before any computation, the framing fixed explicit negative boundaries and offline facts, and the era's denied column - runtime, network, consensus, finality, ambient mutation - was written before its admitted one. Every organ dossier on this portal carries a "refuses" line for the same reason. On the local line these are typed refusals at boundaries; the denial as a sealed object is the direction.

The Yellow Paper's admissibility kernel fixes a frozen order of verdicts so that "two nodes evaluating the same claim emit byte-identical verdict sequences". It then draws a line that answers the obvious economic objection. The cheapest verdicts - syntax, signature, replay - "refuse at near-zero cost and emit unsealed refusals. Sealed denial receipts exist only past the admissibility threshold. Refusal is never an amplification vector." A denial costs the protocol something to seal, so only claims that earned a real judgement receive one.

   claim
     |
     v  cheap-reject tier: syntax . signature . replay
     +--> unsealed refusal (near-zero cost, no object)
     |
     v  admissibility threshold
     +--> sealed DENIAL: boundary, invariant, reason class, evidence hash
     |                   public reason class . claimant-scoped detail
     v
   admitted --> cell

Figure 2 - Two tiers of refusal. Only a claim that passed the cheap tier earns a sealed denial.

Two properties follow. Privacy: "the reason class of a denial is public; the full detail is claimant-scoped. A sealed claim's content must not be reconstructable from its public denial." Reproducibility: denial categories are stable, versioned and reproducible locally, and the kernel's lineage is the sealed admission-oracle grammar of the framing era - structurally valid but not admitted, denied, deferred.

The architecture programme adds the institutional half. A denial "is not merely a failed flag": it identifies the exact deterministic refusal boundary, the reason code, the subject and the relevant committed context, without exposing secrets unnecessarily. Where disclosure is safe, an actionable denial may name the applied rule, the failed obligation, the missing evidence class, the authority basis and a bounded remediation hint - and the programme separates a reconstructible reason from unbounded disclosure, so that being told why never becomes a channel for learning what one was not entitled to know.

Abort receipts: the shadow that teaches

Execution against state a claim did not declare is not an error path in the direction; it is a specified lifecycle. The claim declares its access set; execution observes an access outside it; the cell aborts deterministically - identical 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 wallet or solver receives an advisory suggested widened claim "derived from the observed set (advisory only: it carries no authority and no admission promise)"; the retry is budgeted and congestion-priced; repeated aborts consume per-account and per-resource budgets, and exhaustion triggers a deterministic cooldown.

   declared access  -->  execute  -->  undeclared access observed
                                            |
                                            v   abort, deterministic, no mutation
                                   ABORT RECEIPT: observed set + divergence proof
                                            |
                                            v   advisory widened claim (no authority)
                                   budgeted, priced retry ... cooldown on exhaustion

Figure 3 - "Not blind retry": a controlled learning loop that is deterministic, economic, anti-spam and evidence-producing.

The paper's own summary is the right one: "This is not blind retry. It is a controlled shadow-causality learning loop: deterministic (same abort everywhere), economic (each iteration pays), anti-spam (budgeted and cooled down) and evidence-producing." The FxCell and FxVM dossiers describe the declared access it depends on.

Capsules: finality that carries its refusals

The capsule is where the objects meet. In the Yellow Paper's formal objects it is the finality surface - epoch, state root, receipts root, data-availability root, denial root, coherence roots and a certificate - and after a capsule certificate "history is irreversible; a correction is a new claim, never a rewrite". The denial root is a chained commitment over the machine-evaluated no-authority invariants of the epoch, committing the previous root and the genesis denial certificate, so that "any third party verifies what this chain could never do since genesis by replaying denial roots alone"; committing the versioned catalogue of the judge alongside the verdicts is what the papers call proof-engine continuity. The FxBlock dossier treats the capsule in depth; here it matters as the object that makes every other object final without letting any of them be forgotten.

   capsule (finality surface)
   +----------------------------------------------------------+
   | state root        receipts root       DA root             |
   | denial root  <----- chained to the previous root and to   |
   |                     the genesis denial certificate        |
   | coherence roots   certificate (quorum)                    |
   +----------------------------------------------------------+
   invalid if any invariant verdict fails or is missing

Figure 4 - The capsule: results, receipts, availability and refusals under one certificate.

Two things the direction says a capsule is not: it is not final by itself - finality is a certificate attached by consensus, so the deterministic construction can be exercised before validators exist - and it is not legal settlement, which brings us to the law the objects exist to protect.

Settlement truth: three layers and six laws

The architecture programme refuses to let one receipt carry the complete financial picture. It splits settlement into a runtime settlement receipt (what the protocol executed and finalised), an external settlement claim (what an external rail, a bank or a custodian asserts), and a settlement-truth projection (the reconciled view an institution reads) - and it binds them by laws no object may compress:

   EXECUTED                 !=  FINALIZED
   FINALIZED                !=  EXTERNAL_RAIL_DELIVERED
   EXTERNAL_RAIL_DELIVERED  !=  LEGAL_EFFECT
   LEGAL_EFFECT             !=  ECONOMIC_COMPLETION
   MISSING_EVIDENCE         !=  FALSE
   INSTRUMENT_ERROR         !=  DOMAIN_FAILURE

Figure 5 - The non-compression laws. A receipt states what its plane established and nothing beyond it.

Two further objects serve the same law. Shadow receipts record what a powerless twin would have done, with zero canonical effect, so that a future power class can be judged on evidence before it acts. Lineage commitments let a receipt bind compact commitments to the policy and the authority under which it was produced, so that an auditor can ask why a rule was active at a coordinate and walk the amendment lineage without modifying historical bytes; with bitemporal coordinates - when something was valid, and when the system knew it - a correction can be recorded without pretending it was always known.

What these objects do not do

• They do not exist on a network. The local line emits receipts in a harness; everything else is design.
• A receipt does not imply finality; a capsule does not imply legal effect; a denial does not disclose the claim it refused.
• Refusal is never an amplification vector: the cheap tier seals nothing.
• Shadow receipts have zero canonical effect by definition.
• None of them compresses the six laws into a flag.

Verdict

The evidence objects are the protocol's answer to a question most systems never ask: what, exactly, are we willing to say happened? A receipt says what execution observed. A denial says what was refused and under which invariant, publicly by class and privately in detail. An abort receipt says what execution touched without permission and what it would take to try again. A capsule says all of it at once, with the refusals sealed beside the results and chained back to genesis. On the local line only the first exists, in the smallest form that can already derive a root; the rest is direction. But the law they serve is already the line's oldest habit: the first era was named for denial, and every organ since has been described first by what it refuses.

Frequently asked questions

Is a denial just an error code?

No. An error code is an implementation detail; a sealed denial is a typed protocol result with a public reason class, claimant-scoped detail and an invariant it names. Only claims past the admissibility threshold receive one; cheaper refusals are unsealed on purpose.

Why not seal every refusal?

Because sealing costs, and a refusal that cost the protocol more than the attacker would be an amplification vector. The cheap tier - syntax, signature, replay - refuses at near-zero cost without an object.

What is the difference between a denial and an abort?

A denial refuses a claim before execution, under an invariant. An abort stops an execution that touched state it had not declared, with nothing mutated and the observed set sealed so that the next attempt can declare it.

Does a capsule mean my transaction is settled?

It means the consensus result is certified for the declared plane. Whether an external rail delivered, whether a legal effect followed and whether the economic transaction completed are separate facts under the non-compression laws, and a capsule never claims them.

What exists today?

Receipts on the local line - one per cell, sealed, the input to the state root - and typed refusals at every organ boundary. Sealed denial receipts, abort receipts, denial roots and capsules are design.

Sources and methodology

Drawn from the receipt, block and state specifications of the local line, the era and power map, the Yellow Paper's formal objects, admissibility kernel, abort lifecycle and consensus semantics, the White Paper's laws and inventions, and the architecture programme's chapter on receipts, denials, conflicts and settlement truth. Implementation claims are limited to what the specifications describe as implemented; design claims are attributed and carry the status research.

The specifications and the papers are not published on this portal and are not reproduced here; object names are reported as the shape of the design, and their grammars are not. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.

Related reading: FxVM for receipts as emitted; FxCore for admissibility; FxBlock for the capsule in depth; Three planes for the planes that own receipt families.