Lumen
Zero knowledge. Full accountability.
Created on 9th May 2026
•
Lumen
Zero knowledge. Full accountability.
The problem Lumen solves
Lumen - Cryptographically Safe Whistleblowing
Workers who witness corporate misconduct face an impossible choice: speak up and lose your livelihood, or stay silent and watch it happen again.
Lumen makes whistleblowing cryptographically safe.
A worker proves they are a verified employee of a company without revealing who they are. The proof is a RISC Zero ZK-STARK anchored to a Poseidon Merkle tree of employee badges managed on-chain. The report goes to IPFS; the proof goes on Sepolia. No one - not the company, not the platform, not even Lumen - can link the submission back to an individual.
HOW IT WORKS
For Employees
Submit structured disclosures (misconduct, misclassification, misleading ESG claims, selective disclosure, hollow promises, in-name-only programs) with sanitized evidence - EXIF-stripped images, XMP-cleaned PDFs - so metadata cannot de-anonymize you.
You get a pseudonymous ENS subname like worker-7f3a.workers.acme.lumen-demo.eth that builds credibility across multiple reports without ever revealing your identity. Each report carries a nullifier (prevents double-filing per quarter) and a Merkle root freshness check (proves your badge was valid when the report was filed).
For Journalists and Researchers
Browse a public feed of on-chain-verified reports, filterable by company or category. Every report includes a cryptographically auditable paper trail, verifiable via standard eth_call.
Want deeper context? Purchase AI-enriched context packs via X402 micropayments (1 USDC on Base, powered by Apify) without touching a subscription or creating an account. Pay once, access immediately, no signup friction.
For Company Compliance Teams
See a live signal of internal sentiment you cannot suppress. Reports are immutable once the ZK proof is verified on-chain. The journal digest is verified by the RISC Zero router on Sepolia - mathematical proof, not trust.
For Investors and Regulators
Every report carries a nullifier (prevents double-filing per quarter), a Merkle root freshness check (badge was valid when filed), and a journal digest verified by the RISC Zero router on Sepolia. All readable via standard eth_call - no proprietary APIs.
ONBOARDING: NO WALLET, NO PROBLEM
A worker enters their work email, receives an OTP to verify domain ownership, and the backend derives a deterministic badge secret from a hash of the verified email domain.
A single claimBadge transaction (optionally gasless via ERC-2771 meta-transactions) places them in the Merkle tree. No wallet seed phrase is ever linked to an email address - the ZK proof is the only bridge between on-chain verification and off-chain identity.
Once claimed, the worker downloads their badge as a JSON file. That is their key. Losing it means losing the ability to file under that pseudonym, but it can never be traced back to their email.
INTEGRATIONS
Apify Context Packs (Live on Base)
When a journalist clicks "Enrich this report," Lumen triggers a 402 HTTP challenge. The frontend prompts the user to sign an EIP-3009 transferWithAuthorization typed-data payload for 1 USDC on Base mainnet. Apify verifies the transfer, runs a web scraping and LLM enrichment job cross-referencing the report against public filings, news articles, Glassdoor reviews, and SEC disclosures, and returns an IPFS CID of the enrichment pack within 60 seconds. No credit card, no subscription wall, no email signup.
Umia Trustless Compute (Future)
For automated verification of structured claims, Lumen is designed to integrate Umia's verifiable LLM inference. A ZK proof of the LLM inference is posted on-chain alongside the report's proof - cryptographic proof of both who filed the report and that an AI verified the claim's plausibility, without trusting the AI provider or Lumen.
THE STACK
Identity: ENS subnames for pseudonymous reputation (worker-7f3a.workers.acme.lumen-demo.eth)
ZK Proofs: RISC Zero zkVM (STARK), on-chain verification via Sepolia
Membership: Poseidon Merkle tree (depth 16, BN254 field) with 7-day root freshness
Storage: IPFS (Pinata) for reports and evidence, canonical JSON (RFC 8785)
Key Management: Space KMS (Orbitport) for secure badge credential storage
Payments: X402 (EIP-3009 USDC on Base) via Apify for context packs
Anti-replay: Nullifiers prevent double-filing per quarter (90 days)
Evidence sanitization: EXIF stripping (images), XMP removal (PDFs via qpdf)
WHY THIS MATTERS NOW
Greenwashing is a $2.4B/year problem. Workers see it first. But without protection, they cannot speak.
Lumen flips the incentive: filing a report is safer than staying silent. The proof is public. The identity is not. The truth is immutable.
Challenges we ran into
Challenges We Overcame
1. Development vs. Production ZK Proof Verification
The production RISC Zero verifier on Sepolia rejected our development-mode proofs during initial testing. We implemented a mock verifier path that accepts dev proofs for rapid iteration while preserving the real verification flow for mainnet deployment.
2. Cross-Language Cryptographic Serialization
Matching the ZK circuit's proof journal format with Solidity's ABI encoding required deep coordination between Rust and EVM serialization standards. We locked the encoding contract with cross-platform test vectors to prevent silent failures.
3. Hash Function Constant Alignment Across ZK and EVM
Our Poseidon hash implementation needed identical round constants and domain separation tags in both the zero-knowledge circuit (Rust) and on-chain verification (Solidity). A single mismatch causes silent Merkle proof failures with no revert reason.
4. ENS Permission Model vs. Worker Anonymity
ENS subname text records require admin signatures, but workers must remain pseudonymous. We redesigned the flow to decouple on-chain report verification from ENS metadata writes.
5. HTTP Multipart Handling in Async Proof Pipeline
File upload middleware wasn't registered in the Fastify instance, causing runtime-only failures that TypeScript couldn't catch at compile time. We added startup smoke tests to catch configuration errors before deployment.
6. IPFS Content Addressing for Evidence Integrity
Ensuring sanitized evidence files (EXIF-stripped images, XMP-cleaned PDFs) maintained cryptographic integrity while removing metadata required careful hash-then-pin workflows to prevent client-server hash mismatches.
7. Merkle Tree Depth vs. Gas Cost Trade-offs
Balancing tree depth (depth 16 = 65K workers) against ZK proof size and on-chain verification cost. Deeper trees support more workers but increase proof generation time and circuit constraints.
8. Nullifier Uniqueness Across Reporting Periods
Preventing double-filing within a quarter while allowing legitimate repeated reports across quarters required deterministic nullifier derivation tied to both the worker's badge and the time period.
9. Root Rotation Without Invalidating Active Proofs
Companies need to add/remove workers by rotating the badge tree root, but workers mid-submission would have their proofs rejected. We implemented an 8-slot ring buffer with 7-day freshness windows.
10. X402 Payment Flow Without Custodial Wallets
Integrating EIP-3009 USDC transfers on Base with HTTP 402 challenges required careful signature validation and replay protection - all without Lumen ever holding user funds.
11. Browser-Side ZK Proof Input Generation
Building 16-level Merkle paths client-side in JavaScript using the same Poseidon constants as the Rust circuit, without leaking the worker's badge secret to the backend or leaving it in browser memory.
12. Async Proof Generation UX
Real ZK proof generation takes minutes on Boundless, not seconds. We built a polling-based status system with proper timeout handling and fallback to local proving for demos.
Tracks Applied (4)
Future Society
SpaceComputer Bounty
SpaceComputer
Most Creative Use of ENS
ENS
Apify Bounty
Apify
Cheer Project
Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.