Skip to content
K

Karl Popper

Decentralized Verifiable Sciences

Created on 20th February 2026

•

K

Karl Popper

Decentralized Verifiable Sciences

The problem Karl Popper solves

Scientific publishing has a reproducibility crisis: many results cannot be reproduced, and peer review usually checks narrative quality, not executable truth.
Karl Popper solves this by adding a decentralized verification layer for research claims.
Researchers submit code + data + documentation, and an AI verification agent tests whether the documented conclusions are actually supported by execution results (f(code, data) -> documented claims).

What people can use it for
Researchers: prove their findings are reproducible and auditable.
Reviewers / journals: reduce manual reproducibility burden with automated first-pass verification.
Funding bodies / institutions: track evidence quality with transparent, on-chain records.
Open science communities: create a public, tamper-evident registry of verified scientific outputs.

Why it is safer/easier
Verification output and content hashes are written on-chain.
If artifacts are changed later, hash mismatch exposes tampering.
Results become portable, auditable, and not dependent on a single centralized reviewer.

Challenges I ran into

Testnet deployment friction (Base Sepolia funding)
I initially funded on Ethereum Sepolia, but deployment required gas on Base Sepolia.
I solved this by bridging test ETH to Base Sepolia and validating wallet balance before deployment.
GitHub push protection due to accidental secret exposure
During scripting/automation, an API key appeared in commit history and push was blocked by repository protection.
I removed sensitive values, rewrote the commit content, replaced keys with placeholders, and re-committed safely.
Frontend rendering instability on GitHub Pages
Mermaid-based architecture rendering was inconsistent and caused layout issues in production.
I replaced it with a pure HTML/CSS flowchart and added bounded, scrollable containers for stable rendering.
AI-agent runtime reliability
Agent runs occasionally failed due to deprecated model versions and transient connection errors.
I added model fallback + retry handling, and improved environment loading to make demo execution more reliable.

Use of AI tools and agents

Input ingestion
User submits code, data, and documentation references.
Sandbox execution agent
The agent runs code in an isolated environment and captures objective outputs/logs.
Semantic verification agent (LLM reasoning)
The LLM compares execution outputs against documented claims and detects mismatches or inconsistencies.
DCAS scoring layer
The system maps verification evidence to DCAS-aligned rule scoring.
On-chain attestation pipeline
Final verdict + hashes are prepared for on-chain recording, creating immutable verification provenance.
Multi-agent/tool collaboration pattern
Execution tool provides objective runtime evidence.
Reasoning tool (LLM) interprets whether evidence supports claims.
Scoring logic standardizes outputs into reproducibility metrics.
Blockchain layer anchors outcomes for auditability and tamper detection.
In short: the AI stack combines execution + reasoning + standard-based scoring + on-chain proof to make scientific verification scalable and transparent.

Tracks Applied (3)

Prosperia

Decentralized Verification For Sciences is Public Good. Our thesis: trustworthy science is public infrastructure. If we...Read More

Best Use of AI Inference or Fine Tuning (0G Compute)

I use AI to verify if the code and data can generate consistent results in the documentation.
0g Labs

0g Labs

Base Self-Sustaining Autonomous Agents

I use base as my main implementation given the speed and cost advantage of base
Base

Base

Discussion

Builders also viewed

See more projects on Devfolio