Power research with your genome– without sacrificing your privacy.

... without revealing any private information.

You open a letter—your premium just jumped because someone inferred serious disease risk from your DNA.

The field of genomics has come a long way in balancing the benefits of data sharing with privacy.

We've built federated networks—independently operated systems that share a common language—so patient data can stay with their trusted healthcare provider while researchers access it for approved uses.

But as the size of a federated system grows, it gets harder to maintain the level of security that sensitive health information warrants.

The system is only as secure as its least secure node.

Compromised system illustration
🔒

Data exfiltration

A breach in a node in the federation allows a malicious party to exfiltrate data. Research has surfaced the potential for membership inclusion and genome reconstruction attacks as threats that need to be addressed.

⚖️

Jurisdictional risk

Genomic research must cross national borders to capture the full diversity of the human species. Yet when nodes span jurisdictions, data can be exposed to foreign intelligence collection. In some regions, domestic law enforcement may also pressure institutions to disclose identifying information about their citizens.

🍯

Honeypot

Even within a federated network, large quantities of data concentrate inside centralized institutions making them attractive targets. Over time the expense of storing data grows, and vigilant monitoring is needed to prevent unauthorized access.

So What?

Health and research institutions are generally risk-averse. In light of these threats, they avoid opening pathways to exchange patient data, even when doing so would deliver immense public good.

At the same time, a lack of data is often cited as a major bottleneck in the advancement of genomics research.

A public permissionless complement to federated genomic networks

New cryptographic primitives have enabled novel ways of creating decentralized verifiable systems with strong privacy and data integrity guarantees.

One such technology is zero-knowledge proving systems, which enable verification of computation performed on untrusted hardware.

Here's how this could be applied to the context of genomic research:

Step One

Give patients their data

Transfer custody of a patient's raw genomic data to them via a specialized third-party service or a purpose-built hardware device with a secure enclave that they connect to their home Wi-Fi.

Step Two

Public Attestations

Institutions publish attestations (signed messages using a private key) that represent the digital fingerprint of a patient's genome and phenotype. This proves the underlying data originated from a given institution.

Notably, attestations contain no information that identifies a patient nor their associated institution.

Step Three

Zero-knowledge cryptography

Researchers use an IDE to create inquiries that run within a zero-knowledge (ZK) virtual machine. In practice these inquiries are functions that accept an array of requested alleles and phenotypes as parameters, perform arbitrary computation and return a result.

Example Code

pub fn predict(
    &self, 
    snp_data: &[SnpData],
    hpo_codes: Option<&[&str]>
) -> Result<InquiryResult, InquiryError> {
    
    let mut hpo_match = false;
    let mut hpo_confidence = 0.0;

    for model in &self.snp_models {
        ...
    }

    Ok(InquiryResult {
        hpo_match,
        hpo_confidence,
    })
}

Step Four

Publish Inquiry

The researcher publishes their compiled inquiry alongside metadata identifying them, their institution, and a description of the inquiry so patients can give informed consent.

The researcher may choose to limit inquiry responses to patients whose data has been attested to by one or more trusted sources.

Step Five

Patient Response

A patient's hardware device detects the newly published inquiry and notifies the patient's smartphone that they are eligible to respond.

The patient reviews the details of the inquiry, assisted by software that helps them understand the privacy implications and checks a global registry to verify the identity of the researcher.

If the patient consents, their hardware device executes the inquiry and transmits the results along with a zero-knowledge proof back to the researcher, using fully encrypted peer-to-peer technology.

Step Six

Verification

When a researcher receives a response, the provided zero-knowledge proof is verified. This verification guarantees that the patient's hardware ran the inquiry program correctly using data that originated from one of the trusted institutions.

Notably, verification does not reveal identifiers that link a patient across inquiries, nor does it reveal which institution the data originated from, nor when the data was created. It does however prevent patients from submitting duplicate responses.

Design pillars

🏠

Patient-held custody

Raw reads stay on hardware the patient controls, instead of copying everything into each research silo by default.

✍️

Public attestations

Institutions publish commitments and signatures that vouch for data provenance without broadcasting who the patient is.

🔒

ZK-backed answers

Responses carry proofs that the agreed computation ran correctly—without shipping the underlying genome row.

6
Steps from custody to verified response
0
Central copy of every patient genome required
ZK
Proof layer for private computation
Research questions expressible as inquiries

Trust without raw data movement

Federated networks already keep many datasets at the edge. Attestations and ZK proofs add a path where researchers verify outcomes without institutions pooling identifiable genomes in one place.

The goal is not to replace clinical systems overnight, but to widen what can be studied safely when every node cannot be equally hardened.

Open crypto demo
🧬

From consent to verified response

Patients see who is asking, what computation will run, and what leaves the device. Peer-to-peer delivery and proof verification close the loop without a central honeypot of genomes.

That is the same thread running through the six steps above—custody, attestations, inquiries, consent, execution, and verification.

Back to top flow
🔐

Perspectives (illustrative)

💬

"We need more than policy when a single weak node can undo trust in the whole federation. Patient-held data plus proofs is the first story that feels operational, not aspirational."

Composite voice
Research IT / data governance (illustrative)
💬

"If consent is real, the patient has to see the inquiry, not a PDF version of it. Publishing the program and verifier expectations is the missing half of informed participation."

Composite voice
Ethics & consent design (illustrative)
💬

"We already attest to cohorts in prose. Turning that into cryptographic commitments—without re-identifying participants—is the bridge to reproducible cross-site science."

Composite voice
Genomic data commons (illustrative)

Explore the proof stack

Walk through hashes, Merkle inclusion, signatures, append-only MMR peaks, and how they feed a zero-knowledge verifier—all in one interactive page.

Open interactive demoBack to presentation