If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/spaceandtimefdn/sxt-proof-of-sql shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit 3w ago
• 3 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 84% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live spaceandtimefdn/sxt-proof-of-sql repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/spaceandtimefdn/sxt-proof-of-sql.

What it runs against: a local clone of spaceandtimefdn/sxt-proof-of-sql — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in spaceandtimefdn/sxt-proof-of-sql | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 51 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of spaceandtimefdn/sxt-proof-of-sql. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/spaceandtimefdn/sxt-proof-of-sql.git
#   cd sxt-proof-of-sql
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of spaceandtimefdn/sxt-proof-of-sql and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "spaceandtimefdn/sxt-proof-of-sql(\\.git)?\\b" \\
  && ok "origin remote is spaceandtimefdn/sxt-proof-of-sql" \\
  || miss "origin remote is not spaceandtimefdn/sxt-proof-of-sql (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "crates/proof-of-sql/Cargo.toml" \\
  && ok "crates/proof-of-sql/Cargo.toml" \\
  || miss "missing critical file: crates/proof-of-sql/Cargo.toml"
test -f "crates/proof-of-sql-planner/src/lib.rs" \\
  && ok "crates/proof-of-sql-planner/src/lib.rs" \\
  || miss "missing critical file: crates/proof-of-sql-planner/src/lib.rs"
test -f "crates/proof-of-sql-benches/src/main.rs" \\
  && ok "crates/proof-of-sql-benches/src/main.rs" \\
  || miss "missing critical file: crates/proof-of-sql-benches/src/main.rs"
test -f ".github/workflows/lint-and-test.yml" \\
  && ok ".github/workflows/lint-and-test.yml" \\
  || miss "missing critical file: .github/workflows/lint-and-test.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 51 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~21d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/spaceandtimefdn/sxt-proof-of-sql"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Proof of SQL is a cryptographic proof system that enables verifiable SQL query execution over encrypted or private data using zero-knowledge proofs built on top of the Arkworks elliptic curve libraries (supporting BLS12-381, BN254, Curve25519). It allows a prover to prove that a SQL query was executed correctly on specific data without revealing the underlying data to the verifier. Monorepo of four crates: crates/proof-of-sql/ contains the core proving engine; crates/proof-of-sql-benches/ provides performance benchmarking with Jaeger tracing support; crates/proof-of-sql-planner/ includes runnable examples (albums, avocado-prices, books, brands) demonstrating query planning; crates/powers-of-tau-util/ handles cryptographic setup. Build configuration in .cargo/config.toml and Cargo workspace resolver 2 manages dependencies.

Blockchain developers and cryptographers building privacy-preserving data platforms; specifically those integrating with Space and Time's decentralized data warehouse who need to prove SQL query correctness on-chain without exposing sensitive data to validators or other participants.

Actively developed but pre-release (version 0.0.0). The workspace includes comprehensive CI/CD pipelines (lint-and-test.yml, code-coverage.yml, release.yaml) and four production-focused crates (proof-of-sql, proof-of-sql-benches, proof-of-sql-planner, powers-of-tau-util), suggesting production intent. However, the 0.0.0 version tag and heavy cryptographic focus (no stable releases yet visible) indicate this is still in active R&D.

Moderate-to-high risk for production adoption. Dependencies include cutting-edge cryptography libraries (ark-poly 0.5.0, blitzar 4.3.0, halo2curves 0.8.0) that may have breaking changes; MSRV is 1.89 (very recent Rust), limiting compatibility. The monorepo structure is complex with interdependent crates. Cryptographic correctness is difficult to verify without formal audits, and the 0.0.0 version indicates API instability.

Active development on cryptographic proving and query planning infrastructure. The presence of comprehensive benchmarking crates (with scripts like run_benchmarks.py) and multiple example datasets suggests focus on performance optimization and demonstrating real-world query patterns. GitHub Actions workflows indicate continuous testing, coverage tracking, and release automation. Recent work likely centers on scaling proof generation and query planner optimization.

git clone https://github.com/spaceandtimelabs/sxt-proof-of-sql.git
cd sxt-proof-of-sql
cargo build --release
cargo test --workspace
cargo bench -p proof-of-sql-benches --bench bench_append_rows

Daily commands: No single dev server. Instead: cargo build --release for the library; cd crates/proof-of-sql-planner/examples/albums && cargo run to run a specific example; cargo test --workspace to run all tests; cargo bench -p proof-of-sql-benches to run benchmarks.

• Cargo.toml — Workspace root defining all member crates, shared dependencies (ark-* cryptography libraries, ahash), and MSRV (Rust 1.89)—every contributor must understand the monorepo structure.
• crates/proof-of-sql/Cargo.toml — Core proof-of-SQL crate definition; all cryptographic and proof-generation logic dependencies are declared here.
• crates/proof-of-sql-planner/src/lib.rs — Planner crate entry point exposing SQL planning and query execution API; defines public interfaces for proof generation.
• crates/proof-of-sql-benches/src/main.rs — Benchmark harness entry point; demonstrates how to integrate the proof-of-SQL library and measure performance.
• .github/workflows/lint-and-test.yml — CI/CD pipeline enforcing code quality, clippy lints, and test coverage; every PR must pass these checks.
• CONTRIBUTING.md — Contributor guidelines covering commit messages, development workflow, and code standards specific to this proof system.
• README.md — Project overview explaining Proof of SQL, Space and Time's vision, and high-level architecture rationale.

Add a New SQL Aggregation Function

1. Define the aggregation logic by adding a new variant to the aggregation enum (crates/proof-of-sql-planner/src/aggregate.rs)
2. Implement proof generation for the new aggregation in the core proof module (crates/proof-of-sql/src (locate aggregation proof logic))
3. Add test cases and benchmarks for the new aggregation (crates/proof-of-sql-benches/src/utils/queries.rs)
4. Document usage in an example (e.g., extend existing example) (crates/proof-of-sql-planner/examples/space/main.rs)

Add Support for a New Data Source

1. Create a new accessor struct implementing the Accessor trait (similar to CSVAccessor) (crates/proof-of-sql-planner/examples/posql_db/csv_accessor.rs (use as template))
2. Register the accessor in the data access configuration (crates/proof-of-sql-planner/src/config.rs)
3. Add conversion logic for your data type in the conversion module (crates/proof-of-sql-planner/src/conversion.rs)
4. Create an example demonstrating the new data source (crates/proof-of-sql-planner/examples/<new_name>/main.rs)

Add a New Expression Type to the Query Language

1. Extend the expression enum with the new operation (crates/proof-of-sql-planner/src/expr.rs)
2. Implement evaluation logic in the expression evaluator (crates/proof-of-sql-planner/src/expr.rs (or separate eval module if it exists))
3. Add proof generation for the expression in the core proof system (crates/proof-of-sql/src (locate expression proof logic))
4. Write unit and integration tests, add benchmark if performance-critical (crates/proof-of-sql-benches/src/utils/queries.rs)

Create a New Example Dataset & Query

1. Create a new example directory with CSV data files (crates/proof-of-sql-planner/examples/<dataset_name>/<dataset>.csv)
2. Write the example main.rs demonstrating your use case (crates/proof-of-sql-planner/examples/<dataset_name>/main.rs)
3. Optionally add a README explaining the example (crates/proof-of-sql-planner/examples/<dataset_name>/README.md)
4. Run and test with cargo run --example <dataset_name> ((verification step))

• Arkworks (ark-bls12-381, ark-bn254, ark-curve25519) — Provides battle-tested elliptic curve cryptography and proof generation primitives necessary for zero-knowledge proof construction.
• Apache Arrow (RecordBatch) — Efficient columnar in-memory data format enables fast vectorized proof generation and query execution.
• Rust 1.89+ with workspace monorepo — Memory-safe systems language with zero-cost abstractions; monorepo structure allows tight integration between proof system and planner without FFI overhead.
• Cargo workspaces (4 crates) — Modular architecture separates concerns: core proofs, SQL planning, benchmarking, and utilities for different execution contexts.
• Jaeger tracing — Distributed tracing enables performance profiling and bottleneck identification in complex proof generation pipelines.

• Proof generation happens synchronously in query execution path

  • Why: Simplifies semantics and ensures proof freshness with data at query time.
  • Consequence: Query latency grows with proof complexity; large datasets may require asynchronous or streaming approaches.

• Separate planner crate from core proof

  • Why: undefined
  • Consequence: undefined

Rust version pinning: MSRV 1.89 is very recent; many CI environments may have older Rust. Cryptographic setup: The crates/powers-of-tau-util/ crate suggests proving schemes require pre-computed cryptographic parameters (Powers of Tau ceremony); these may not be bundled and must be fetched or generated separately—check for required environment variables or setup scripts. DataFusion compatibility: arrow 51.0.0 and datafusion 38.0.0 are specific minor versions; minor version bumps may break query planning. No stable API yet: Version 0.0.0 means breaking changes are expected; don't assume public function signatures are stable across branches.

• Polynomial Commitments — The core cryptographic primitive enabling Proof of SQL; you must understand how polynomial commitments allow proving correct polynomial evaluation without revealing the polynomial to grasp the entire system.
• Zero-Knowledge Proofs (ZKP) — Proof of SQL is fundamentally a ZK proof system; understanding the prover-verifier model and what 'zero-knowledge' guarantees mean is essential to using and debugging this library.
• Elliptic Curve Cryptography (BLS12-381, BN254, Curve25519) — This repo supports three different elliptic curves (selectable via Cargo features or build config); each has different security, proof size, and performance tradeoffs you must choose among.
• Columnar Data Format (Apache Arrow) — Queries operate on Arrow columnar data via DataFusion; inefficient column access or serialization can bottleneck proof generation, so understanding Arrow's layout is critical for performance.
• Query Planner / Logical Plan Optimization — DataFusion converts SQL to logical plans that feed into the prover; understanding the planner's optimization decisions (pushed predicates, projection pushdown, join ordering) affects proof size and proving time.
• Powers of Tau (Ceremony) — The powers-of-tau-util crate suggests this system uses structured reference strings from powers-of-tau ceremonies; you must understand the trust assumptions and how to source or validate these parameters.
• Sumcheck Protocol — A key interactive protocol for proving polynomial identities in ZK; likely used internally by Blitzar optimizations in this repo for efficient multivariate polynomial proofs.

• arkworks-rs/arkworks — Core dependency; the Arkworks elliptic curve and polynomial commitment libraries that underpin all proof generation in this repo.
• apache/arrow-rs — Upstream columnar data format library used by DataFusion; critical for understanding how query data is represented internally.
• apache/datafusion — Query planner and execution engine (version 38.0.0 pinned); the layer that translates SQL to logical plans before proof generation.
• spaceandtimelabs/sxt-explorer — Likely the companion dapp/frontend for Space and Time; users of this proof system would integrate with it for end-to-end workflows.
• privacy-scaling-explorations/zk-sql — Related ZK + SQL research in the ecosystem; different approach but overlapping problem domain for reference and architectural comparison.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for proof-of-sql-planner examples

The planner crate has 10+ example binaries (hello_world, albums, avocado-prices, books, brands, census, countries, dinosaurs, dog_breeds, plastics) but there are no visible integration tests validating they execute correctly. This would catch regressions when the core proof-of-sql API changes and provide documentation of expected behavior.

• [ ] Create crates/proof-of-sql-planner/tests/integration_tests.rs
• [ ] Add test functions that execute each example's main() or equivalent logic
• [ ] Validate output against expected results (e.g., query counts, schema validation)
• [ ] Add test data fixtures in crates/proof-of-sql-planner/tests/fixtures/
• [ ] Update CI workflow .github/workflows/lint-and-test.yml to run integration tests

Add benchmarking coverage for proof-of-sql core query operations

The proof-of-sql-benches crate exists with benchmark infrastructure (Cargo.toml, scripts/run_benchmarks.py, Jaeger setup), but only has bench_append_rows.rs. Core operations like proof generation, commitment verification, and filter/aggregate operations lack performance baselines. This helps track performance regressions during development.

• [ ] Create crates/proof-of-sql-benches/benches/bench_proof_generation.rs for core proof operations
• [ ] Create crates/proof-of-sql-benches/benches/bench_verification.rs for verification performance
• [ ] Create crates/proof-of-sql-benches/benches/bench_query_operations.rs for filters/aggregations
• [ ] Add benchmark result logging/comparison in scripts/run_benchmarks.py
• [ ] Document expected performance targets in crates/proof-of-sql-benches/src/README.md

Add missing documentation for arithmetic and polynomial operations

The repo has cryptographic operations (Arkworks curves, Halo2, polynomial proofs) but lacks module-level documentation explaining core mathematical concepts. New contributors struggle understanding the proof system. Adding doc comments and a mathematical overview would lower the barrier to entry.

• [ ] Create crates/proof-of-sql/src/ARCHITECTURE.md explaining proof system design
• [ ] Add /// doc comments to major modules (arithmetic.rs, polynomial.rs, etc.) in crates/proof-of-sql/src/
• [ ] Add examples in doc comments showing how to use core APIs (e.g., field operations, commitments)
• [ ] Create crates/proof-of-sql/examples/basic_proof.rs demonstrating minimal proof generation
• [ ] Update crates/proof-of-sql/README.md with links to mathematical background resources

• Add integration tests for crates/proof-of-sql-planner/examples/ beyond CSV loading—verify proof correctness for queries on the brands, albums, avocado-prices, and books datasets; currently only main.rs examples exist without assertion-based tests.
• Document the cryptographic setup requirements for crates/powers-of-tau-util/—the binary exists but README.md is missing; clarify what Powers of Tau parameters must be pre-generated, where they're expected, and provide a setup script or container instructions.
• Add benchmarks comparing proof generation time vs. row count for different elliptic curves (BLS12-381 vs. BN254 vs. Curve25519)—crates/proof-of-sql-benches/scripts/run_benchmarks.py exists but no systematic curve comparison is visible; this would validate performance claims.

The Proof of SQL codebase demonstrates good security practices with workspace organization and explicit dependency management. However, there are several areas of concern: (1) The use of an RC version for bincode, a serialization critical to proof systems, (2) Exact pinning of cryptographic and time-related dependencies without documented audit procedures

• Medium · Pinned but Outdated Cryptographic Dependencies — Cargo.toml (workspace.dependencies). The project uses pinned versions of cryptographic libraries (ark-bls12-381 0.5.0, ark-bn254 0.5.0, ark-curve25519 0.5.0, ark-ec 0.5.0, ark-ff 0.5.0, ark-poly 0.5.0). While pinning is good for reproducibility, these versions should be regularly audited for security patches. The arkworks ecosystem may have critical security updates available. Fix: Establish a regular dependency audit schedule (monthly or quarterly). Use cargo audit in CI/CD pipeline to detect known vulnerabilities. Consider using cargo-deny for dependency policy enforcement.
• Medium · RC (Release Candidate) Dependency in Production — Cargo.toml (workspace.dependencies - bincode). The project uses bincode = 2.0.0-rc.3, which is a release candidate version. RC versions are not stable and may contain bugs, breaking changes, or undiscovered security issues that could affect serialization/deserialization operations critical to proof systems. Fix: Upgrade bincode to the stable 2.0.0 release once available, or consider using the latest stable 1.x version if 2.0.0 stable is not yet released. Ensure comprehensive testing of serialization operations after upgrade.
• Medium · Exact Version Pin on chrono Without Security Review — Cargo.toml (workspace.dependencies - chrono). The project pins chrono = 0.4.39 exactly. Chrono has had timezone-related security vulnerabilities in the past. The exact pin prevents automatic security updates unless manually bumped. Fix: Consider using chrono = "0.4" to allow patch version updates automatically. Monitor chrono security advisories and use cargo update chrono when security patches are released.
• Medium · High MSRV (Minimum Supported Rust Version) at 1.89 — Cargo.toml (workspace.package - rust-version). The MSRV is set to 1.89, which is a very recent Rust version. This may exclude users on stable Rust versions and could limit security scrutiny from a broader community. Additionally, the comment mentions home 0.5.12 dependency concerns. Fix: Consider lowering MSRV to a more stable LTS version (e.g., 1.70 or 1.75) to allow broader community use and security review, unless there are specific technical requirements for newer Rust features.
• Low · Missing Security Policy — Repository root (missing SECURITY.md). No SECURITY.md file is visible in the repository root, which is a best practice for handling security vulnerabilities responsibly. Security researchers may not know how to report vulnerabilities privately. Fix: Create a SECURITY.md file in the repository root documenting: how to report security vulnerabilities, expected response timeline, whether you offer bug bounties, and any responsible disclosure policies.
• Low · No Visible Dependency Lock File — Repository structure. While Cargo.lock management is implicit in Cargo, the absence of explicit lock file management documentation in the repository structure could lead to reproducibility issues in CI/CD environments. Fix: Ensure Cargo.lock is committed to version control for all crates that produce binaries. Include clear documentation in CONTRIBUTING.md about lock file usage.
• Low · Default Features Disabled on Multiple Dependencies — Cargo.toml (workspace.dependencies). Several dependencies have default-features = false (ahash, ark-std, arrayvec, bincode, byte-slice-cast), which is good for supply chain security but requires careful verification that essential security features aren't disabled. Fix: Document why default-features are disabled for each dependency. Review each dependency's security-critical features to ensure none are inadvertently disabled. Add comments in Cargo.toml explaining the rationale.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.