HEGEMON
v0.11 PRE-MAINNET · VERIFICATION SCOPE

What verification establishes

A passing result means the listed checks completed on the identified block bytes. Hidden amounts stay private. The proof system’s assumptions still apply.

An additional check on public data

The explorer checks public data separately from the node and runs a configured released Hegemon verifier on private-spend proofs. This can reveal skipped checks, inconsistent data and some implementation failures.

It uses the released cryptographic implementation. A forged proof that passes that verifier, or a missing constraint in the shared relation, can also pass the explorer. Rechecking enforces existing rules; it does not increase the proof system’s soundness.

Read a result together with its block hash, checked height, check list and verifier identity. Missing data, disabled verification, timeouts and crashes are not passing results.

The checks behind a passing status

“Public checks passed” covers the contiguous indexed history from genesis to the displayed checked block. This is the configured node’s reported canonical view. The observer does not independently choose the winning chain.

Selected checks and their limits
CheckWhat is tested
Action encoding and identitySupported action framing and the selected network and proof identity.
Private-spend referenceThe reference block hash and permitted age of 0–12 blocks. The note root is not reconstructed.
NullifiersNo repeated public nullifiers across the complete indexed prefix.
Reward accountingPublic reward amounts and allocation follow the permitted subsidy-plus-fees rules.
Private-spend proofThe SHA-pinned released binary verifies the exact 688-byte statement and proof, with ciphertext binding checked.

These checks do not independently reconstruct the note root, header hash, proof of work, difficulty adjustment or supply_digest. A per-block result covers that block; the global result also requires a complete checked prefix. Unknown or incomplete coverage never means passed.

ASSUMPTIONS · IN PRACTICAL ORDER

What a passing result relies on

1. The executable implements the intended rules

The verifier must match the intended release and relation. Its parser, arithmetic, compiler and platform must behave correctly. Source review, checksums and fixture tests provide evidence, but are not a proof about every possible native execution.

The explorer adds a separate execution of public checks. It does not supply an independently implemented proof system or a complete proof that native bytes and execution match the Lean model.

Declared implementation, compiler and serialization assumptions ↗

2. The cryptographic assumptions hold

The proof model treats SHA-512 as an ideal oracle that can also receive quantum queries. Real SHA-512 is a fixed algorithm. The model also assumes bounds on the exact primitive attacks used in the native authorization argument, including attacks on commitments and their domains.

BLAKE2b implementation and commitment binding remain separate assumptions. A verifier cannot reliably diagnose a successful attack on the assumptions it uses to accept proofs.

Native failure theorem and its explicit primitive-game hypotheses ↗

The seven primitive attacks, in plain language

This list belongs to the inherited native Final-authorization argument. It is not every assumption for the current 86-word proof or the entire product; current source binding is also required. An accumulator is a note recording policy approvals, not a supply counter.

  1. Change a note without changing its commitment. Find different canonical 18-word note payloads with the same NOTE hash. Note-collision predicate ↗
  2. Change a tree node’s children without changing its hash. Find different ordered child-digest pairs with the same COMPFF node hash. Merkle-collision predicate ↗
  3. Make an ordinary output look like approval state. Match an ordinary recipient’s owner digest to an accumulator owner. The recipient can be an arbitrary canonical digest; the game does not assume a known secret-key preimage. Ordinary-recipient / accumulator predicate ↗
  4. Make locked value look like approval state. Match a value-note owner digest to an accumulator owner. Value / accumulator predicate ↗
  5. Substitute different approval state. Find different accumulator credentials, signer policy, intent or approval bits with the same owner digest. Accumulator-collision predicate ↗
  6. Confuse approval state with a hash/time lock. Match an accumulator owner to an HTLC owner. Accumulator / HTLC predicate ↗
  7. Make the known-empty placeholder look like approval state. Match an accumulator owner to the exact public SINGLE hash of [1,0,0,0,0,0,0]. This is a fixed known target, not a zero digest or secret. Known-empty-target predicate ↗

The proof derives that its unauthorized-Final event is covered by these attacks. Small attack probabilities are explicit inputs to the theorem, not proved cryptanalysis or explorer measurements. Its games and remaining hypotheses require the individual bounds and their combined allowance.

3. The resource bounds include offline work

One oracle query is a modeled request for a hash result, including quantum queries. A single proof needs many queries. The budget covers the whole modeled history: other hash work, proof generation, verification and diagnostic traces, including failed and unused attempts.

For example, generating one proof and checking it on five nodes charges one generation and five verifications. Discarding a failed proof still uses the budget. An adversary’s offline work is not visible in a block explorer.

Transaction counts, chain height and restarts do not establish those bounds. The ongoing HGN route has no automatic chain expiry or accepted-proof quota; its security statements remain conditional on finite resources.

Exact resource class and source

Total oracle queries: at most 3 × 2^64, about 55 quintillion. Other-query allowance: 2^65. Proof, verification and trace attempts: at most 2^39 each, about 550 billion in each category.

The accounting multiplies each attempt count by its conservative per-attempt query cost, then adds the other queries. The arithmetic showing those allowances fit is proved. Whether real software and adversaries remain in that class is a condition, not a live measurement.

What the query accounting includes ↗

ResourceClass and source_inclusive_resource_bound ↗

4. Native data must match the formal model

The engineering assumption is that real note tables, append positions, historical roots and serialized inputs have their stated formal interpretation. The native-data interface supplies chronological data; it does not assume that a spender is authorized.

Inside the model, matching the proof producer, decoded assignment and history is derived, or the corresponding failure is accounted for. The same-source witness is a proved conclusion under the theorem’s hypotheses. It is not an extra assumption that “everything is valid,” and does not give the explorer a practical way to extract private amounts.

What the native-data interface supplies ↗

Accepted-source result ↗ · Native-history result ↗

5. Privacy has its own conditions

The privacy argument assumes honest proofs from valid private inputs, the prescribed independent randomness, and the same well-formed initial state chosen before the oracle. Earlier oracle work must be included and charged.

It also uses an external mathematical bound on how much an observer can notice the public simulator changing selected oracle answers as requests evolve. This is the adaptive-reprogramming premise. Continuation queries, failed requests and errors remain part of the comparison.

The explorer does not test these conditions. Privacy and soundness are separate mathematical games; their individual bounds do not automatically form a combined security guarantee.

Initialized public comparison ↗ · Persistent-history comparison ↗ · Ongoing specialization ↗

6. The observer has the right chain data

Results depend on the configured RPC source, local index and verifier executable. The observer can lag behind the chain. A reorganization changes which blocks are canonical and invalidates affected results.

An RPC source can withhold a competing chain. This service does not independently establish global chain selection or audit every consensus rule. An accounting or proof check does not imply that proof of work, difficulty adjustment and every state root were independently recomputed. The displayed coverage defines the claim.

Proved facts and supplied hypotheses

Lean checks that the conclusion follows from the stated inputs. It does not make every input a fact about deployed software or an adversary.

Logical axioms are different from security hypotheses. Even an axiom audit with no extra project axioms would not remove a theorem’s explicit cryptographic inputs. This explorer performs no new Lean kernel or axiom audit.

Supply accounting is not a public balance total

The subsidy schedule limits authorized issuance. Hidden note conservation additionally relies on proof soundness, correct admission and the history assumptions above. Fees move existing value; they do not create new HGN.

The chain’s supply_digest is fee-inclusive gross accounting. It is not hidden circulating supply. The explorer can recompute public accounting; it cannot add up amounts concealed inside note commitments.

blockSubsidy_finset_sum_le_cap ↗ · net_new_is_subsidy ↗

Exact release and theorem scope

The current software release is v0.11.4. These existing explorer checks remain pinned to public source tag v0.11.2. Its private-spend route is the 86-word BoundedPolicy.CompFF01.Packed.v4 relation, circuit 12, with HGPSLC02 carriers and compact SMZL/q38 proofs.

The linked 77-word SMZD/q58 and RP05 results are inherited evidence with their own identities. They do not independently certify the current 86-word bytes. The current source binding and qualification must also hold.

Referenced proof-release identity ↗ · Current and historical scope ↗ · Source qualification checks ↗

Named theorem entry points

The numbers in theorem names describe their stated conditional bounds. They are not an unconditional rating for the deployed system.

Frozen tag commit: 15c42e687b24d9cb35bb6dbde6061459d6f1242a.

Reproduce a proof check

The packaged node can verify a public statement and proof offline, without opening chain state or connecting to peers. Use the exact extracted bytes and record which binary you ran.

hegemon-node verify-private-spend --statement statement.bin --proof proof.bin

That command checks the cryptographic backend. Inclusion, reference freshness, nullifier uniqueness and public reward accounting need separate chain-context checks.

Released offline verification instructions ↗

← Return to the explorer