Skip to content

feat: ZK-SNARK proof system for Benford compliance on-chain attestation #358

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Inkman007 merged 2 commits into from
Jun 30, 2026
+382 −17
Merged

feat: ZK-SNARK proof system for Benford compliance on-chain attestation #358

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
018a5c6
feat: implement ZK-SNARK proof system for Benford compliance attestat…
joel-metal Jun 30, 2026
a886818
Merge branch 'main' into feature/issue-194-zk-benford
Inkman007 Jun 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 17 additions & 14 deletions docs/zk_attestation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,28 +1,31 @@
# zk Attestation Design
# ZK Attestation Design

This repository now supports a V1 hash-commitment flow for on-chain score submissions.
This repository supports two attestation tiers for on-chain score submissions.

## V1
## V1 — Hash Commitment

The attestor computes three public values from the wallet submission:

1. `trade_data_hash` from a canonical serialization of the public trade set.
2. `model_version_hash` from the model parameters committed at deployment time.
1. `trade_data_hash` — SHA-256 of the canonical serialisation of the public trade set.
2. `model_version_hash` — SHA-256 of the model parameters committed at deployment.
3. `commitment = SHA-256(wallet, trade_data_hash, model_version_hash, score)`.

The contract client can submit the usual `RiskScore` fields plus the commitment metadata. The raw `submit_score` method remains available as a fallback when attestation is not required.
The contract client submits the `RiskScore` fields plus the commitment metadata.
Re-running the same computation over the same trade set yields the same receipt
(deterministic because trade rows and columns are canonicalised before hashing).

## Reproducibility
## V2 — Benford MAD ZK Proof (Issue #194)

The commitment is deterministic because trade rows and columns are canonicalized before hashing. Re-running the same score computation over the same trade set yields the same receipt.
High-risk scores (> 70) include a `BenfordZKProof` in the alert payload.
The proof attests — without revealing trade amounts — that the claimed MAD against
Benford's expected distribution was computed correctly.

## V2 zkVM path
### Circuit Statement

Future Risc Zero integration should keep the same public receipt shape, but replace the hash-commitment builder with a guest program that consumes:
> Given trade amounts x₁, …, xₙ (committed to Merkle root R), the MAD of
> leading-digit frequencies from Benford's expected distribution equals the
> claimed value v, within ±0.001 tolerance.

- `wallet`
- `trade_data_hash`
- `model_version_hash`
- `score`
### Proof System

The guest should emit the public receipt values above and a proof artifact that Soroban can verify before accepting the attested score.
Loading
Loading