Whitepaper · v0.1 · July 2026
An encrypted biomarker wallet, decentralized identifiers for consent, and verifiable provenance anchored to a public settlement layer. Biology stays local. Trust becomes portable.
Abstract
We propose Proto, a protocol for encoding a single person's biological signal into a signature that is portable, private, and verifiable. Continuous biomarker data from clinical labs, functional-medicine panels, and wearables is captured, encrypted with a key held only by the subject, and stored in a personal wallet on-device. The chain is not the datastore. The chain holds three things: a decentralized identifier that resolves to the subject's public verification keys, a hash-anchored provenance receipt for each biomarker record, and a consent receipt each time a signature is queried by an outside actor: a restaurant, a clinic, a research protocol. Verifiable credentials express derived predicates ("HRV was stable over the last 14 days," "glucose is in range for this meal") without revealing the underlying series. The result is a wallet for the body that behaves like a wallet for value: the owner holds the keys, the counterparty verifies what they need to verify, and no intermediary holds the record. Proto turns lifetime biological signal into a first-class primitive.
I · Introduction
Every human runs a biology that is measurable, continuous, and unique. Glucose, heart-rate variability, VO2, sleep architecture, recovery, lipid panels, hormones, inflammation. Taken together, over years, they form a signature. That signature is more specific than a passport photo and more informative than any survey ever built.
The signature exists. What does not exist is a way for its owner to carry it. Today the signal lives fragmented across an Epic instance at one clinic 1, a proprietary vendor cloud for one wearable, a spreadsheet in a functional lab, a paper printout from a physical. The person who generated the data cannot fluently move, prove, or use it. The people who could benefit from it, a restaurant plating dinner, a coach programming a week, a physician making a call, do not receive it.
This paper proposes a protocol that closes the gap. It is not a database. It is not another PHR (personal health record) attempting a centralized aggregator play. It is a wallet, designed the way a cryptographic wallet is designed for value, and a set of standards for how the signature it carries can be presented, proven, and consented to, without the wallet ever surrendering the underlying data.
The design draws directly from work the identity and settlement-layer communities have done for a decade. W3C Decentralized Identifiers (DIDs) v1.1 2, W3C Verifiable Credentials 3, ISO/IEC 27560 consent records 4, ERC-725 on-chain identity 5, and validity-proof rollups such as Linea 6. Proto is not a new cryptographic invention. It is a specific instantiation, engineered for a specific subject: a human being.
II · The Signature
A biological signature is a time-indexed vector of biomarkers and derived features for a single subject. Formally:
Si(t) = { b1(t), b2(t), … , bn(t) }
for subject i, time t, over n biomarker channels: clinical, functional, and wearable-derived.
Channels currently supported by Proto include, non-exhaustively: continuous glucose (CGM), heart-rate variability (HRV), resting heart rate, VO2 max, respiratory rate, sleep stages, recovery, strain, body temperature, blood oxygen, and any structured lab panel expressible in FHIR Observation resources 7.
Two properties matter for the protocol.
Uniqueness. A signature composed of even a modest number of channels sampled at daily resolution over a year is, with overwhelming probability, unique to its subject. This is an empirical claim well-supported in the biometric literature 8 and is the reason the signature has cryptographic-grade identifying power. The protocol treats this power as a hazard, not a feature. The raw signature never leaves the wallet.
Reducibility. Nearly every real-world use of the signature does not need the signature itself. A restaurant does not need your CGM curve. It needs to know whether tonight's tasting menu is compatible with the last 72 hours of your metabolism. A clinic does not need your minute-by-minute HRV. It needs to know whether the intervention it prescribed six months ago moved the underlying variable in the right direction. Both are predicates over the signature, not the signature itself. This is where verifiable credentials and zero-knowledge proofs enter.
III · The Wallet
Proto ships as a mobile application on iOS and watchOS. Every biomarker record ingested, from HealthKit, from WHOOP, from a lab-integration adapter, from manual entry, is written to an encrypted store on the device.
The cryptographic model is straightforward:
This is the ground floor. It is also the least novel part of the design. Encrypted local storage is table-stakes. What matters is that the wallet is the only party that ever holds plaintext biology. The rest of the protocol is about what the wallet is allowed to say on its owner's behalf.
Figure 1. Data flow. Signals enter the wallet, plaintext never leaves. Only DID references, verifiable credentials, and consent receipts are surfaced.
IV · Identity
Each Proto subject controls a family of decentralized identifiers conforming to W3C DID v1.1 2. A DID is a URI of the form did:proto:z6Mk… that resolves, via a DID document, to the subject's public keys and service endpoints. The DID does not identify a person by name; it identifies a controllable cryptographic locus.
Proto uses a two-tier structure:
Long-lived. Corresponds to the master key. Never presented to counterparties. Used only to sign or rotate subordinate keys.
Short-lived, purpose-scoped. One for restaurants, one for clinical partners, one per research study. Rotated freely. Correlatable only by the subject.
DID methods. Proto supports two resolution methods:
did:key. Offline, cryptographic-only resolution. Zero on-chain footprint. Preferred for high-cadence, low-value interactions (a menu, a coffee shop).did:proto. An ERC-725-compatible smart-contract identity anchored on Linea 6. Used for durable relationships (a physician of record, a research protocol enrollment) where rotation, revocation, and delegation matter and are worth on-chain state.Neither method requires the subject to hold the ledger native token to be identified. Chain fees are settled by verifiers or by relayer meta-transactions, not by patients. This is intentional: a protocol for biology cannot ship a UX in which a person needs to buy a token to be a person.
V · Consent
Consent is the primitive that HIPAA 9 and GDPR 10 demand and that the current health-data stack fakes with a checkbox at intake. Proto treats consent as a first-class, cryptographically verifiable event.
Every time a counterparty (restaurant, clinic, coach, researcher) requests a predicate over the subject's signature, the wallet mints a consent receipt conforming to ISO/IEC 27560 4. The receipt includes:
The receipt is delivered to the counterparty and, at the subject's option, a hash of the receipt is anchored on-chain. The full receipt itself never touches the chain. Receipts contain contextual metadata that would be a privacy hazard if immutable and public.
"Consent should be event-scoped and verified locally. Keep only hash-anchored receipts; open one named event under due process. Nothing ambient." 11
Revocation is native. A subject can revoke a receipt at any time; the revocation is a second signed object that supersedes the first. Counterparties that fail to check for revocation before relying on a predicate are, cryptographically, on notice.
VI · Anchor
Design constraint: raw biomarker data cannot go on any public ledger. HIPAA and GDPR are incompatible with immutable, world-readable storage of personal health information. The right to erasure 10 and immutability are, at first order, contradictory.
The workable answer, which Proto adopts, is a strict separation between data and attestations about data. Only attestations are eligible for the chain, and even attestations are eligible only when they contain no direct or reasonably re-identifiable personal information.
Concretely, Proto uses the chain (Linea, a zkEVM L2 6) for four kinds of objects and nothing else:
Anchoring choice. We target Linea for three reasons. First, the anchor inherits the security of the largest and most-scrutinized public settlement layer in production. Second, ZK validity proofs mean finality within minutes and no seven-day withdrawal window 6. Third, the recent Linea prover migration to 31-bit field arithmetic (KoalaBear) 12 pushes proof generation toward consumer hardware, a direction the personal-biology use case will eventually need.
Nothing in the protocol binds Proto to Linea specifically. The anchoring interface is chain-agnostic; alternate implementations on Base, Optimism, or L1 mainnet are trivial. The chain is a substitutable trust layer, not the product.
VII · Proofs
The value in Proto is not in moving raw biomarker data. It is in moving facts about biomarker data: verifiable, revocable, scoped, cryptographically bound to a subject the counterparty can trust without ever seeing their name.
Facts are expressed as Verifiable Credentials 3. A VC is a signed JSON-LD object with three principals:
For high-privacy predicates, the VC embeds a zero-knowledge proof: the verifier learns the truth-value of the predicate and nothing else. Techniques currently supported include BBS+ signatures for selective disclosure and Groth16 / PLONK circuits for arbitrary numeric predicates over recent records. Recent work has demonstrated ZK proofs over genomic and clinical data at practical performance 13; the same techniques apply directly to biomarker streams.
Two example predicates:
Example 1. A restaurant asking whether a subject's last-72-hour glycemic profile permits a tasting menu with sequential sugars.
{
"type": "VerifiableCredential",
"issuer": "did:proto:z6MkWalletA",
"credentialSubject": {
"id": "did:proto:z6MkContextRestaurantX",
"predicate": "glucoseAUC(last72h) < 12000 mg·dL·h"
},
"proof": { "type": "BBS+", "…": "…" }
}Example 2. A research protocol verifying that a subject's HRV baseline is within enrollment criteria without receiving the underlying values.
{
"type": "VerifiableCredential",
"issuer": "did:proto:z6MkWalletA",
"credentialSubject": {
"id": "did:proto:z6MkContextResearchY",
"predicate": "mean(HRV, 30d) >= 45 && sd(HRV, 30d) < 15"
},
"proof": { "type": "Groth16-BN254", "…": "…" }
}In both cases the counterparty receives a boolean, cryptographically bound, revocable, and expiry-fenced. They do not receive glucose values. They do not receive HRV time series. They do not learn the subject's clinic, wearable brand, or name.
VIII · Actors
A protocol is only real when its participants and their incentives are stated clearly.
01
The person whose biology is being measured. Holds the master key. Signs every DID document, every credential, every receipt. Cannot be impersonated as long as the master key is safe.
02
Software the subject controls, running on their devices. Ingests, encrypts, stores. Issues credentials the subject authorizes. Never speaks without the subject's signature.
03
Optional. External party attesting to a fact about the subject: a lab confirming a panel result, a clinic confirming a diagnosis. Issuers sign their own credentials into the wallet. Subject controls whether to re-present them.
04
The counterparty asking a predicate. Restaurants, clinics, researchers, coaches. Receives a credential, verifies signatures and revocation status, acts on the boolean.
05
A public ledger (Linea, by default). Holds DID documents, provenance hashes, consent-receipt hashes, and revocations. Substitutable. Not a party to any private data.
06
A centralized platform holding every subject's biomarker plaintext, monetizing it against them. That entity is architecturally absent from Proto. This is the design.
IX · On Tokens
A protocol that touches health data should be evaluated on whether it works, not on whether it has a launch-market unit of account. We have made the following commitments explicit in the design.
The design deliberately trades one axis of tokenomic upside for a different axis of trust. In our reading, the credibility of a protocol for personal biology is bounded above by how obviously its incentives do not diverge from the subject's. The cleanest way to demonstrate non-divergence is to not build the divergence in.
X · Roadmap
Phase 01 · Shipped
iOS + watchOS wallet. HealthKit, WHOOP, and FHIR-Observation adapters. AES-256-GCM at rest. Secure Enclave master key. Encrypted iCloud backup.
Phase 02 · In development
did:key resolution and W3C VC issuance in-wallet. First set of predicates for menu-sorting and coach-check-in flows. BBS+ selective disclosure.
Phase 03 · Q4 2026
ERC-725-compatible did:proto method. Provenance anchoring for lab-issued credentials. Revocation registry. Relayer-paid meta-transactions for subjects.
Phase 04 · 2027
Groth16 / PLONK circuits over rolling biomarker windows. Restaurant, clinic, and research verifiers running against production credentials. Independent security review.
Phase 05 · Beyond
A federation of Proto wallets and issuers, labs, clinics, restaurants, researchers, interoperating around portable biological signatures. One person, many contexts, one signature they hold.
Closing
The last decade of public-chain research showed that a value primitive can be given to a person without a bank sitting between them and it. The next primitive is the person themselves: their signal, their signature, their biology. Proto is our attempt at that primitive. This paper is version 0.1. Comments, disagreements, and collaborators are welcome.
References