Sequence platformGit for genomes
gl1-seq gives every DNA, RNA and protein sequence a permanent identifier, a complete change history and proof of integrity that anyone can check. When a reference changes, it updates a minimap2 and bcftools analysis by redoing only what the change can affect, with the result a full reanalysis would give. The human reference genome, more than 1,000 genomes, GENCODE and the human proteome are planned for public chain state on GenesisL1.
Platform
Public reference data on chain, applications to work with it, a developer platform to build on it, and tools that let institutions use it with private data. Each part is labelled by where it stands today.
The human reference genome GRCh38, every base, in chain state. The main branch that every genome commits against.
Learn more Data on chainAt launchOpenly released genomes stored as commits against the reference: 12 at launch and more than 1,000 to follow.
Learn more Data on chainAt launchGENCODE gene models on the reference coordinates at launch, for work gene by gene. The human proteome follows.
Learn more ApplicationsPlannedGenome, genes and proteins joined into one map to browse, compare and cite.
Learn more ApplicationsBuiltA browser workbench to import, edit, version, compare and prove sequences. Nothing is uploaded.
See it ApplicationsBuiltReads the reference and public genomes from the chain, compares a gene across genomes and rebuilds any haplotype to check it. A home in the GL1X explorer is planned.
Learn more Developer platformBuiltThe gsq command line, with libraries in Python, Go, C++ and JavaScript that compute the same identifiers.
Learn more Developer platformBuiltA Model Context Protocol server, so AI agents can branch, analyse and commit with attribution.
Learn more Developer platformBuiltEVM contracts that validate sequence objects as they are written, check proofs and register salted commitments on GenesisL1.
Learn more For institutionsIn pilotAfter a reference update, re-align only the read pairs that can change and reuse the rest: identical to full recomputation, several times faster for a local correction.
Learn more For institutionsPartly builtSalted commitments of private records on chain, never the data. The registry contract and its client are built; disclosure to named recipients is planned.
Learn more For institutionsPlannedEach variant stored once and each genome as the entries it carries, for collections of thousands.
Learn moreToday the version of a sequence is usually a file name. gl1-seq replaces it with four things a file can't give you.
Every sequence has an identifier computed from its content. The same sequence gets the same identifier in every implementation, on chain and off, next to its GA4GH refget and MD5 names.
Changes are commits with parents, author, time and provenance, all covered by the commit hash. Branch, diff, merge, blame and lift coordinates between versions.
A proof of a few kilobytes shows that a stretch of bases belongs to an identifier. Certificates state exactly what changed between two versions. Both check against identifiers alone.
The reference genome and openly released genomes live in chain state on GenesisL1 as the data itself. Anyone can read any range and check it, with no account and no host to trust.
The identifiers, commits and proof shown are real output for the example region open in Studio above: GRCh38 chr21:30,000,001–30,012,000.
Every sequence reconstructs bit for bit from the reference and its commits. Soft-masking and IUPAC ambiguity codes are kept.
Sequences are stored as content-defined pieces in a Merkle tree. A one-base change rewrites about one piece and shares the rest with the previous version.
The Python, Go, C++ and JavaScript implementations and the EVM contracts compute the same identifiers. No chain upgrade is needed.
One machine-readable format and one interface. An agent can branch a genome, run an analysis and commit with attribution, and a person can audit each step.
The same identifiers, history and proofs, from a 110-residue hormone to a 3.1-gigabase genome.
Chromosomes, contigs, genes and amplicons. About 2 bits per base, with IUPAC ambiguity codes and soft-masking preserved.
Transcripts, non-coding RNAs and viral genomes, in the same encoding and with the same proofs as DNA.
The 20 amino acids plus selenocysteine, pyrrolysine, ambiguity codes and stop. Proteomes, antibodies and HLA alleles.
Any printable ASCII symbols, for structure strings, quality tracks and other symbolic sequences.
On-chain data
On GenesisL1 the sequence itself is written into contract state. The chain holds the data, with no hash pointing at a server that may move or close. Any node can return any range, and any reader can check it against its identifier.
| Dataset | Contents | Scale | In chain state | Status |
|---|---|---|---|---|
| Human reference genomeGRCh38 | 24 chromosomes and the mitochondrial genome, every base, with its soft mask | 3.1 Gb | ≈ 0.8 GB with its layers (est.) | At launch |
| Human gene annotationGENCODE | Genes, transcripts, exons and coding sequences on the reference coordinates | ≈ 78,000 genes, ≈ 19,400 protein-coding | To be measured | At launch |
| Pilot genomes12 genomes | Openly released genomes, each as the deltas of its two haplotypes against the reference | 12 genomes | ≈ 70–90 MB each (est.) | At launch |
| Public genome collection1,000+ genomes | Openly released genomes as deltas against the reference | 1,000+ genomes | ≈ 70–90 GB per 1,000 (est.) | Following months |
| Human proteomeReference proteome | Proteins linked to their genes and transcripts, with translation receipts | ≈ 20,000 canonical proteins | To be measured | Roadmap |
| Protein and immune reference setsSwiss-Prot · RefSeq · UniRef50 · OAS · IPD-IMGT/HLA | Reviewed proteins, known RefSeq proteins, clusters, paired antibodies and HLA alleles | Tens of millions of sequences | To be measured | Roadmap |
Sizes in chain state are extrapolated from a chromosome written to the compiled contracts in an EVM, and are labelled as estimates. Only genomes whose donors consented to open release go on chain, and each source's licence applies.
| Collection | Full copies | As deltas, current format |
|---|---|---|
| 10 genomes | 15 GB | 0.7–0.9 GB |
| 1,000 genomes | 1.5 TB | 70–90 GB |
| 3,202 genomesthe size of the high-coverage 1000 Genomes set | 4.9 TB | 0.22–0.29 TB |
Estimates. Full copies hold both haplotypes at 2 bits per base. Deltas are extrapolated from a chromosome written to the contracts. A planned shared variant catalogue would keep each variant once; its sizes will be measured when it is built.
The gl1-seq figure is an estimate for a whole genome, extrapolated from a chromosome written to the contracts; it varies with the number of variants a genome carries. The deltas rebuild both haplotypes exactly, each checked against its identifier; where the source VCF has no genotype, the haplotype keeps the reference and the genome's metadata says so. The reads stay off chain.
Atlas
With the reference genome, GENCODE and the human proteome in chain state, the Atlas joins them into a single resource to browse and query. Every view is backed by content identifiers, so a figure in a paper can cite the exact bases, gene model and protein it shows.
Move from a genomic position to its gene, transcript, coding sequence and protein. Each step is a verifiable object.
Pull the same gene from every genome in the collection and see each genome's differences side by side.
Align a gene or protein across genomes and reference sets, starting from proven sequences.
Derive a protein from its coding sequence with a receipt that anyone can recompute.
Lift annotations between reference versions through certified edits, with no chain file to take on trust.
Every range, gene and protein has a permanent identifier suited to methods sections and regulatory files.
Planned access: in the GL1X explorer, through an API, and through a Model Context Protocol server for AI agents. Gene-by-gene comparison across genomes already runs in the genome browser, a command-line tool and the agent interface: every variant named in HGVS with VEP-style consequence terms, and the distinct proteins aligned.
Developers
The same operations are available from a Git-style command line, from libraries in four languages and as tools for AI agents. Every route computes the same identifiers, so results can be checked across teams and systems.
Git-style commands for repositories of sequences, from FASTA import to planning an on-chain upload.
A Python reference with Go, C++ and JavaScript ports. All four agree on shared conformance vectors.
A Model Context Protocol server exposes the operations as tools with structured, verifiable results.
Validate sequence objects as they are written, register identifiers, record history and check proofs, and keep a registry of salted commitments for private records. Standard Solidity and Vyper, with no precompiles or chain changes. An independent audit comes before mainnet deployment.
A Rust engine decides, pair by pair, which alignments a certified update can change, and merges the re-aligned records with the reused ones. The pilot kit runs it on an institution's own CRAMs.
The browser workbench shown at the top of this page. It runs entirely in the page and uploads nothing.
gsq add GRCh38.fa -m "GRCh38 release" # import FASTA as a commit on main
gsq cat main:chr21 --start 30000000 --end 30000100
gsq edit main --member chr21 --at 30000050 --del 1 --ins T -m "fix base"
gsq diff main~1 main # edit scripts per sequence
gsq branch agent-b main # work in parallel
gsq merge main agent-b -m "merge" --branch main # three-way, base resolution
gsq prove main:chr21 30000000 30001000 -o p.json && gsq verify p.json
gsq liftover main~1:chr21 main:chr21 31000000-31002000
gsq derive translate main:cds --to-stop # derived sequence + receipt
gsq alias main:chr21 # gl1-seq id, refget, MD5
gsq chain-plan main:chr21 # transactions, bytes, gasimport gl1seq
seq = gl1seq.sequence("ATGGCCATTGTAATGGGCCGC", gl1seq.DNA)
print(seq.id.hex(), seq.n) # content identifier and length
proof = gl1seq.prove(seq, 3, 12) # a range proof
gl1seq.verify(proof) # checked against the identifier alone{
"mcpServers": {
"gsq": {
"command": "python3",
"args": ["-m", "gl1seq", "mcp"],
"env": { "GSQ_REPO": "/data/genomes/.gsq" }
}
}
}PH=/data/gsq-pilot # the pilot's folder
bash pilot/setup.sh $PH # every tool built from source, once
python3 -I pilot/make_update.py --reference GRCh38.fa --out $PH/updates \
--name fixitfelix --mask duplicated.bed # a certified update of the reference
python3 -I pilot/pilot.py init --config $PH/pilot.json --work $PH/work \
--tools $PH/tools/tools.json --updates $PH/updates/updates.json \
--sample P0001=/archive/P0001.cram --sample P0002=/archive/P0002.cram
python3 -I pilot/pilot.py run --config $PH/pilot.json # record, archive, update, verify
python3 -I pilot/pilot.py status --config $PH/pilot.json # stages and verdicts per sampleCertified reanalysis In pilot
A reference correction normally means aligning and calling every genome again. gl1-seq certifies exactly which bases changed, re-aligns only the read pairs whose alignment can change, re-calls where the evidence changed and gives every other pair its old records. The aligner and caller are the original analysis' own, and the result is identical to a full reanalysis.
A certificate states exactly which bases changed between the two versions, and anyone can verify it.
Find the read pairs and calls that could change, before any mapping starts. Where reuse would not pay, run the full analysis.
Re-align and re-call them with the same tools and settings. Reuse every other record.
Identical to full recomputation: every alignment record in order, every call in every field. Each run also re-aligns a random sample of reused pairs as an audit.
A 30× genome and several kinds of update to GRCh38, each result compared with full recomputation record by record and call by call. Measured values, intervals and methods will be published with the preprint.
| Update | Time | Same result |
|---|---|---|
| Local correctionfalsely duplicated sequence masked, as FixItFelix proposes | several times faster | identical |
| Rearrangementa block moved, a deletion and an insertion; coordinates move | a modest gain | identical |
| Genome-wide changecommon alleles substituted across the genome | the planner runs the full analysis | identical, by plan |
Shortcuts such as lift-over tools, or re-mapping only the corrected regions, can be quicker. They approximate a reanalysis by design, and their results differ from a full one.
A genome enters with one original analysis that gl1-seq records. Every later update then costs what gl1-seq costs. Existing BWA-MEM or DRAGEN alignments are not reused.
Exact reuse is a property of an aligner and a caller, so it is stated and tested for each one.
Stated and tested for minimap2 in short-read mode and bcftools mpileup and call: alignment, sorting and per-sample variant calls.
As released, a read's alignment depends on the other reads in its batch. A small patch that breaks ties by read name, with a fixed insert size, makes reuse possible in tests. A whole-genome contract is still to do.
Closed source. The conditions under which its results could be reused cannot be stated or checked from outside.
Duplicate marking, base-quality recalibration and joint genotyping across a cohort have no reuse contract yet.
The pilot kit runs the campaign's own code on an institution's server, genome by genome, and reports what it measured there.
The read pairs rebuilt from the genome's CRAM with samtools, for the original analysis.
minimap2 and bcftools with gl1-seq's recording. On the first genome, stock minimap2 runs as well, to show that the recording changes nothing.
The alignment kept as CRAM 3.0, decoded and compared record by record before the BAM is removed.
gl1-seq applies a certified update starting from the CRAM, with the pairs' digest checked against the reads the original analysis used.
Full recomputation on the new reference, compared with gl1-seq's result record by record and call by call.
Verdicts, times, storage and costs at the institution's own prices, and a batch of salted commitments it may choose to put on chain.
Nothing leaves the machine unless the institution commits a batch root. The commands are under Developers, in the Pilot kit tab.
Solutions
One canonical reference that everyone shares, exact reanalysis when it changes, and a tamper-evident audit trail for private data, without moving a single patient genome.
Built forComputational biology · Target discovery · Regulatory and quality
Challenges
What gl1-seq does
Built forData stewards · Bioinformatics platform teams · Access committees · Biobank IT
Challenges
What gl1-seq does
Built forProgramme leadership · Bioinformatics platforms · Data governance
Challenges
What gl1-seq does
Built forPrincipal investigators · Core facilities · Research software engineers
Challenges
What gl1-seq does
Built forBioinformatics leads · Laboratory directors · Quality managers
Challenges
What gl1-seq does
Built forRegulatory reviewers · Auditors · AI and agent builders
Challenges
What gl1-seq does
Security and compliance
Genetic data is personal data, and chain state is permanent. Anything that needs consent, deletion or access control stays off the public ledger. The protocol is the same on both sides, so an institution gets identifiers, proofs and history for private genomes without publishing a single base.
GRCh38: public, and assembled from anonymous consented donors.
Genomes whose donors consented to public release, from open-access resources such as the 1000 Genomes Project, Genome in a Bottle and the Personal Genome Project.
Each genome's source, release terms and checksum. Sample codes as published, never names.
Patient and participant sequences, unless the donor has explicitly consented to permanent public release.
Data held under access agreements, such as dbGaP, EGA or UK Biobank, which forbid redistribution.
Nothing that identifies a person or describes their health sits next to a genome.
Three layers keep private sequences verifiable without exposing them.
The genome stays with its institution, under its governance and jurisdiction, on storage that can be deleted.
A fingerprint proves a record existed and is unchanged without revealing it. Destroying the salt unlinks it, and a withdrawal can be marked on chain. The registry contract and its client are tested in an EVM: one transaction commits a batch of any size, at a cost that does not grow with the batch.
Results are shared with a named recipient only, using CIPNFT encrypted envelopes on GenesisL1.
A data protection impact assessment, provenance recorded for every genome, terms of use that forbid re-identification, and review by a data-protection lawyer.
This section describes design intent and is not legal advice. The design follows the special-category rules of GDPR Article 9 and European guidance on personal data and blockchains, and remains subject to legal review.
GenesisL1
gl1-seq runs on a laptop with no chain at all. Running it on GenesisL1 adds properties that a file server or a cloud bucket can't provide.
Sequences sit in contract state, the way MolNFT already keeps Protein Data Bank structures. There is no link to rot and no host to trust.
Every node holds the same reference under the same identifier. Mirrors can't drift, and two laboratories can't unknowingly use different versions.
Each commit is ordered and timestamped by consensus and can't be rewritten afterwards. The audit trail is a property of the data.
Contracts verify sequence objects, proofs and certificates in the EVM, so other contracts and applications can rely on them. GenesisL1 runs Ethereum smart contracts as they are, with the same languages and tools.
The network is replicated across independent validators and governed on chain. The companies building on it don't control it and can't switch it off.
Reading is free and permissionless through standard Ethereum JSON-RPC and the GL1X explorer. Writes are paid once in L1 coin.
Genomes sit beside molecular structures (MolNFT), executable models (GL1F Model NFTs), datasets and protected intellectual property (CIPNFT), and can be combined with them.
The explorer and its MCP server open on-chain records to researchers and to autonomous software through the same interface.
A community pool, replenished every block and spent only by on-chain vote, pays for open data and shared infrastructure.
The ledger proves which data was stored and which computation ran. Laboratory and clinical evidence still decide whether a biomedical claim is valid.
Comparison
Typical size of one person's genome at 30× sequencing, and the properties a shared, verifiable record needs.
Scroll the table sideways for every column →
| Method | Size per person | Exact genome | Random access | Checkable without trust | History | On-chain fit |
|---|---|---|---|---|---|---|
| Raw reads (FASTQ)the reads: evidence, not yet a genome | 50–100 GB | needs analysis | ||||
| Alignments (BAM / CRAM)reads placed on a reference | 15–100 GB | needs calling | indexed | CRAM records the reference checksum | ||
| Variant calls (VCF / gVCF)differences from the reference | 0.1 GB to several GB | approximate | indexed | |||
| Reference-based compressorspacked differences, e.g. DNAzip | ≈ 4 MB | decode from start | ||||
| Cohort compressorsmany genomes, shared chunks | smallest at scale | genotypes | ||||
| Pangenome graphsgenomes as paths in a shared graph | tens of MB | |||||
| GA4GH refget / seqcolcontent identifiers, no storage format | identifiers only | – | – | whole sequences | identifiers only | |
| Blockchain genomics platformsencrypted file off chain, consent on chain | off-chain file | – | ledger only | |||
| gl1-seq commitdeltas of both haplotypes + their content identifiers | ≈ 70–90 MB (est.) | checked against its identifier | any range, with proof | identifiers, proofs, certificates | commits, provenance, blame, merge | designed for it |
Where others win. Specialised and cohort compressors are smaller. Pangenome graphs model complete assemblies more naturally. A gl1-seq commit stores the resulting genome, so raw reads still need their own archive. The gl1-seq size is an estimate for the current on-chain format.
Roadmap
gl1-seq aims to become the common way sequence versions are named, exchanged and verified. A standard is earned through openness and adoption, and the plan is built on both.
Specification, reference implementation, three ports, Studio and the genome browser. The benchmark campaign behind the preprint, and a pilot kit and commitment registry for institutions. Preprint in preparation.
GRCh38 and GENCODE gene annotation in chain state, with 12 pilot genomes. Contracts audited. Studio and the command line released.
1,000+ openly released genomes as commits. The sequence browser in GL1X. The cohort variant catalogue.
The human proteome in state, the Atlas, protein and immune reference sets, authorised disclosure for private data.
Work with us
We're speaking with institutions that want to shape the launch datasets, the Atlas and the private data layer, or to run a pilot on their own genomes and infrastructure.
Nominate public genomes, populations and annotation sets for the on-chain programme, and review how they are recorded.
Run the pilot kit on a few of your own CRAMs, on your own server. It applies a certified reference update and checks every result against full recomputation. Your data stays where it is.
Connect the libraries, the agent interface or the contracts to your pipelines, platforms and products.
Reach the team through the GenesisL1 community channels or on GitHub, and say which of the three you have in mind.
FAQ
gl1-seq is a platform for storing, versioning and verifying biological sequences. Each sequence gets an identifier computed from its content, each change is recorded as a commit, and any part of a sequence can be proven against its identifier. When a reference genome changes, it updates read alignments and variant calls by redoing only what the change can affect, with the result a full reanalysis would give. It is built on an open protocol developed by The Bioinformatics Company and is coming soon on the GenesisL1 distributed ledger.
Public reference data in chain state: the human reference genome, openly released genomes, GENCODE and the human proteome. Applications: Studio, a genome browser and the Atlas. A developer platform: the gsq command line, libraries in four languages, an agent interface and EVM contracts. Tools for institutions: certified reanalysis with a pilot kit, and a private data layer of salted commitments. Each part is labelled as built, partly built, in pilot, at launch or planned.
That the updated alignments and calls are identical to what a full reanalysis with the same aligner and caller would produce: every BAM record in the same order, and every VCF record in every field. From a certificate of the reference change and the aligner's declared behaviour, gl1-seq derives which read pairs can align differently, re-aligns those, re-calls where the evidence changed and reuses everything else. Each run also re-aligns a random sample of reused pairs as an audit. In the benchmark behind the preprint, on a 30× genome and several kinds of update to GRCh38, the result was identical every time, and several times faster than full recomputation for a local correction. When an update is genome-wide, the planner says before mapping that reuse would not pay and runs the full analysis. Measured values, intervals and methods will be published with the preprint.
Today, minimap2 in short-read mode with bcftools mpileup and call: alignment, sorting and per-sample variant calls, the pipeline behind every measurement on this page. Reuse is a property of each aligner and caller, so each needs its conditions stated and tested. BWA-MEM as released makes a read's alignment depend on the other reads in its batch; a small patch that breaks ties by read name, with a fixed insert size, makes reuse possible in tests, and a whole-genome contract is still to do. DRAGEN is closed source and cannot be covered from outside. Duplicate marking, base-quality recalibration and joint genotyping across a cohort have no reuse contract yet. Existing BWA-MEM or DRAGEN results are not reused: an institution starts from one analysis that gl1-seq records.
One server and a few genomes its governance allows for method validation. The pilot kit runs on Linux with 16 or more hardware threads, 32 GB of memory, and about 300 GB of working space plus 70 GB of sort scratch per 30× genome in flight; one script builds every tool from published sources. For each genome it rebuilds the reads from the CRAM, runs the original analysis with gl1-seq's recording, archives it as CRAM and checks the round trip, applies a certified reference update with gl1-seq from the CRAM, and compares the result with full recomputation record by record. The report gives the verdicts, times, storage and costs at the institution's own prices. Plan for several hours per sample on a 32-thread server, most of it the full analyses the pilot runs to check itself. Nothing leaves the machine unless the institution commits a batch of salted commitments.
Git gave source code content-addressed storage, commits, branches, diffs and merges. gl1-seq brings the same operations to sequences at single-base resolution, which is why it is described as Git for genomes: add, edit, commit, branch, diff, merge, blame and liftover, plus cryptographic proofs that a range of bases belongs to a specific version.
DNA, RNA, protein and general text. Nucleotide sequences keep IUPAC ambiguity codes and soft-masking. The same identifiers, proofs and history work for a 110-residue protein and for a 3.1-gigabase genome.
At launch, the complete human reference genome GRCh38 in chain state, at about 2 bits per base and about 0.8 GB with its soft mask and overview layers, together with GENCODE gene annotation on its coordinates and 12 pilot genomes stored as deltas against it. More than 1,000 openly released genomes follow in the months after launch. The human proteome and further protein reference sets are on the roadmap.
No. Only public reference data and genomes whose donors consented to open release go on chain. Private genomes stay in the institution's own compliant environment. For those, the chain can hold a salted commitment, a fingerprint that proves a record existed and is unchanged without revealing any of it. Destroying the record's salt unlinks the commitment from the data.
The reference is stored once, about 0.8 GB with its layers. Another person's genome is stored as the deltas of its two haplotypes against that reference: in the current on-chain format, an estimated 70 to 90 MB, extrapolated from a chromosome written to the contracts. That is about 5% of a full copy of both haplotypes at 2 bits per base. A planned change that writes shared variants once would make it smaller. Specialised compressors are smaller still; the deltas rebuild each haplotype exactly and check it against its identifier.
No. It imports and exports FASTA, carries GA4GH refget and MD5 identifiers for every sequence, and writes chain files for liftOver and CrossMap. In the pilot kit, certified reanalysis reads the CRAM an archive already keeps and writes standard BAM, CRAM and VCF. Raw reads and alignments stay in their own archives. gl1-seq adds what those formats lack: a verifiable identity, a history and proofs.
The data itself lives in public chain state, so there is one canonical copy that anyone can read and check. History is timestamped by consensus and can't be rewritten. Smart contracts verify proofs on chain, and no single company operates or controls the network. GenesisL1 already holds more than a million PDB and AlphaFold structures in state through MolNFT.
gl1-seq is in development. Institutions can nominate launch datasets, run the pilot kit on a few of their own genomes, or connect the libraries and contracts to their pipelines. Reach the team through the GenesisL1 community channels or on GitHub.