Verifiable Private Genomic Computation Stream

DSWS Hackathon

July 20–21, 2026 · 8:00–12:00 ET both days

A two-day blue-sky exploration of what zero-knowledge cryptography could unlock for genomic data sharing.

Monday · July 20 · stream 9:10–11:30 ET

Day 1 Agenda

Tuesday · July 21 · stream 8:20–11:00 ET

Day 2 Agenda

Day 1 · 9:10–9:22

Introductions

“Tell us your name, where you're coming from, and a funny or frustrating data-sharing story — bureaucracy you've had to deal with, something that felt impossible, something that made you laugh or cry.”

Day 1 · 9:22

Why we're here

Three parts

Concept walkthrough

Day 1 · ~5 min · the one thing you need to understand

ZK intuition

From a game to a zkVM

While the claim in the gem game is basic, a zero-knowledge virtual machine (zkVM) expands the concept to allow running real programs: you run ordinary code over private inputs and publish a short proof that the claim is true.

That means the guest can verify other cryptographic primitives inside the proof — ed25519 signatures, Merkle inclusion, hashes — then run a computation (a GWAS filter, a risk score, a panel check) and commit only the public result.

Here's an example of what a program looks like.

// Illustrative SP1 guest (Rust → RISC-V zkVM)
// Private inputs never leave the proof; only the claim is public.
#![no_main]
sp1_zkvm::entrypoint!(main);

fn main() {
    // ── private inputs (not revealed to the researcher) ──
    let snps: Vec<Snp> = sp1_zkvm::io::read();
    let merkle_proof: MerkleProof = sp1_zkvm::io::read();

    // ── public inputs (known to patient and researcher) ──
    let vcf_merkle_root: [u8; 32] = sp1_zkvm::io::read(); // commitment to a merkleized VCF
    let targets: Vec<Variant> = sp1_zkvm::io::read(); // panel of variants

    // ── prove the SNPs came from that committed VCF ──
    assert!(verify_merkle_proof(&snps, &merkle_proof, &vcf_merkle_root));

    // ── only then: run the claim on private data ──
    let claim = genome_has_any_variant(&snps, &targets); // bool
    sp1_zkvm::io::commit(&claim); // public output: yes/no — not the sequence
}

Inputs

Private

• snps

  [{ chr: "7", pos: 140753336, gt: "A/T" }, … 48 more]

• merkle_proof

  path from those SNPs → VCF Merkle root

Public

• targets

  [BRAF V600E, EGFR L858R, …] · panel · GRCh38

• vcf_merkle_root

  0x3a91…b0 · commitment to a merkleized VCF

Output

claim = true

Proof

sp1_proof = 0x02af91c3…

What's going on

A VCF was merkleized and committed as a public root. The patient privately supplies some SNPs plus a Merkle path that ties them to that root. Inside the zkVM the path is checked, then a simple claim runs on those SNPs. In this case, does the genome carry one of a set of target variants? The researcher only learns the public inputs, the boolean result, and a proof — never the genotype itself.

Two ZK VMs in the wild

For further reading, here are two production stacks that make this style of proving practical today:

Succinct · SP1Rust → RISC-V zkVM. Prove ordinary programs; verify the proof on-chain.Open site →Aztec · NoirNoir is a ZK language (Rust-like) used to write private apps and Aztec contracts.Open site →

Day 1 · 9:42 · ~5 min

Infrastructure picture

A mental model for how this system could work.

~9 scenes

User journey

An imagined workflow that leverages zero-knowledge cryptography.

Actors

Sarah is trying to understand whether a specific variant correlates with disease progression.

Day 1 · 9:57–10:35

Sandbox + office hour

Day 1 · 11:00–11:20

Facilitated discussion

1. 1

   Where does this approach work well — what problems is it especially well suited for?

2. 2

   Where does it break down — what assumptions are we making that won't hold in the real world?

3. 3

   What would need to exist that doesn't yet — infrastructure, standards, tooling, policy?

4. 4

   What other opportunities do you see here?

Day 1 · 11:20

Overnight prompt

If this existed at scale — 7 billion people with genotypes and phenotypes queryable – what would you use it for?

Day 2 opens with an overnight harvest (8:20–8:35) after the group lead update: everyone shares their answer while someone adds directly to the FigJam board — use cases to Use Cases, skepticism to Limitations, blockers to Infrastructure Gaps.

Day 2 · 8:35–9:45

FigJam board

Participants contribute throughout both days. Day 2's deep dive (8:55–9:45) works through the board zone by zone as a full group — organizing, debating, and filling gaps until each zone feels conclusive.

Day 2 · 10:25–10:40

Wrap + next steps