Proof Forge System
Relevant source files
The following files were used as context for generating this wiki page:
The Proof Forge System (also referred to as ProofGate) is a comprehensive proof-based scoring and verification infrastructure designed to validate the mainnet readiness of the X3 Chain. Unlike traditional percentage-based progress tracking, Proof Forge operates on the principle of "No proof = no points," requiring observable, reproducible evidence for every feature claim within the project. It provides a structured framework for auditing code integration, testing, observability, and recoverability.
The system's scope includes automated evidence generation through specialized shell scripts, manifest-driven requirement definitions, and an AI-assisted audit layer that utilizes specialized repository packs to perform deep technical analysis. The end goal is to provide a binary "Go/No-Go" decision based on cryptographically hashed evidence and hard-fail safety gates.
Sources: launch-gates/INFRASTRUCTURE_STATUS.md:6-14, launch-gates/COMPLETE_SYSTEM_SUMMARY.md:6-12
Core Architecture and Components
The Proof Forge architecture is divided into three functional layers: the Manifest Layer (defining the "Law"), the Execution Layer (generating evidence), and the Audit Layer (analyzing results).
Manifest Layer
The system's logic is governed by two primary configuration files:
- proofs.yaml: Catalogues 12 core features, defines the scoring rules for 8 proof tiers, and specifies the 9 hard-fail gates that can block a release.
- invariants.yaml: Lists critical blockchain properties (P0 to P2) that must hold true, such as canonical supply conservation and atomic swap rollbacks.
Sources: launch-gates/CHECKLIST_INFRASTRUCTURE_COMPLETE.md:12-24, launch-gates/COMPLETE_SYSTEM_SUMMARY.md:16-24
Execution Layer
Evidence is generated via executable scripts that interact with the Rust toolchain and the local environment:
- run-proof-commands.sh: Executes 12 specific commands (including
cargo test,clippy, and production hazard scans) to produce timestamped log files. - build-repomix-pack.sh: Packages the codebase into specialized AI-readable markdown files (packs) for targeted auditing of the bridge, runtime, and consensus layers.
Sources: launch-gates/CHECKLIST_INFRASTRUCTURE_COMPLETE.md:27-46, launch-gates/build-repomix-pack.sh:33-100
Logic and Data Flow
The system follows a strict linear progression from code execution to a final readiness decision.
This diagram illustrates the parallel tracks of automated proof execution and AI-assisted auditing that converge at the final decision point.
Sources: launch-gates/COMPLETE_SYSTEM_SUMMARY.md:118-132, launch-gates/CHECKLIST_INFRASTRUCTURE_COMPLETE.md:118-146
Proof Tiers and Scoring System
Proof Forge employs a hierarchical scoring system where a feature's score is strictly capped by its strongest level of evidence. A feature cannot claim "Testnet Proven" status without the specific integration and multi-node logs to support it.
| Level | Tier | Description |
|---|---|---|
| 10 | code_exists | Feature mentioned in docs/comments only |
| 25 | code_created | Source files present in repository |
| 35 | wired | Feature integrated into runtime/API |
| 45 | compiles | cargo check passes successfully |
| 55 | unit_tested | Core logic verified by unit tests |
| 70 | integration_tested | Full workflow verified by integration tests |
| 85 | fuzz_invariant | Chaos/fuzz testing proves resilience |
| 95 | testnet_proven | Verified on multi-node testnet |
| 100 | audit_approved | Approved by external/formal audit |
Sources: launch-gates/COMPLETE_SYSTEM_SUMMARY.md:58-69, launch-gates/INFRASTRUCTURE_STATUS.md:21-31
Hard Fail Gates
There are 9 critical "Hard Fail Gates" that must all return a "PASS" status for the system to recommend a mainnet launch. Failure in any single gate results in an overall "FAIL" status for the entire project.
- Bridge Replay Protection: Verified through
cargo test -p x3-bridge. - Atomic Rollback: Proven recovery from swap timeouts.
- Supply Conservation: Invariant checks ensuring
supply_in == supply_out. - Runtime Compilation: No errors in
cargo check -p x3-runtime. - Fresh Machine Build: Reproducibility from a clean environment.
- Multi-node Stability: Stable operation of at least 4 local validators.
- Zero Production Hazards: No instances of
panic!,unwrap(), orexpect()in critical paths. - Chain Spec Integrity: Successful generation of the genesis specification.
- Validator Reproducibility: Proven ability to launch validators from shared specs.
Sources: launch-gates/COMPLETE_SYSTEM_SUMMARY.md:44-55, launch-gates/CHECKLIST_INFRASTRUCTURE_COMPLETE.md:158-168
System Monitoring and Dashboard
The public/index.html file provides a real-time visualization of the Proof Forge status. It aggregates metrics from the evidence/ and reports/ directories to display an overall grade and readiness badges.
Metric Visualization
The dashboard tracks 20 critical modules, categorizing them into three tiers:
- Critical Chain (P7): Consensus, Custody, Asset Kernel, Bridge, Governance.
- Economic & Advanced (P5-P6): Treasury, DEX, X3VM, Flashloans, Formal Proofs.
- Infrastructure (P4-P6): Incident Response, Upgrade Safety, Social Consensus, Ecosystem Quality, Bug Bounty.
Sources: public/index.html:132-192
Dashboard Sequence
The following sequence describes how the dashboard updates its state based on automated proof completion.
This sequence shows the progression from script execution to the visual representation of blockchain health.
Sources: public/index.html:204-216, launch-gates/run-proof-commands.sh:105-125
Critical Invariants (P0 Level)
The system enforces specific P0 (Priority 0) invariants that are non-negotiable for system safety. These are defined in invariants.yaml and verified by the Proof Forge scripts.
| Invariant | Requirement |
|---|---|
| Canonical Supply | Total asset supply must be conserved across all VM transfers. |
| Atomic All-or-Nothing | Swaps must either complete fully or roll back fully with no partial state. |
| Replay Protection | Bridge messages must contain unique nonces and be rejected if replayed. |
| Hazard-Free Paths | Critical dispatchables must use saturating/checked arithmetic and avoid panics. |
| State Consistency | Lock/Unlock queues between the Bridge and Atlas Kernel must stay in sync. |
Sources: launch-gates/INFRASTRUCTURE_STATUS.md:38-49, launch-gates/COMPLETE_SYSTEM_SUMMARY.md:73-82
Implementation Details
The evidence generation process is implemented as a series of sequential checks. Below is a representation of the core command logic used to generate proofs.
# Example Proof Command Logic
# Source: launch-gates/run-proof-commands.sh
# 1. Check for Production Hazards
# Scans for unwrap/expect/panic in non-test code
rg "\.unwrap\(\)|\.expect\(|panic\!" --glob "!**/tests/**" > evidence/proof-05-hazard-scan.log
# 2. Verify Runtime Compilation
cargo check -p x3-runtime > evidence/proof-06-runtime-check.log
# 3. Verify Bridge Safety (P0 Invariant)
cargo test -p x3-bridge replay_protection > evidence/proof-07-bridge-tests.log
Sources: launch-gates/run-proof-commands.sh:45-75
Conclusion
The Proof Forge System serves as the final gatekeeper for the X3 Chain's transition to mainnet. By enforcing a "No proof = no points" philosophy and requiring cryptographically verifiable logs for all 9 hard-fail gates, the system ensures that the blockchain infrastructure is wired, tested, and observable. The integration of manifest-based laws, automated evidence generation, and AI-assisted auditing provides a high-confidence roadmap for institutional-grade deployment.
Sources: launch-gates/INFRASTRUCTURE_STATUS.md:112-118, launch-gates/COMPLETE_SYSTEM_SUMMARY.md:188-195