ProofChain

Four AI agents audit supplier sustainability documents, a human reviewer decides, and the verdict is sealed on Ethereum. No more greenwashing, no more taking anyone's word for it.

Comment

Inspiration

Greenwashing is everywhere in fashion and textiles. Brands claim "100% recycled", "carbon neutral", "sustainably sourced" — but buyers have no way to verify any of it. The documents exist — certificates, invoices, lab reports, energy records — but nobody systematically cross-checks them. A procurement manager at a mid-size brand receives a folder of PDFs from a supplier and is expected to just trust it. We wanted to change that

What it does

ProofChain AI is a supplier sustainability verification platform. A buyer uploads evidence documents from a supplier — recycling certificates, purchase invoices, composition lab reports, energy consumption records. Four AI agents work through the evidence in sequence: the first extracts structured facts from every document, the second runs eight deterministic cross-checks, the third calculates a transparent carbon footprint from raw activity data, and the fourth writes a narrative audit report with a recommendation. A human reviewer makes the final call — Verified, Rejected, or Needs Evidence — and the decision is hashed and written permanently to the Ethereum Sepolia blockchain. Anyone with the batch code can scan a QR code, read the public passport, and independently verify the record has not been altered.

How we built it

The stack is a Next.js modular monolith — one codebase handles the UI, API routes, and all agent logic. Supabase provides Postgres and private file storage. The agents are plain TypeScript functions with no LangChain or agent framework. Agent 1 and Agent 4 call an LLM, Agents 2 and 3 are fully deterministic. The smart contract is written in Solidity 0.8.24, tested with Foundry, and deployed to Sepolia. The canonical record hash uses keccak256 over a deterministically serialised JSON object, matching exactly what the contract stores on-chain.

Challenges we ran into

LLM quota limits and model availability broke the demo repeatedly. This was our biggest practical problem and we want to be honest about it. The free tier on Gemini allows only 20 requests per day — each document extraction is one LLM call, so four documents plus retries exhausted the daily limit within a single test session. We switched models multiple times during development: gemini-2.5-flash was blocked for new API keys, gemini-3.5-flash worked but hit its daily cap, gemini-3.5-flash-lite was tried next. Each switch required resetting the database, clearing failed extraction records, and re-running analysis.

Accomplishments that we're proud of

Document extraction is the most fragile part of the system. When the LLM quota is exhausted or the model returns an unexpected response format, all four documents silently fail with EXTRACTION_FAILED status. This means Agent 2 sees no documents at all — every cross-check returns UNKNOWN or FLAG, the ceiling becomes REQUEST_EVIDENCE, and the reviewer cannot verify the batch. The carbon calculation still works because it is deterministic and does not touch the LLM, but the document intelligence layer is completely blocked. At the time of submission the LLM pipeline is functional using Groq as an alternative provider, but we encountered this failure mode enough times that we want to name it clearly.

Model response format inconsistencies caused Zod schema validation failures even when the LLM returned valid-looking JSON. Thinking models like gemini-3.5-flash include a thoughtSignature field in their response parts, which caused the .text getter to throw a console warning in the Next.js server context. We fixed this by extracting text directly from response parts rather than using the SDK's convenience getter, and by adding markdown code fence stripping before JSON parsing.

Blockchain verification required careful attention to canonical serialisation. Getting the keccak256 hash to match exactly between TypeScript and Solidity required deterministic key ordering, consistent ISO timestamp formatting, and ensuring the decided_at field was normalised the same way at decision time and at verify time.

Keeping the AI honest was a core design challenge. The Auditor cannot upgrade its recommendation above the ceiling set by the deterministic cross-checker — enforced in code, not by prompt. Uncited statements are dropped in post-processing. The reviewer override for high-severity flags requires explicit confirmation. Every guardrail exists because we wanted the output to be usable as audit evidence

The "proves integrity, not truth" problem shaped the entire UX. The blockchain record proves the decision was not altered after it was recorded. It does not prove the underlying documents are authentic. Getting that nuance into the UI — the caveat on the passport page, the ILLUSTRATIVE FACTORS label on carbon numbers, the DEMO DATA banner — took more iteration than any single feature.

What we learned

Deterministic agents are underrated. The cross-checker and climate analyst produce fully reproducible results, have unit tests covering every rule, and are far easier to debug and trust than LLM-based equivalents. The LLM is valuable for extraction and narrative — tasks that are genuinely hard to express as rules — but everything that can be deterministic should be.

We also learned that LLM reliability is a product problem, not just an engineering one. Quota limits, model deprecations, and response format changes are operational risks that need fallback strategies, not just error handling. Building the provider abstraction to support both Gemini and Groq was the right call, but we should have done it from the start rather than after hitting the wall

What's next for ProofChain

What's next for ProofChain Fix the LLM layer first. The most immediate priority is making document extraction reliable. That means moving to a paid API tier to eliminate quota failures, adding proper retry logic with exponential backoff, and building a dead letter queue so failed extractions can be retried without resetting the entire batch. The fragility of the current pipeline is the single biggest barrier to real use.

Supplier portal. Right now suppliers hand documents to a procurement manager who uploads on their behalf. That is fine for a demo but not for production. Suppliers need their own login, the ability to upload directly, and a view that shows them exactly what is missing and why a claim was flagged — without exposing the reviewer's notes or internal scoring.

Multi-reviewer workflows. A single passcode is demo-grade auth. A real deployment needs SSO, named reviewer accounts, approval chains for high-value batches, and an audit trail that shows which human made which call and when. The database schema already has the right shape for this — it just needs proper identity attached to decisions.

PDF support that actually works. The current PDF extractor uses unpdf for text extraction. Scanned PDFs return no text and are marked NO_TEXT. Most real supplier certificates are scanned images. OCR integration — either via a cloud Vision API or a local Tesseract layer — is essential for the system to handle real-world documents.

Verified emission factors. Every carbon number in the system is currently labelled ILLUSTRATIVE_FACTORS because the emission factors in emission-factors.json are placeholders. Replacing them with cited, country-specific, year-specific figures from DEFRA, GHG Protocol, or IEA tables — and setting verified: true — would make the carbon output genuinely useful for reporting rather than directionally indicative.

Mainnet deployment. Sepolia is a testnet. Moving the registry contract to Ethereum mainnet or a cheaper L2 (Base, Arbitrum, Polygon) would make the blockchain anchor carry real economic weight. The contract is already written and tested — deployment is a configuration change, not a code change.

Batch-level credential NFTs. Once a batch is verified, issue a non-transferable NFT (ERC-5192) to the supplier's wallet as a machine-readable proof of the verification. This would let downstream buyers verify credentials programmatically without going through the ProofChain UI.

Regulatory alignment. The EU's Corporate Sustainability Reporting Directive (CSRD) and the proposed Digital Product Passport (DPP) regulation are creating mandatory disclosure requirements for exactly the kind of supply chain data ProofChain handles. Aligning the data model and export format to those standards would make ProofChain a compliance tool, not just an internal audit tool.

The long term. A network of verified batches creates a dataset that individual companies cannot build alone — cross-supplier benchmarks, industry-level carbon intensity by product category, red flags that appear across multiple suppliers. That aggregate intelligence is the real value, and it only exists if the underlying verification is trustworthy enough that the data is worth aggregating.

Built With

Share this project:

Updates

Submission history