Bind the exact artifact
Canonicalize and hash the configuration so every proof and signature refers to the same bytes.
← All researchMF-PRISM-DLT-2026-07 / interactive guide
INTERACTIVE RESEARCH GUIDE
Let the configuration carry its evidence.
Change an artifact and watch the first failed verification gate block activation.
Research reportPCQC: Proof-Carrying Quorum Certificates for Federated Consensus Networks
Bind evidence to exact bytes
A certificate must refer to the configuration actually being activated. This teaching fixture compares serialized bytes; it does not perform a cryptographic signature check.
- Artifact epoch
- 4
- Checks satisfied
- 3 / 4
- Activation
- Blocked
Activation stops at “Exact bytes”. Later gates cannot override that failure.
Activate ⇔ bound bytes ∧ authorized ∧ current epoch ∧ structural check
TRY THIS
Try each fault scenario. Notice that fixing one gate does not waive the remaining checks.
What this experiment represents. Illustrative gate logic with byte equality, fixed authorization fixtures, epoch comparison and a uniform-quorum predicate. No real signatures, cryptographic proof verification or production activation is performed.
Distributed Systems · Research Paper
PCQC: Proof-Carrying Quorum Certificates for Federated Consensus Networks
Machine-verifiable safety, transition, fault-domain, and availability evidence for Gravity
Research reportMF-PRISM-DLT-2026-07 / v0.2
Distribute network configurations with checkable structural evidence, authorization and freshness state. The reference verifier rejects specified adversarial changes; the result remains conditional on sound proof kernels and correct artifact binding.
- Identifier
- MF-PRISM-DLT-2026-07
- Series
- Distributed Systems
- Edition
- Version 0.2
- Length
- 23 pages
- Reserved DOI
- 10.5281/zenodo.22728326 (record reserved)
01
Plain-language guide
3 minute explanation
A plain-language summary.
The paper packages a quorum configuration with machine-checkable safety evidence, authorization, freshness, and rollback data so a validator can verify the change before activating it.
proof-carrying configurationfederated consensusverification
Configuration review is often a human process: someone inspects a file, approves it, and distributes it. That leaves room for stale, altered, or incompletely justified changes.
PCQC proposes a proof-carrying artifact. The exact configuration bytes are bound to certificates for structural safety, transitions, fault domains, and availability, plus governance signatures and freshness state. A reference verifier rejects artifacts that fail those checks.
02
How it works
The argument, without the notation.
Attach proof kernels
Include independently checkable evidence for quorum intersection, transition safety, fault-domain policy, and availability assumptions.
Gate activation
Verify authorization, freshness, rollback rules, and proof results before the validator accepts the new configuration.
03
What it adds
Main findings.
Safety claims travel with the configuration instead of living only in a review document.
Exact byte binding prevents a valid certificate from being reused for altered contents.
The reference verifier rejects the specified stale, unauthorized, or structurally invalid adversarial changes.
04
Scope & limits
Evidence and limitations.
Current status
Certificate architecture and executable reference verifier. Signing keys are deterministic test fixtures; the checker is not formally verified and no production Gravity validator has enforced the proposed gate.
This paper proposes network configurations that carry their own checkable proofs. In testing with research keys, the reference verifier rejects the specified attacks; no production validator enforces it yet.
The signing keys are deterministic test fixtures, not production governance keys.
The verifier and its proof kernels are not formally verified.
No production Gravity validator has enforced the proposed activation gate.
05
Why it matters
Why this research matters.
Proof-carrying configuration turns governance and safety claims into artifacts a validator can check, rather than relying only on human review or unsigned configuration files.
06
Key terms
Terms used in this paper.
These are the terms needed to understand the claim. The full paper uses them more precisely.
Proof-carrying configuration
A configuration bundled with evidence that a machine can check before use.
Proof kernel
A small checker responsible for validating one class of certificate.
Byte binding
Cryptographically tying evidence to the exact serialized contents of an artifact.
Freshness
Evidence that an artifact is current enough and not an old configuration being replayed.
07
Independent review
Where scrutiny should concentrate.
- 01Soundness of each implemented proof kernel.
- 02Exact byte binding, governance roles, rollback and activation.
- 03Research signing keys, metadata truth and scaling beyond exact replay.
Publication record
Read the paper and examine the source files.
This page is a reading guide, not a substitute for the manuscript. The public record links the explanation to the paper, source package, review materials, and persistent identifier.
- Document
- Research Paper
- Review status
- Open for independent review
- Published
- 2026-09-12
- DOI status
- Reserved · 10.5281/zenodo.22728326
- Canonical record
- MF-PRISM-DLT-2026-07
Metriq PRISM Laboratory, PCQC: Proof-Carrying Quorum Certificates for Federated Consensus Networks, Metriq PRISM Laboratory Research Paper MF-PRISM-DLT-2026-07, Version 0.2, 2026. Corresponding contributor: Daniel H. Jeffery, ORCID 0009-0001-1200-6042. DOI: 10.5281/zenodo.22728326.