VERNOD Whitepaper

Proof-of-Useful-Compute for AI · designed for Solana settlement
Technical draft · V1 interface · October 2026
1. Introduction

Abstract. The world is full of idle accelerators and hungry AI workloads, yet the two rarely meet in a market that pays fairly for real work. Classical crypto mining burns electricity on hashes that secure a ledger but produce nothing else; proof-of-stake pays capital for holding capital. VERNOD proposes a third path: proof of useful compute — a network in which miners earn the native token $VERNOD by contributing verifiable AI computation (inference and training jobs) rather than wasted hashpower. Work is metered in verified TFLOP-hours, checked by a redundant verifier mesh, pooled in an open mining pool we call the Backplane, and settled on Solana. The original design proposes a token-first community launch; the compute mining network is then built on top of it, turning holders into an economy that pays for real machine work. This paper specifies the mining mechanism, the reward and emission model, the verification game, and the settlement path. Like a modular compute backplane, VERNOD turns scattered accelerators into coordinated, verifiable capacity that settles into value.

Keywords: proof of useful work, AI compute, decentralized mining, verifiable computation, token emission, mining pools, Solana, fair launch.

1Introduction

Two curves are diverging. On one side, the demand for AI compute is compounding faster than any resource in modern computing history. On the other, an enormous installed base of GPUs and accelerators sits idle — in gaming rigs, in half-used data centers, in mining farms stranded by the end of proof-of-work. The market that should connect them barely exists, and the token economies that could coordinate it are busy paying for work that produces nothing.

VERNOD exists to close that gap. Instead of rewarding miners for guessing hashes (proof of work) or for locking up coins (proof of stake), the proposed VERNOD design rewards them for performing useful computation the network actually needs — AI inference and training jobs — and aims to verify that the work meets its acceptance criteria before paying for it. We call this Proof of Useful Compute (PoUC).

1.1 Why now, and why a token first

A compute network is only as valuable as the demand flowing through it, and demand follows liquidity and attention. The proposed VERNOD launch plan reverses the typical order of an infrastructure project: the $VERNOD token would launch first, as a fair, community-owned coin under the proposed launch plan (Section 9), seeding an aligned community and a liquid unit of account. The mining network — the pool, the verifier mesh, the settlement programs — is then built on top of that token, so that the people who believed early become the miners, verifiers and customers of the network they own.

1.2 Why Solana

Rewards must settle somewhere fast, cheap and close to real financial rails. We target Solana as the settlement layer for mining epochs. Its high-throughput runtime, low transaction costs, and mature SPL tooling suit frequent reward settlement. Compute proofs are verified off-chain; only the compact, signed result of each epoch is committed by the VERNOD Solana program, where rewards are distributed through SPL token accounts. This keeps verification practical while preserving an auditable on-chain settlement record.

1.3 Contributions

  • A proposed Proof-of-Useful-Compute mining mechanism that meters AI work in verified TFLOP-hours and prices it in $VERNOD.
  • A redundant verifier mesh with a challenge game intended to discourage fake work under the assumptions in Section 8.
  • An open mining pool (the Backplane) with a transparent, share-based reward split and a halving emission schedule.
  • A proposed fair-launch token policy intended to bootstrap the later network; allocation and launch claims require confirmed token evidence.

2The Modular Compute Layer

VERNOD treats distributed compute as a modular electronic system. Idle accelerators are independent components, AI jobs are incoming signals, and the protocol is the control plane that routes, verifies, and settles useful work. The system uses four explicit stages, shared with the task replay: Dispatch, Execute, Verify and Settle.

  • Dispatch (demand). Streams of AI jobs — inference requests, fine-tuning and training batches — enter the network and are matched to available compute.
  • Execute (work). A miner accepts a job, runs it on its hardware, and returns the output together with a proof. One accepted unit is a verified execution.
  • Verify (acceptance). Profiled outputs are checked against task-specific acceptance criteria; rejected attempts earn no accepted work.
  • Settle (reward). Verified executions are aggregated per epoch and paid out in $VERNOD according to each miner's share of useful compute.
In one line: demand enters as jobs, miners execute the work, and verified output settles into $VERNOD. Everything the protocol does is a variation on measuring and pricing the execution.

2.1 Notation

Let the network contain N miners. In the model, epoch t spans one elapsed hour. Interface timestamps use US Eastern Time, observing EST or EDT as applicable. Accepted effective work for miner i is Wi,t, measured in TFLOP·h. A task-specific quality factor is applied once, after acceptance; rejected attempts contribute zero. The period total is Wt = Σi Wi,t. Bt is the separately defined minerRewardBudget in $VERNOD, and ρi,t is the miner's reward for that same epoch. Rate (TFLOP/s), occupied-capacity utilization (%) and accepted work (TFLOP·h) are distinct measurements.

3Proof of Useful Compute

The core problem is old and hard: how do you pay someone for a computation without re-running it yourself? VERNOD does not claim a single silver bullet; it combines cheap statistical checks with an economic dispute game intended to make honest computation economically preferable under stated detection and incentive assumptions. The pipeline from job to reward has four stages.

1 · Dispatch job → miner 2 · Execute run AI compute 3 · Verify redundant + challenge 4 · Settle distribute reward budget
Figure 1. The PoUC pipeline. Jobs are dispatched to miners, executed, verified by a redundant mesh with an economic challenge window, and settled as $VERNOD each epoch.

3.1 Metering work

Raw FLOPs are easy to claim and hard to trust, so VERNOD meters accepted output, not self-reported cycles. Each job has a known compute profile (model, input size, precision); a correctly returned result is credited its profiled TFLOP-hours, scaled by the miner's quality multiplier. A miner's effective work in an epoch is

Wi,t = Σj ∈ acceptedJobs(i,t) qj · cj (1)

where cj is the task profile in TFLOP·h and qj is its accepted quality factor in [0, 1]. Only accepted tasks enter this sum. The factor is applied here once; the reward calculation does not discount it again. Rejected or retried attempts are excluded, and only the final accepted attempt may contribute. This metered work is distinct from the GPU’s nameplate FLOP/s rate.

3.2 The verification game

Verification uses redundant sampling: a fraction s of jobs are dispatched to two or more independent miners, and their outputs are compared (exactly for deterministic jobs, within tolerance for stochastic ones). Any accepted result may additionally be challenged inside a fixed window by a verifier who re-runs it and posts a bond. If the challenge succeeds, the cheating miner's stake is slashed and the challenger is rewarded; if it fails, the challenger loses its bond. These are proposed mechanisms, not features implemented by this front-end replay. Deterrence requires sufficiently independent checks, available honest challengers, enforceable penalties and an expected loss greater than the benefit of cheating; collusion and correlated errors can weaken it.

Under an illustrative model of independent checks that each detect invalid work when performed, the escape probability is

Pescape = (1 − s)(1 − pc) (2)

where s is the probability of a detecting redundant check and pc is the probability of a detecting independent challenge. Equation (2) assumes independence and effective detection; it is not a proven bound for correlated, tolerant or colluding verifiers. Production rates, tolerances and incentive parameters require measurement and security review.

Algorithm 1 — Execution lifecycle · pseudocode
input : job j with profiled compute c_j, value v_j
1  dispatch j to miner i  (and to a shadow miner w.p. s)
2  i runs the model, returns output o_i and commitment h_i
3  if shadowed and o_i ≠ o_shadow within tol: reject; retry if allowed
4  publish {j, h_i} ; open challenge window Δ
5  during Δ any verifier may re-run j, post bond, dispute
6      if dispute upheld:  slash stake(i), reward challenger
7  on acceptance: credit W_{i,t} += q_j · c_j exactly once
8  rejected or retried attempts receive no work credit
output: verified work credited to miner i

3.3 Reward function

At the close of each epoch, a defined miner reward budget is distributed in proportion to accepted effective work. Miner i's reward is

ρi,t = Bt · ( Wi,t / Wt ),   Wt > 0 (3)

Here Bt = minerRewardBudget, Wt = verifiedWorkTotal, and the ratio is minerShare. The reward per work unit is Bt / Wt ($VERNOD / TFLOP·h). When Wt = 0, no reward is allocated. The dashboard, miner details and task records use this same period and formula.

For example, an illustrative budget of 1,000 $VERNOD and accepted work of 100 TFLOP·h gives 10 $VERNOD / TFLOP·h; a miner with 15 TFLOP·h receives 150 $VERNOD (15%). Displays round for readability; accounting first rounds down at the configured token precision, then assigns residual microtokens by largest fractional remainder (stable task ID breaks ties). The sum stays within the budget. A zero-work epoch leaves its budget unallocated. The formal fee and non-miner allocation policy remains pending; no additional fee is deducted from this already defined budget.

4The Backplane · Mining Pool

A single miner's income from a proportional scheme is lumpy — you only get paid when your work lands in a settled epoch. The Backplane is VERNOD's open mining pool: miners contribute compute continuously and receive smoothed rewards proportional to their sustained contribution from a defined miner budget. The formal pool-fee policy is pending. Multiple independent pools may coexist; the protocol treats them as first-class and reports their share of network compute (see the Network simulation dashboard).

4.1 Share accounting

Within a pool, each miner accrues shares equal to its verified work. For each epoch, the configured miner budget is split using accepted work during that exact epoch. This V1 demonstration uses period-proportional accounting, not a separately specified PPLNS window. Accepted contributions remain attributed to their task, miner and epoch IDs; no pool-hopping or retention guarantees are claimed by this interface.

5Solana Settlement

Compute happens off-chain; trust must reach the chain without re-execution. Each epoch, the pool operator aggregates verified work into a signed report — a Merkle root over (miner, verified-work, reward) leaves plus the epoch's parameters — and submits it to the settlement program on Solana.

Off-chain
verifier mesh
pool aggregation
→
Report
signed epoch root
{root, W_t, B_t, sig}
→
On-chain · Solana
VERNOD Pool Program
release · distribute · challenge

The intended design commits one compact report root per epoch. Committing that root may have approximately fixed size, but preparing reports, verifying Merkle paths (typically logarithmic in leaf count), individual claims, account creation and transaction fees add costs that depend on participation and implementation. A challenge window can permit disputes only if monitoring, data availability and enforcement work as designed. No deployed contract or on-chain finality is evidenced by this V1 simulation; the following are design references.

ParameterValue (preview)
Settlement chainSolana
Mining epoch1 hour
Report challenge window30 minutes
Verificationredundant sampling + challenge
Fee / non-miner allocation policyPending confirmation; miner budget is explicit

6Tokenomics

$VERNOD is the proposed network unit of account: customers would pay for compute in it, miners would earn it, and verifiers would post bonds in it. The illustrative release model halves a per-epoch budget at a fixed epoch interval. This is a model of scheduled release, separate from mint authority, circulating float and actual chain supply; no chain state is inferred from it.

Et = E0 · 2−⌊t / H⌋ (4)

where E0 is the initial release per epoch, H is the interval in epochs, and t is an epoch index from an unconfirmed model origin. For an infinite halving schedule the total release is 2E0H; this does not by itself specify token maximum supply, mint permissions or a reserve source. The shared chart below uses the same model parameters as the Token dashboard; no next-halving calendar date is asserted.

Figure 2. Shared release model. The per-epoch view is a step function; cumulative release grows through each stage at that stage’s rate. Hover, tap or select a stage to inspect it. Epoch indices are model indices, not calendar dates.

6.1 Allocation

The model distinguishes maximum supply, minted supply, circulating supply, a period reward budget and cumulative rewards already distributed. These values cannot be substituted for one another. A scheduled budget released from reserves is described as release or distribution; new issuance is called minting only when supported by an actual mint mechanism and chain evidence. The supply figures below retain the previous model references and are not queried chain balances.

Accounting itemMeaning / policy
Miner reward budgetExplicit per-epoch budget, shared proportionally by accepted effective work
Verifier / treasury allocationFormal percentages require confirmation; not deducted a second time
Allocated reward progressDistributed rewards / reward allocation budget for the labelled scope; not maximum token supply mined
Formal fee policyPending reconciliation of prior draft assumptions
Budget scope & data provenance

The V1 terminal uses a fixed, explicitly marked simulation dataset. Its miner budget is a scenario parameter and does not establish a permanent protocol fee or allocation ratio. No verified token mint, historical market feed or deployed settlement program is configured. Original conflicting fee assumptions are retained in the delivery record for confirmation.

7Architecture & Roadmap

The network is four cooperating roles: miners that run AI jobs, a verifier mesh that keeps them honest, pools that aggregate and smooth rewards, and the settlement program on Solana intended to release and distribute rewards. The interface demonstrates Dispatch → Execute → Verify → Settle with stable simulation records.

Dispatch pool · task assignment Execute miner · AI compute Verify mesh · acceptance Settle epoch · reward share
Figure 3. The same four stages used by the terminal replay. Pools dispatch; miners execute; verifiers check acceptance; the epoch budget settles proportionally. This is a front-end mechanism simulation.

7.1 Roadmap

  • Phase 0 — Token identity. Confirm the token mint, launch destination and account ownership before enabling token actions.
  • Phase 1 — Mechanism simulation. The present dashboard is a fixed front-end dataset and replay. A future testnet requires a deployed client, verifier mesh and independently labelled testnet telemetry.
  • Phase 2 — Settlement. VERNOD Pool Program deploys to Solana; epochs settle and rewards distribute on-chain.
  • Phase 3 — Open market. External customers submit paid AI jobs; miner rewards shift from pure emission toward real compute demand.

8Security

The dominant threats to a compute-mining network are fake work and Sybil identities. The proposed design combines verification with economic incentives; effectiveness depends on implementation and threat-model assumptions.

  • Fake work. Sampling and challenges can discourage invalid submissions when detection is independent and the expected enforceable penalty exceeds the cheating gain. This remains a design goal, not a measured guarantee.
  • Sybil identities. Work-proportional accounting avoids an automatic reward for identity count. Dispatch rules, colluding identities and quality scoring still require separate Sybil analysis.
  • Verifier collusion. Independent re-execution, challenge access and data availability are assumptions. Shared model errors or collusion can defeat nominal redundancy and must be tested.
  • Settlement safety. A challenge window helps only if observers can obtain the report, detect an error and enforce a timely dispute. The V1 replay does not implement staking, slashing, economic security or a settlement contract.

9$VERNOD & Fair Launch

The original design proposes a token-first community launch followed by the compute network. No verified project token mint or token-specific trading destination is configured for this replica. The whitepaper therefore presents the complete token model and mechanism without enabling address copy, trade or explorer actions. A plausible address format alone would not prove project ownership.

Current V1 scope: readable model, linked sample records and an interactive task replay. Real compute execution, testnet or mainnet settlement, wallet claims and market prices require their own confirmed deployments and data sources. The four-stage replay demonstrates accounting logic; it does not execute GPU work or submit Solana transactions.

10Disclaimers

This document is a technical and conceptual overview provided for information only. It is not financial, investment or legal advice, and it is not an offer or solicitation to buy any asset. $VERNOD is the proposed community token; the mining network, settlement programs, parameters and emission figures described here are design targets that are not yet deployed and may change. Forward-looking statements carry risk and uncertainty. Digital assets are volatile and you may lose everything you put in. Do your own research and never risk more than you can afford to lose.

Figure detail

Copy manually

Clipboard access is unavailable. Select the complete text below and use your device’s copy command.