PoUW Technical Specification

Overview

Proof-of-Useful-Work (PoUW) replaces traditional mining by directing computational resources toward generating zero-knowledge proofs that validate execution correctness.

Job Model

Job Tiers

Tier	Scope	Typical Proof Time
`Micro`	Per-instruction	Fast (sub-second)
`Macro`	Per-intent	Medium (seconds)
`Full`	Per-batch	Slow (minutes)

ProofJob Structure

pub struct ProofJob {
    pub job_id: String,               // deterministic: BLAKE3(prefix || intent_id || trace_hash || tier || seq)
    pub tier: JobTier,
    pub intent_id: IntentId,
    pub trace_hash: [u8; 32],         // BLAKE3 of execution trace
    pub trace_ref: String,            // content-addressed blob key
    pub fee_budget: u64,              // upper bound for bids
    pub reward_budget: u64,           // prover compensation
    pub created_at_ms: u64,
    pub created_seq: u64,             // monotonic, replay-safe
    pub lease_expires_at_ms: u64,
    pub deadline_ms: u64,
    pub max_retries: u32,
    pub attempts: u32,
}

Job ID Derivation

Job IDs are deterministic and replay-safe:

job_id = hex(BLAKE3("rivellum-pouw-job-v1" || intent_id || trace_hash || tier || created_seq)[..16])

Job Lifecycle

1. Intent is executed → execution trace produced
2. Trace hashed (BLAKE3), stored as content-addressed blob
3. ProofJob created with trace reference
4. Job enters pending queue
5. Prover claims job (lease granted)
6. Prover downloads trace, generates ZK proof
7. Prover submits proof (base64-encoded)
8. Node verifies proof
9. On success: prover receives reward from fee pool
   On failure: job returns to queue, attempts incremented

Lease Mechanism

Claiming a job grants a time-limited lease
Provers can renew leases before expiry
Expired leases release the job back to the queue
After max_retries failures, jobs go to the dead-letter queue

API

Endpoint	Method	Description
`/v1/pouw/jobs/pending`	GET	List pending jobs
`/v1/pouw/jobs/claim`	POST	Claim next available job
`/v1/pouw/jobs/:id`	GET	Job detail + trace reference
`/v1/pouw/jobs/:id/renew`	POST	Extend lease
`/v1/pouw/jobs/:id/submit`	POST	Submit proof (base64)
`/v1/pouw/jobs/:id/fail`	POST	Report worker failure
`/v1/pouw/jobs/:id/history`	GET	Attempt history
`/v1/pouw/provers`	GET	List registered provers
`/v1/pouw/system/status`	GET	PoUW system status
`/v1/pouw/pool`	GET	Pool status
`/v1/pouw/dead-letter`	GET	Dead-letter queue
`/v1/pouw/events`	GET	PoUW event stream
`/v1/pouw/metrics`	GET	Prometheus metrics

Prover Statistics

{
  "prover_id": "...",
  "jobs_completed": 142,
  "jobs_failed": 3,
  "total_fee_earned": 50000000,
  "avg_completion_time_ms": 2400,
  "last_seen_ms": 1700000000000
}

ZK Backend Selection

The proof system used depends on the job tier and network configuration:

Winterfell (STARKs): Used for batch-level proofs; transparent setup, post-quantum
Plonky2: Used for recursive aggregation of intent-level proofs
Halo2: Alternative backend with no trusted setup requirement

For prover setup instructions, see PoUW Setup. For economic details, see PoUW Economics.