Lineage

Lineage is a provenance and verification layer for AI-assisted medical writing. Pharmaceutical value dossiers justify a drug's value to payers and regulators, and every claim has to trace back to real evidence. Bodies like NICE, the FDA, and ISPOR expect a clear audit trail and human oversight, but when a language model helps draft these documents it routinely invents or misattributes citations. You give Lineage a confidential source document, a drug, and an indication. It drafts one targeted dossier chapter grounded in PubMed, with inline PMID citations. It then independently verifies each citation by pulling the real abstract and checking whether it actually supports the sentence, marking every citation as confirmed or flagged for human review. The chapter is drafted inside a confidential enclave, so the source document never touches a public model. The finished evidence bundle is hashed, stored on Walrus, and published under an ENS name, so anyone can re-verify the whole thing with no trust in us and no central server. It drafts a single chapter rather than a full dossier, and it is built as an augmentation tool with a human in the loop.

The app is Next.js and TypeScript, deployed on Vercel. Three partner technologies each do a distinct job.

Chainlink Confidential AI Attester (dev preview) runs the drafting step inside an AWS Nitro enclave on model gemma4. We pass in both the fetched PubMed abstracts and the confidential source document, and the document never leaves the enclave or reaches a public LLM. The enclave returns signed digests over the content, request, and response, which we anchor as proof of how the chapter was produced.

PubMed E-utilities supply the abstracts. After drafting, a verifier re-checks every inline PMID against its real abstract using a verbatim-span grounding check and marks it confirmed or flagged. Early de-risk testing showed the model keeps the cited PMIDs in-set but misattributes about a third of them, which is exactly why the independent verifier is the headline feature and not an afterthought.

Walrus testnet stores the canonical evidence bundle as a blob over HTTP with no wallet, giving tamper-evident decentralized storage. ENS on Sepolia ties it together: a heor.dossier.latest text record on heor-prov.eth points to the Walrus blob, alongside agent version and capability records, so the name is a human-readable, mutable pointer to the latest evidence. Integrity is a SHA-256 over a canonical sorted-key JSON, recomputed in the browser on the Verify path so anyone can re-hash and compare to the on-chain value against a public Sepolia RPC, no keys required.

The notably hacky part was ENS registration. The ETHRegistrarController in the current ENS docs had been de-authorized in a Sepolia v2 redeploy, so commit() worked but register() kept reverting. We replayed ControllerAdded and ControllerRemoved events on-chain to find the live registrar, registered through that, and confirmed it still wires through the canonical registry so standard ENS resolution works.

That ENS registrar paragraph is worth keeping. It's the kind of "we actually dug into the chain" detail that reads well to a technical judge, and it's true.

favicon.svg svg

lineage-logo.svg svg

Logo * A square image (i.e 512x512) that can behave like a logo or an icon. Cover image * The ideal aspect ratio is 16:9 - for example 640x360 px.

3:11 AM

Devised strategy to convert existing assets into required image formats Devised strategy to convert existing assets into required image formats Let me look at what you've got, then make proper export-sized files for both.

Weighing renderer options and font availability solutions Weighing renderer options and font availability solutions The mark is a clean chain-of-custody with a verified bottom node, green #2E6F4E on cream #FBFAF7. I'll build a proper square icon and a 16:9 cover from that, exported as PNG at submission sizes. Let me check the tools available.

Troubleshooting font paths, pivoting to Liberation Sans fallback Troubleshooting font paths, pivoting to Liberation Sans fallback Tools are limited here (ImageMagick only, no Inter font), so I'll install a clean renderer and grab Inter to match your site, then composite precisely. Setting that up.

Architected dual image generation with variable fonts and SVG rendering Architected dual image generation with variable fonts and SVG rendering Inter loaded. Generating both assets now (cream #FBFAF7, green #2E6F4E, your chain mark), supersampled for crisp edges.

Evaluated image specifications for quality assurance Evaluated image specifications for quality assurance Let me check both before handing them over.

Evaluated design quality and verified file specifications met requirements Evaluated design quality and verified file specifications met requirements Both done and on-brand. Logo first.

Presented 2 files Presented 2 files Logo is 512×512, your chain mark centered on cream with a faint border so the tile stays defined on white gallery cards. Upload it to the Logo field as-is. Cover is 1280×720, which is exactly 16:9 (the same ratio as their 640×360 ideal, just sharper), so it'll downscale cleanly. It carries the lockup, the "HEOR Provenance Agent" line, the one-line tagline, and an ENS · Walrus · Chainlink Confidential AI row so a judge skimming the gallery sees the stack at a glance. Want any tweaks? Easy changes if you want them: swap the tagline text, drop the chip row, make the icon a bolder green-on-cream fill, or render a PNG favicon too.

Lineage logo 512 Image · PNG

Lineage cover 1280x720 Image · PNG Are you using any Ethereum developer tools for your project? * Select all that are applicable. Walrus Which blockchain networks will your project interact with? * Select all that are applicable. Please select Which programming languages are you using in your project? * Select all that are applicable. Please select Are you using any web frameworks for your project? * Select all that are applicable. Please select Are you using any databases for your project? * Select all that are applicable. Please select Are you using any design tools for your project? * Select all that are applicable. Please select Are there any other specific technologies, libraries, frameworks, or tools you're making heavy usage of don't fit into the categories above? Type and hit enter to add new values into the multiselect box. Please select Describe how AI tools were used in your project (if applicable) Be specific about which tools were used and explain which parts of the projects they were used for. This field may be left blank if no AI tools were used.

Show more 3:17 AM

Mapped tech stack across form fields and distinguished build-time versus runtime AI usage Mapped tech stack across form fields and distinguished build-time versus runtime AI usage Here's what to select/enter for each, based on your actual stack.

Ethereum developer tools: keep Walrus, and add (if they're in the list) viem, ENS, and Alchemy. If Chainlink appears here, add it; otherwise it goes in "other" below.

Blockchain networks: Ethereum (Sepolia) and Sui. ENS lives on Ethereum Sepolia; Walrus runs on Sui. The Chainlink enclave is an off-chain TEE, not a network, so don't add it here.

Programming languages: TypeScript, and JavaScript if listed separately.

Web frameworks: Next.js, and React if listed separately.

Databases: None. You don't use a traditional database, your storage is Walrus blobs plus ENS text records. If the field forces a selection and has a "None" option, pick that; if it lets you type a value, enter "None."

Design tools: None. The logo and UI were hand-authored (SVG plus code), no Figma/Sketch. Same "None" handling as above if required.

Other technologies/libraries (type-and-enter each):

Chainlink Confidential AI Attester AWS Nitro Enclaves PubMed E-utilities (NCBI) Vercel mammoth (.docx parsing) pdf-parse (.pdf parsing) docx (.docx export) SHA-256 / Web Crypto (provenance hashing) Describe how AI tools were used:

This project was built largely with Claude, via Claude Code. As a non-developer with a health economics and genomics background, I designed the architecture, made the domain and HEOR decisions, and ran the de-risk testing, and used Claude to write and debug the implementation: the Next.js app, the PubMed integration, the citation verifier, the Walrus and ENS clients, and the SHA-256 provenance hashing. It was especially useful on an ENS edge case on Sepolia, where the documented registrar contract had been de-authorized in a v2 redeploy. Claude replayed on-chain controller events to find the live registrar so registration would go through.

AI is also part of the product at runtime. The dossier chapter is drafted by a model (gemma4) running inside the Chainlink Confidential AI enclave. The point of the project is to not trust that output blindly: an independent verifier re-checks every citation the model produces against the real PubMed abstract, because testing showed the model keeps cited PMIDs in-set but misattributes about a third of them. The model does the drafting, and the verification layer keeps a human in the loop.

That answer is honest and specific, which is exactly what they ask for, and it doubles as your story for the "explain how you used AI" question in judging.

One related reminder from the judging deck: they want your plan files added to the repo. If Claude Code left any plan or task files in the project, commit them so that requirement is covered.

Submission type * Please select whether you want to be considered for the Top 10 Finalist prize and Partner Prizes OR for just Partner Prizes. Top 10 Finalist & Partner Prizes I want to be considered for both finalist and partner prizes. I will participate in main judging and partner judging. Partner Prizes only I want to be considered for partner prizes. I will participate in partner judging. All projects looking to attend Live Judging will present their project live to a panel of judges on Sunday, June 14th 2026 at 02:30 pm EDT Which partner prizes you applying for? Select all that are applicable. H Be sure to explain why your project is applicable for these prizes. You are allowed to apply for a maximum of 3 partners You may select up to 3 partners. This will make you eligible for all prizes offered by those partners from the prizes page. ENS $20,000 Sui $15,000 World $15,000 Arc $15,000 Hedera $15,000 LI.FI $15,000 Chainlink $14,000 Uniswap Foundation $10,000 Canton Foundation $10,000 Ledger $10,000 Dynamic $10,000 1inch $7,000 Google Cloud $5,000 Privy $5,000 Unlink $5,000 Blink $5,000 Which other partners' technologies have you used on your project? Select any additional technologies you used but aren't applying for prizes

Show more 3:23 AM

Weighed finalist versus partner-only submission, selected three integrations, crafted justifications Weighed finalist versus partner-only submission, selected three integrations, crafted justifications Submission type: go with Top 10 Finalist & Partner Prizes. It's strictly more upside and doesn't cost you anything on the partner side. You stay eligible for all the same partner prizes, you just also get considered for the Top 10. And you already qualify: the project is open source, deployed, and live, and you're making a demo video. The only real cost is presenting to a second (broader) panel at 2:30pm today and handling 3 minutes of Q&A.

Pick Partner-only instead only if one of these is true: you can't be present at the 2:30pm live judging, or your video/repo won't be ready in time. Neither seems to be the case, so opt into both. Your thesis (don't trust an AI's citations, verify every one, make it tamper-evident) lands even with judges who've never heard of a GVD, which is exactly what you need for a non-domain finalist panel. Just be ready for the verifier-vs-integrity distinction and the "how did you use AI" question, both of which we've already prepped.

Partner prizes (your 3): ENS, Sui, Chainlink. That's exactly your three integrations, and you're capped at 3, so it's clean. If there's a "why applicable" box, drop these in:

ENS: ENS is the human-readable, owned entry point to each evidence bundle. heor-prov.eth resolves via text records (heor.dossier.latest) to the current Walrus blob, alongside agent version and capability records, so anyone can verify a dossier starting from just a name, with no central server. Sui (Walrus): The canonical evidence bundle is stored as a Walrus blob for tamper-evident decentralized storage. The Verify flow fetches the bytes back from the Walrus aggregator and re-hashes them in the browser, making integrity provable against what's anchored on-chain. Walrus is the load-bearing storage layer of the whole provenance chain. Chainlink: The dossier chapter is drafted inside the Chainlink Confidential AI enclave (AWS Nitro), so the confidential source document is processed by a model without ever touching a public LLM. The enclave returns signed digests over content, request, and response, which we anchor as proof of how the chapter was produced. Other partners' technologies used (not applying for prizes): none. Nothing else on that list is in your stack. AWS Nitro, Vercel, and PubMed aren't partners here, and you deliberately kept Hedera out of this solo project. Leave it empty.

Prize How are you using this Protocol / API? * ENS - $20000
Please add a sentence or two on why you're applicable for this prize. Link to the line of code where the tech is used. How easy is it to use the API / Protocol? (1 - very difficult, 10 - very easy) 0 Additional feedback for the Sponsor. They will use this to make the tech and documentation better. Sui - $15000
Please add a sentence or two on why you're applicable for this prize. Link to the line of code where the tech is used. How easy is it to use the API / Protocol? (1 - very difficult, 10 - very easy) 0 Additional feedback for the Sponsor. They will use this to make the tech and documentation better. Chainlink - $14000
Please add a sentence or two on why you're applicable for this prize. Link to the line of code where the tech is used. How easy is it to use the API / Protocol? (1 - very difficult, 10 - very easy) 0 Additional feedback for the Sponsor. They will use this to make the tech and documentation better.

Show more 3:25 AM

Synthesized partner integrations with code links, ratings, and constructive feedback Synthesized partner integrations with code links, ratings, and constructive feedback Here's everything for the three partner forms. The "why applicable" lines are tightened to a sentence or two each, code links point at your actual lib files, and the ratings/feedback are honest (sponsors read these, and honest feedback reads better than flattery).

ENS — $20,000

Why applicable:

We use ENS as the human-readable, owned entry point to each evidence bundle. heor-prov.eth resolves through text records (heor.dossier.latest, plus agent version and capability records) to the current Walrus blob, so anyone can verify a dossier starting from just a name, with no central server in the loop.

Code link: https://github.com/vedantMahangade/heor-provenance/blob/main/src/lib/ens.ts

Ease (suggested 5/10): The read path via standard libraries is genuinely easy once a name resolves. The write/register path on Sepolia is what drags this down, for the reason below. Adjust if it felt worse to you.

Feedback:

On Sepolia, the ENS apps now register names into ENS v2, which is invisible to standard ensjs/viem reading the v1 registry, so a name can look unregistered (owner = zero) even though it exists. Worse, the ETHRegistrarController address in the current docs had been de-authorized in the v2 redeploy, so commit() succeeded but register() reverted at onlyController with no clear error. We only got unblocked by replaying ControllerAdded/ControllerRemoved events on-chain to find the live registrar. Please update the Sepolia docs with the current controller address, and clearly document the v1/v2 split and which registry the JS libraries read, this cost us hours.

Sui (Walrus) — $15,000

Why applicable:

We store the canonical evidence bundle as a Walrus blob for tamper-evident decentralized storage. The Verify flow fetches the bytes back from the Walrus aggregator and re-hashes them in the browser, so integrity is provable against the hash anchored on-chain. Walrus is the load-bearing storage layer of the whole provenance chain.

Code link: https://github.com/vedantMahangade/heor-provenance/blob/main/src/lib/walrus.ts

Ease (suggested 9/10): The keyless HTTP publisher/aggregator flow was the smoothest integration of the three, no wallet, no setup.

Feedback:

The HTTP publisher/aggregator with no wallet made this the easiest sponsor integration by far. Two things would help: document testnet blob persistence and epoch/expiry behavior more prominently (it's not obvious how long a stored blob survives), and publish any rate limits on the public endpoints. A tiny end-to-end "store, read back, re-hash to verify" snippet in the docs would have saved a step.

Chainlink — $14,000

Why applicable:

The dossier chapter is drafted inside the Chainlink Confidential AI enclave (AWS Nitro) on model gemma4, so the confidential source document is processed by an LLM without ever touching a public model. The enclave returns signed digests over content, request, and response, which we anchor as proof of how the chapter was produced.

Code link: https://github.com/vedantMahangade/heor-provenance/blob/main/src/lib/confidential.ts

Ease (suggested 6/10): The async submit-then-poll API shape is reasonable and the attestation digests are clean to consume. Dev-preview reliability is what holds the score back.

Feedback:

The async POST inference + poll pattern and the content/request/response digests were clear to work with. The main issue was reliability: the dev-preview endpoint went unresponsive for stretches with 240s+ timeouts, then recovered on retry, which makes live demos risky. A status/health signal and documented expected latency would help. Also, the note that inputs may be logged is easy to miss but critical, since the whole use case is confidential data. A prominent, explicit data-handling and retention statement would make it far easier to trust the enclave with real (not synthetic) documents.

Two quick notes on the code links: confirm those three file paths match your repo exactly (they're the lib modules you built). And if a field wants a specific line rather than a file, open the file on GitHub, click the line number, and use "Copy permalink", that produces a frozen #L link to the exact line, which is what sponsors prefer.