PaperChain

A decentralized DApp for scientific peer review on the Internet Computer.

Scientific peer review is under increasing strain — major ML conferences now rely on tens of thousands of reviewers, making calibration difficult and consistency uneven. PaperChain explores whether the core mechanics of peer review — identity, incentives, transparent scoring, and lifecycle state transitions — can be encoded in a compact, auditable decentralized application.

Reviewers write all reviews themselves. An off-chain AI component (RevAI) produces rubric-based quality scores, and the canister deterministically maps those scores to token rewards — keeping automation narrowly scoped and the logic fully auditable.

Built for the Distributed Systems course at USI (Università della Svizzera italiana), December 2025.

For the full thesis, motivation, and roadmap, see VISION.md. For the detailed system design (entity model, roles, tokenomics, matching), see DESIGN.md.

Submit paper (stake 100 tokens)
        ↓
  Pre-publishing phase
  (reviewers sign up)
        ↓
  Review phase
  (reviewers submit reviews → scored by RevAI)
        ↓
  Published or Rejected

Review rewards are distributed proportionally by reviewScore:

reviewScore = 0.6 × (AI quality score) + 0.4 × (speed bonus)

The speed bonus rewards early reviewers relative to the signup deadline. If all scores are zero, no tokens are paid out.

Each researcher has an R-Index combining publication activity, review activity, and AI-assessed review quality:

R-index = (34 × papers_score + 33 × reviews_score + 33 × avg_AI_score) / 100

papers_score  = min(100, 10 × published_papers)
reviews_score = min(100, 5  × reviews_submitted)
avg_AI_score  = average RevAI score across all reviews

When a review is submitted, RevAI sends the paper abstract, review text, and a fixed scoring rubric to the Google Gemini API, returning only a numeric score (0–100). The prompt is stored in the repository for transparency. RevAI runs off-chain; the canister treats the score as an external input and applies the reward formula deterministically.

src/
├── backend/
│   ├── main.mo          # Core canister: profiles, papers, tokens, reviews
│   ├── ReviewManager.mo # RevAI integration and reward distribution
│   └── types.mo         # Shared data structures
└── frontend/
    └── (React + Vite + Tailwind)

• Backend: Motoko canister on the Internet Computer. All state (profiles, papers, reviews) lives in canister memory. Authorization is principal-based via Internet Identity.
• Frontend: React + Vite + Tailwind, interacting with the canister through dfx-generated bindings.
• Identity: Internet Identity — no passwords, no centralized auth.

• Node.js v16+ — nodejs.org
• DFINITY SDK (dfx) — install via:

  sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh)"

• A Gemini API key — set it in src/backend/ReviewManager.mo (replace YOUR_GEMINI_API_KEY)

# Deploy everything (recommended)
./run.sh

The script stops any running dfx processes, installs frontend dependencies, starts a clean local replica, deploys all canisters, and launches the frontend at http://localhost:5173.

cd src/frontend && npm install && cd ../..
dfx start --background --clean
dfx deploy
cd src/frontend && npm run dev

Then open http://localhost:5173, log in with Internet Identity, register your profile, and start submitting or reviewing papers.

• Review spam: No rate limiting, uniqueness constraint, or minimum-content check — the platform is currently vulnerable to Sybil-style attacks.
• AI-only scoring: RevAI is a single point of failure; it introduces bias and version instability with no human calibration fallback.
• Simple token model: Rewards dilute as reviewer count grows; no inflation controls or reputation-weighted payouts.
• Fixed submission cost: 100-token stake is uniform — no market mechanism for authors to signal paper importance.
• Rigid deadlines: Signup and review windows are global and cannot be configured per paper.
• Monolithic storage: Papers and reviews live directly in canister memory; large PDFs hit limits quickly.
• No revision/appeal flow: No way to edit reviews, appeal decisions, or hold post-review discussion.

• Reproducible or model-agnostic scoring (reduce LLM dependency)
• Sybil-resistant reviewer verification (e.g. SheerID)
• One review per user, minimum content, stricter timing enforcement
• Split backend into multiple canisters for modularity
• Off-chain storage (IPFS) for paper content
• Second-layer meta-reviewing to calibrate review quality
• Certified variables / verifiable logs for full auditability

Built by @justvicthor, @kybeka, @giolagioia, @LucaLeonx, and @pareek-ml.