Eva Protocol WhitepaperAligned edition · March 2026
Public whitepaper

A trust graph for article verification on Avalanche.

Eva Protocol is a curator network. Curators register with stake, submit source URLs, and build a measurable track record as Eva verifies claims and writes evidence-linked results back to Avalanche.

1. Abstract

The current Eva Protocol product is not a prediction market and not a marketing-only landing page. It is a live trust graph with three product surfaces: curator onboarding, article verification, and curator or article detail pages that read the same canonical on-chain state the backend writes to.

The system is Avalanche-first. `EvaTrustGraph` is the canonical source of article and curator state. ERC-8004 registries remain part of the trust boundary for identity, validation receipts, and reputation events.

2. Product

  • Curators register with an owned ERC-8004 agent identity and self-stake.
  • Curators submit source URLs they want Eva to verify.
  • Eva extracts factual claims, checks evidence, stores a report, and updates trust.
  • Readers and agents consume the resulting trust graph through the UI and API.

The key product decision is alignment: the frontend now consumes backend response schemas for verification and detail views, while the backend reads canonical on-chain state from the deployed trust-graph contract.

3. Verification Flow

  1. Fetch the submitted article and normalize the content.
  2. Extract factual claims suitable for verification.
  3. Check on-chain claims against blockchain data and off-chain claims against web evidence.
  4. Score each claim and compute an overall article score.
  5. Store the report and write feedback or validation receipts on Avalanche.
  6. Surface the result through `/api/verify`, `/api/article/:id`, and the UI.

4. Architecture

Frontend

Next.js on Vercel. Curator onboarding, live article views, and verification UI.

Backend

Hono API for verification, article detail, curator detail, and trust summaries.

On-chain

EvaTrustGraph plus ERC-8004 registries on Avalanche C-Chain.

Register curator→Submit source→Verify claims→Update trust

Vercel is the canonical deployment target for the product surface. The frontend is a dynamic Next.js app, and the backend routes are exposed through the same domain so article, curator, trust, and verification views do not drift across environments.

5. Contract Boundary

  • Source of truth: the deployed `EvaTrustGraph` contract on Avalanche.
  • Generated interfaces: frontend and backend both consume ABI output generated from the Solidity artifact instead of maintaining hand-written partial ABIs.
  • Identity model: the Eva oracle uses agent #1599, but curator onboarding requires each curator to supply and own their own agent ID.

6. Public API

The public surface is intentionally narrow and explicit:

  • POST /api/verify accepts a source URL and returns a scored report plus honest payment metadata.
  • GET /api/article and GET /api/article/:id return on-chain article state plus stored report data when available.
  • GET /api/curators and GET /api/curator/:id return live curator detail instead of placeholders.
  • GET /api/trust/:address reads trust against the same tag semantics the backend writes.

x402 remains a roadmap item. Payment enforcement is not claimed as live unless request verification is actually implemented end-to-end.

7. Roadmap

Now

Dynamic article and curator routes, real curator APIs, shared config, honest verification responses, and ABI generation from the deployed contract.

Next

Harden verification persistence, add broader route coverage, and formalize deployment smoke tests for Vercel previews.

Later

Implement real x402 request verification if payment gating remains a product requirement.

Future research

Explore broader trust distribution mechanics without letting speculative concepts replace the core trust-graph product.

8. Archived Concepts

Earlier drafts of Eva Protocol described prediction markets, cross-chain x402 settlement, and broader tokenomics as if they were active product features. They are not the live product surface and should be treated as archived research material unless they are reintroduced behind a concrete implementation plan.

The repo now treats those concepts as roadmap context only. The trust graph, verification pipeline, and curator onboarding flow are the canonical product.