Lineage Compute

Overview

Lineage is designed as a two-sided compute market. Buyers fund deterministic inference, rendering, and verification jobs. Operators opt in to short sessions, accept compatible work, and submit measurable outputs. A verification service evaluates those outputs before a settlement coordinator includes rewards in a claim epoch.

The system deliberately separates useful computation from financial settlement. GPU execution happens off-chain because that is where commodity hardware is available. Solana records custody, epoch commitments, and completed claims because those records benefit from public inspection.

Design principles

Useful work before rewards

Customer-funded execution is the intended economic base. Benchmarks can test hardware and bootstrap operators, but they cannot create sustainable reward value by themselves.

Verification before settlement

A client-reported score is not proof. Accepted work must be bound to a server-issued lease, a specific input commitment, a deadline, and checks that a modified browser cannot predict in advance.

Liabilities before distribution

An epoch cannot authorize more raw token units than the treasury can cover after accounting for every earlier unclaimed reward. Display prices never substitute for raw-unit solvency.

Explicit trust boundaries

Lineage does not describe an off-chain verifier as trustless. Operator eligibility, job assignment, result acceptance, and root construction remain coordinated services until a stronger proof system replaces them.

Product loop

1. Fund: a buyer creates a bounded job and deposits its execution budget.
2. Lease: the coordinator issues a signed, short-lived lease to a compatible operator.
3. Execute: the browser worker downloads committed inputs and performs the requested GPU work.
4. Submit: the worker returns outputs, timing evidence, adapter capability, and the lease identifier.
5. Verify: the verifier checks commitments, ceilings, hidden challenges, and selected independent replays.
6. Account: an accepted result becomes a reward ledger entry under a published allocation policy.
7. Commit: the settlement service builds an epoch Merkle tree and publishes its root on Solana.
8. Claim: the operator submits a Merkle proof; the program transfers covered raw token units and creates a claim receipt.

System architecture

Minimum Solana accounts

• ProtocolConfig: authorities, fee limits, verifier policy, and paused state.
• AssetVault: mint, token account, cumulative deposits, liabilities, and paid units.
• Epoch: sequence, Merkle root, asset totals, close time, and accounting hash.
• ClaimReceipt: epoch and wallet pair preventing a second claim.

Verification model

Lineage uses layered defenses rather than treating one benchmark result as proof. The target is economically meaningful confidence, not a claim that arbitrary GPU work is perfectly verifiable.

• Signed leases bind a wallet, workload, nonce, input hash, deadline, and maximum reward.
• Hidden challenges introduce unpredictable inputs that cannot be precomputed from public client code.
• Deterministic workloads are preferred where an output can be reproduced within an accepted numerical tolerance.
• Independent replay re-runs a sample of work on verifier-controlled infrastructure.
• Ceilings and anomaly detection limit impossible throughput, duplicate output, and coordinated abuse.
• Reputation influences assignment limits but never replaces validation of the current result.

Solana settlement

Accepted work is accumulated off-chain during a six-hour epoch. Before closure, the settler converts every entitlement into the payout mint's raw integer units, verifies vault coverage, and builds a deterministic Merkle tree. The root and total liability by asset are written to an Epoch account.

A claim instruction verifies the leaf, confirms that the epoch is active, checks that no receipt exists, transfers tokens from the appropriate vault, and creates the receipt atomically. This makes duplicate claims fail without depending on an off-chain database.

Root reproducibility

Each closed epoch should publish a downloadable manifest containing sorted leaves, allocation policy version, source revenue, conversion records, raw-unit totals, and the resulting root. An independent tool must reproduce the root byte for byte.

Hardware-matched reward reserves

Lineage maps verifier-accepted NVIDIA, AMD, Intel, and Apple runs to NVDAx, AMDx, INTCx, and AAPLx on Solana. A run whose vendor cannot be established maps to NVDAx. The mint is part of every settlement leaf so one wallet can receive different assets without mixing vault liabilities.

Acquisition must use supported Solana assets, compliant counterparties, and regionally permitted distribution. Token-2022 features, including scaled UI amounts, require raw-balance accounting and operational pauses around multiplier changes.

• Every eligible mint has an allowlisted vault.
• Only realized and reconciled revenue can fund acquisition.
• Existing liabilities are reserved before a new epoch closes.
• Price displays are informational; claim solvency is measured in raw units.
• Emergency pause prevents new claims while preserving the public accounting trail.

Lineage token

The planned Lineage coordination asset has a fixed display configuration of 1,000,000,000 units on Solana with six decimals. The mint remains TBA and the intended public launch venue is OTC.

Its proposed role is access, not payout. A 24-hour mining pass reads the wallet's $LINEAGE value when issued: holder at $30 or more receives x1.0, operator at $300 or more receives x1.25, and foundry at $3,000 or more receives x1.5. A later balance change applies only when the next pass is issued.

$LINEAGE does not make an unverified browser score valid, replace treasury solvency, or guarantee a reward. The planned treasury allocation is 10% of supply. Its purpose is to retain OTC holder rewards as supplemental stock inventory for verified runner payouts; those assets remain subject to vault coverage and settlement policy.

Economic model

Revenue should come from compute buyers, verification services, and clearly disclosed platform fees. A finite launch subsidy may accelerate testing, but it must be budgeted separately and cannot be described as workload revenue.

Proposed reward formula

The nominal policy is ($0.10 base + $0.0009 × verified VCU) × treasury governor × pass tier. A network VCU must be calculated from independently measured, instrument-specific work; the arbitrary local Lineage units shown by the preview are not eligible VCUs.

At each six-hour settlement, the governor compares nominal 24-hour liabilities with treasury value and scales the epoch toward a maximum distribution target of 3% of the vault per day. Rate movement is bounded to 2× per settlement with a proposed floor of 0.1. The program can pay only assets already deposited in allowlisted vaults.

Illustrative revenue waterfall

1. Buyer payment clears payment and infrastructure costs.
2. Operator compensation funds accepted execution.
3. Verifier compensation funds replay and integrity checks.
4. A protocol fee supports coordination, development, and risk reserves.
5. The reward reserve allocation acquires the xStock matching each verified GPU vendor for future epochs.

All percentages remain configuration proposals until real workload costs, fraud rates, asset access, and legal constraints are measured.

Threat model

• Fabricated work: modified clients submit invented timing or results.
• Replay: a valid output is reused across leases or wallets.
• Sybil operation: one operator presents many identities to bypass limits.
• Verifier compromise: a coordinator accepts invalid work or censors valid work.
• Insolvent root: settlement commits liabilities beyond vault coverage.
• Key compromise: a hot signer publishes a malicious root or changes configuration.
• Privacy leakage: GPU metadata or model inputs expose user or buyer information.

Production readiness requires independent program review, multisig controls, least-privilege service keys, reproducible epoch tooling, incident procedures, monitoring, and a public disclosure of every remaining centralized decision.

Staged roadmap

Phase 0: local prototype

Browser capability checks, interface validation, workload schema, and deterministic test vectors. No token rewards.

Phase 1: closed compute pilot

Approved operators, customer-funded test jobs, server-side replay, fiat or stablecoin accounting, and measured fraud rates.

Phase 2: devnet settlement

Vault accounts, epoch roots, claim receipts, root reproduction tools, multisig procedures, and adversarial testing.

Phase 3: limited mainnet

Capped assets and liabilities, audited program, restricted workload classes, monitored claims, and conservative acquisition limits.

Phase 4: open market

Broader operator access only after useful demand, verification costs, compliance, solvency, and unit economics are demonstrated.