Verifiable Tasks

Verifiable tasks. Write them in Lua. Prove they ran.

Proveno runs a small task you write in plain Lua and hands back two things: the result, and a proof of exactly what it did. Trust it because of math — no special hardware, no enclave.

If you can write a script, you can write a verifiable task — no circuits, no cryptography, no ZK expertise.

Two guarantees, one proof

Execution and provenance — side by side.

A verifiable task proves two things, bound into a single proof.

Always

Execution

This exact program ran over exactly these inputs and produced exactly this output — inside a deterministic, sandboxed, bounded VM. This is what proveno does on its own.

With a provider

Provenance

The same proof also attests the inputs were authentic. Proveno binds a provider's attestation to the exact bytes it covers; a provenance provider produces it. Signed feeds and zkTLS plug in at the boundary.

Execution integrity is the floor; provenance completes the picture when you attach a provider. Proveno binds, the provider attests — proveno never claims provenance on its own.

Anatomy of a task

Fetch. Compute. Commit.

Every proveno task has the same shape — and the whole shape is sealed into one proof.

01

Fetch inputs

Pull in external data through a committed tool-call boundary. Each call is recorded in a transcript that becomes part of the proof — and the seam a provenance provider attaches to.

02

Compute in a bounded VM

Run a small Lua task — deterministic, sandboxed, gas- and memory-metered. No floats, no clocks, no nondeterminism.

03

Commit to a proof

Emit a succinct proof binding the program, its inputs, and its output. Verify it off-chain — or on-chain, when a contract must act on the result.

Why the bar is low

Write a task, not a circuit.

This is the line between a zkVM and a circuit DSL like Circom, Halo2, or raw Noir — and the reason you write Lua instead of constraints.

In a circuit DSL, every program is a circuit: a new task means new constraints, a new trusted setup, a new audit. In proveno, tasks are data. One fixed circuit proves any valid task for the ISA — write a new one in Lua and nothing downstream changes.

Proveno sits one notch below RISC-V on generality, but keeps that "programs-are-data" property that makes a zkVM usable — while paying for a far smaller circuit, because the ISA is a high-level scripting language, not bare metal. The language is small enough that an LLM can write the task.

How it works

Trace off-circuit, constrain in-circuit.

Structurally a zkVM — generate a trace, then prove it — with UltraHonk / Noir as today's backend.

Lua task
compilerAST → register-based bytecode + program hash
VMdeterministic, sandboxed, bounded execution → trace
Noir circuitconstrains the trace against the bytecode → UltraHonk proof
verifieroff-chain, or on-chain when a contract acts on the result
Why proveno

Three properties, ranked by how long the edge lasts.

Most general zkVMs have none of them. The order is the point: the durable advantage is the execution model, not the benchmark.

Durable moat

Committed boundary over attested inputs

Tool responses, inputs, outputs, and attestations are first-class public inputs — committed in the proof, with a transcript and deterministic replay around them. It's what makes the provenance pillar possible, and it doesn't decay.

Structural

High-level, LLM-authorable

Proveno proves a Lua-subset bytecode directly — not RISC-V. A task is human-readable and machine-writable, which is why the bar is low and why an LLM can write one. A property of the abstraction level, not a bolt-on.

Present-day

Cheap verification

A small fixed circuit: prove time in seconds, a single UltraHonk verification on-chain. Real today — but the least durable edge, as general zkVMs close the proving-cost gap. A benefit, not the thesis.

Trust model

Trust it because of math, not hardware.

Most ways to get verifiable compute without a cryptography team lean on a trusted enclave — a TEE. Proveno's trust is cryptographic: no special hardware, and a proof a contract can verify natively.

TEE · enclave + attestation
Proveno · ZK proof
Root of trust
Hardware vendor (Intel / AMD / AWS)
Cryptographic assumptions
Special hardware
Required; CPU / cloud lock-in
None — any commodity machine
Side-channels
Long break history
Not in the threat model
On-chain verification
Hard — trust a vendor cert chain
Native — one UltraHonk verify
Inspectable
No — trust the chip
Yes — open verifier

Three honest limits: it proves integrity, not privacy (a TEE can hide data; proveno proves correctness); it's for bounded tasks, not whole apps; and "no trusted hardware" isn't "no trust" — like any SNARK it uses a one-time universal setup, not a per-circuit one.

Use cases

Tasks that need a proof.

The shape that fits: a bounded task that applies a rule to fetched inputs, whose correct application matters to someone who won't — or can't — re-run it.

On-chain unlock

Parametric payouts

Fetch a condition — flight delayed, rainfall below a threshold, event resolved — apply the payout rule, output who gets what. Proveno proves the resolution logic ran honestly; attach a provider and the outcome feed is attested too.

consumed by a settlement contract paying out on the proof
On-chain unlock

Eligibility & policy gating

Evaluate a rule set over fetched attributes — airdrop allocation, allowlists, underwriting, KYC policy. Emit a verdict and a proof the policy was applied. Prove the rule ran; don't just trust the answer.

consumed by a contract gating a claim or mint
Horizontal

Verifiable agent actions

An LLM-authored or LLM-assisted task where control flow is deterministic and the model is content, not control. Proveno proves the logic and commits every model call in the transcript. Prove what the agent actually did.

consumed by anyone auditing an autonomous workflow
Horizontal

Auditable process

Prove a refund, royalty split, or fee was computed per the documented rules from order or usage data. An auditable proof-of-process for disputes and compliance — no chain required.

consumed by auditors, counterparties, regulators
Where it fits

One identity. A first high-value job.

Verifiable tasks are horizontal — useful wherever a result must be trusted. Smart contracts are where that trust unlocks the most value first.

Identity · the product

Verifiable tasks

Write a task in Lua, get a proof it ran — chain-agnostic. The product is the task and its committed I/O boundary, not any single backend or venue.

First job · design partners

On-chain, coprocessor-style

Because the proof verifies cheaply on-chain, a contract can act on a task's result trustlessly. The natural first design-partner motion — an application of proveno, not its category.

The zkVM is the mechanism, not the identity. The Noir circuit is today's backend; it could retarget to SP1 or RISC Zero without changing what proveno is. And proveno touches the oracle world — it consumes attested external data — but it does not claim to be an oracle, because "oracle" promises data provenance, which is the provider's job, not proveno's.