# GLYPH: A Universal Transparent Verification Layer for Heterogeneous Zero-Knowledge Proof Systems on Ethereum **Author:** Christopher Schulze **Affiliation:** Independent Researcher **ORCID:** 0009-0000-3436-8880 **Date:** 2026-02-04 (manuscript), 2026-02-26 (public release records) ## Abstract GLYPH is a transparent verification layer for Ethereum that enables trustless on-chain verification of heterogeneous proof systems by executing upstream verification inside GLYPH-Prover. Under adapter correctness and upstream assumptions, it covers pairing-based SNARKs and hash-based STARKs without requiring protocol-specific verifier contracts or any GLYPH-specific trusted setup. Imported proofs retain their original trust assumptions. The architecture combines a universal adapter framework with a packed arity-8 GKR sumcheck verifier over `p = 2^128 - 159`, producing a compact on-chain verification path. Recorded receipt-backed benchmarks report `29,450` total transaction gas for the GLYPH artifact path in the stated setup. ## 1. Why this exists Ethereum proof verification is fragmented across proving systems, encodings, and verifier contracts. GLYPH introduces a single verification boundary that: - preserves upstream trust assumptions, - reduces verifier sprawl at contract level, - keeps settlement compact and stateless on-chain. ## 2. Design goals - Transparent core without GLYPH-specific trusted setup. - One adapter boundary for heterogeneous proof families. - Chain-bound artifact model for replay resistance. - Compact on-chain verification surface with stable interface. - Explicit assumption mapping instead of hidden trust shifts. GLYPH is a verification and settlement layer, not a standalone state-transition system. ## 3. System overview ```mermaid flowchart LR A["Upstream Proof Systems<br/>SNARK (Groth16/KZG/PLONK/Halo2/SP1) / STARK / IVC / IPA / Binius / Hash"] --> B["Adapter Layer<br/>Canonical receipt parsing + verification relation mapping"] B --> C["UCIR Compilation<br/>Unified constraints + statements"] C --> D["GLYPH-Prover<br/>Witness + packed arity-8 sumcheck over p=2^128-159"] D --> E["GLYPH Artifact<br/>commitment_tag, point_tag, claim128, initial_claim"] E --> F["GLYPHVerifier.sol<br/>Stateless on-chain verification"] ``` ## 4. Artifact boundary and chain binding ```mermaid flowchart TD C1["commitment_tag"] --> H["artifact_tag = keccak256(commitment_tag || point_tag)"] C2["point_tag"] --> H H --> B1["chain-bound context<br/>chainid + verifier address"] B1 --> V["On-chain checks<br/>claim bounds<br/>transcript consistency<br/>packed sumcheck verification"] ``` The artifact binding includes chain id and verifier address to prevent cross-chain replay and cross-deployment replay. ## 5. Threat model (condensed) **Adversary can:** - control prover inputs and malformed receipts, - submit adversarial calldata, - replay/reorder transactions at mempool level. **Assumed secure:** - EVM execution correctness, - Keccak256 for transcript/domain separation, - packed sumcheck soundness over `p = 2^128 - 159`, - correctness of adapter logic and canonical encodings for each supported family. ## 6. Supported families (implemented & tested) - SNARK: Groth16, KZG (BN254/BLS12-381), PLONK (gnark BN254, dusk BLS12-381), Halo2 KZG, SP1 (Groth16/Plonk BN254 receipts) - STARK: multiple canonical receipt families - IVC/Folding: transparent receipt flow - IPA - Binius - Hash adapter paths Important: wrapped systems keep their own upstream trust model. GLYPH does not convert trusted-setup systems into transparent systems. ## 7. Receipt-backed gas snapshot Recorded benchmark context (Sepolia and Hoodi receipts, same reported setup, 2026-02-02 measurements): | Path | Total tx gas | |---|---:| | GLYPH artifact-bound verification | 29,450 | | Groth16 verify (3 public inputs) | 227,128 | Approximate ratio in this setup: `~7.7x`. ## 8. Reproducibility and links Publications: - Zenodo record (primary DOI): https://zenodo.org/records/18792566 - DOI: `10.5281/zenodo.18792566` - OSF Preprint: https://osf.io/preprints/metaarxiv/z4h2w_v1 GitHub: - Code: https://github.com/Christopher-Schulze/glyph-zk - Benchmark scripts: - https://github.com/Christopher-Schulze/glyph-zk/blob/main/scripts/benchmarks/bench_glyph_sepolia_artifact.sh - https://github.com/Christopher-Schulze/glyph-zk/blob/main/scripts/benchmarks/bench_glyph_hoodi_artifact_truncated.sh - https://github.com/Christopher-Schulze/glyph-zk/blob/main/scripts/benchmarks/bench_groth16_sepolia.sh - https://github.com/Christopher-Schulze/glyph-zk/blob/main/scripts/benchmarks/bench_groth16_hoodi.sh - Benchmark outputs: - https://github.com/Christopher-Schulze/glyph-zk/tree/main/scripts/out/benchmarks - Receipt table reference (Section 14.2.1): - https://github.com/Christopher-Schulze/glyph-zk/blob/main/docs/documentation.md ## 9. What feedback is most useful 1. Adapter boundary soundness and failure modes 2. Cross-family composition assumptions 3. Benchmark comparability methodology 4. Artifact binding and replay-resistance model ## 10. Citation If you cite this work, please use the Zenodo DOI as the canonical reference: `10.5281/zenodo.18792566`