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
THE IDEA, MADE VISIBLE
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
What this paper is really saying.
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.
The paper’s technical details matter, but the basic route can be understood in three moves.
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
The useful takeaways.
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
What this does—and does not—establish.
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 report develops a conditional method and evaluates it within the stated evidence. It does not establish production performance, operational safety, or calibrated real-world predictive skill beyond that evidence.
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 anyone should care.
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
The vocabulary, decoded.
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.
The strongest review is not a general reaction. It tests the steps most capable of changing the conclusion.
- 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
Go from explanation to evidence.
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.