LP-5200: A-Chain Proof-of-AI Mining Standard

Abstract

This LP defines Proof-of-AI (PoAI) mining as useful AI work admitted, verified, and finalized exclusively by PoAI consensus on the Lux A-Chain (aivm). Miners may execute an approved deterministic integer model on a CPU or GPU. A-Chain binds the demand-backed job, consumer, model, input, runtime policy, proof policy, reward, and payout destination before execution; verifies that the committed work was actually performed; consumes one global work nullifier; and emits one finalized mining receipt.

Z-Chain is the Plonky3-derived P3Q proof-compression and settlement rollup for finalized A-Chain receipt transitions. It does not admit work or decide that a mining claim is valid. Another chain may receive the economic result of mining, but it is never a mining or proof authority. A destination verifies the Z-settled, PQ-finalized A-Chain receipt, then releases the authorized representation to the bound recipient. It MUST NOT accept raw work proofs, miner signatures, TEE quotes, or locally maintained "spent work" as an alternative to that receipt.

Activation

Parameter	Value
Flag string	lp5200-ai-mining
Default in code	false until the launch criteria below pass
Activation height	TBD by governance
Back-off plan	Disable new job admission; preserve finalized receipts

Normative mining-authority invariant

A-CHAIN IS THE SOLE POAI CONSENSUS AND MINING AUTHORITY. Only A-Chain may admit a useful mining job, determine that the bound work was actually executed, consume its work nullifier, calculate subsidy, and finalize a mining receipt. A destination chain only verifies and consumes that finalized receipt.

Consequences:

1. "Mine into chain D" means an A-Chain job names D as its payout destination. It does not mean that D verifies the work.
2. The same proof cannot be submitted independently to Hanzo, Zoo, Lux C-Chain, or any external EVM.
3. There is one network-wide issuance allowance, not one cap or halving schedule per chain.
4. Destination-local replay state records consumption of an A-Chain receipt. It does not decide whether the underlying computation was valid.
5. PoAI is A-Chain's useful-work validity consensus. Lux Quasar supplies its validator ordering, fork choice, and finality; Z-Chain P3Q supplies proof compression and settlement. Neither creates a second mining authority.

Consensus, proof settlement, and post-quantum omnichain finality

The protocol has three complementary layers:

1. PoAI useful-work consensus decides that a pre-admitted job was useful under policy, that its bound execution was actually performed, and that one mining receipt may be finalized.
2. Z-Chain P3Q settlement batches finalized A-Chain receipt transitions and verifies their Plonky3-derived, pairing-free STARK/FRI proof after the exact PoAI AIR and verifier are audited and activated. Z-Chain never admits a raw mining job or independently determines useful work.
3. Lux base-layer consensus orders and finalizes the A-Chain and Z-Chain state transitions under Quasar and authenticates exported roots under the activated post-quantum validator policy.

"Useful" is a protocol predicate: the job exists before the result, binds a real requester or network service, specifies a deliverable, and is admitted under a demand or governance policy. The miner cannot generate arbitrary work and self-certify it as useful. Execution evidence separately proves that the bound work was done. Neither predicate claims that an answer is universally true, unbiased, safe, or socially valuable.

The omnichain path is:

1. PoAI consensus finalizes a destination-bound receipt in the A-Chain receipt root.
2. Z-Chain batches that finalized transition and verifies the activated P3Q settlement proof. Before the PoAI circuit is active, Z-Chain may checkpoint only an independently authenticated, already-final A-Chain root and MUST NOT claim succinct proof authority.
3. Quasar finalizes the corresponding A-Chain and Z-Chain roots; the activated PQ policy certifies their heights and validator context.
4. Warp/Teleport, a native atomic boundary, or an authenticated relay transports the Z-settled receipt and inclusion proof.
5. The named destination verifies finality, settlement, inclusion, binding, amount, recipient, and non-consumption, then releases the authorized representation.

This permits mining payout on any supported destination while Lux remains the PQ root of trust and A-Chain remains the only PoAI consensus.

Goals

• Reward pre-admitted inference, embedding, evaluation, and deterministic training deliverables instead of arbitrary hash or chain-derived matrix puzzles.
• Keep honest execution byte-identical across CPU and GPU backends.
• Make CPU mining possible; specialized accelerators improve throughput but are not a consensus requirement.
• Prevent replay and duplicate issuance across all payout destinations.
• Keep confidential-compute evidence optional and explicitly vendor-dependent.
• Permit stronger proof backends without changing the job or receipt identity.

Non-goals

• Proving that an answer is true, unbiased, safe, or economically useful solely from its execution trace.
• Treating a bare output quorum or signature as proof that costly AI execution occurred.
• Letting every EVM deploy an independent AI supply schedule.
• Requiring TEE hardware for public deterministic jobs.

Protocol objects

Mining job

Every subsidy-eligible unit of work begins as an A-Chain job:

MiningJob {
    version
    job_id
    policy_epoch
    requester
    miner_eligibility_policy
    model_spec_hash
    input_commitment
    execution_spec_hash
    proof_policy
    reward_budget
    expiry_height
    destination_chain_id
    destination_recipient
    nonce
}

job_id MUST commit to every field above and to the A-Chain network identifier. The model, input, execution policy, proof policy, and destination are fixed before the miner commits a result.

The requester establishes usefulness by funding or otherwise authorizing a real task. PoAI establishes execution accountability for the admitted task. These are different properties and MUST NOT be conflated.

Execution specification

The deterministic software path uses quantized integer execution:

• integer weights and activations, normally int8;
• a specified wider accumulator (int32 or int64) with defined overflow rules;
• canonical tensor layout and serialization;
• fixed reduction, saturation, rounding, and dequantization rules;
• deterministic routing, normalization, sampling, and tie-breaking;
• a measured model-weight root and execution-runtime identifier.

An honest CPU and GPU implementation of the same execution specification MUST produce identical committed integer values. Floating-point tolerance is not a valid substitute for this requirement.

Execution commitment

Before the challenge beacon is known, the miner commits:

ExecutionCommitment {
    job_id
    miner
    model_spec_hash
    input_commitment
    output_commitment
    execution_spec_hash
    transcript_root
    metering_root
    commit_height
}

The transcript commits the proof-bearing operations and their graph wiring. The metering commitment binds the work quantity used by the reward calculation; a correct output alone does not prove a claimed FLOP, token, or time count.

Work nullifier

The canonical nullifier is A-Chain state:

work_nullifier = keccak256(
    "lux/aivm/poai-nullifier/v1"
    || a_chain_id
    || policy_epoch
    || job_id
    || execution_commitment
)

A-Chain consumes the nullifier atomically with receipt finalization. A key based only on (model, input, output) is not sufficient: two legitimate jobs may ask the same deterministic question, and a predictable tuple can be pre-claimed.

Finalized mining receipt

MiningReceipt {
    version
    job_id
    work_nullifier
    miner
    requester
    model_spec_hash
    input_commitment
    output_commitment
    execution_spec_hash
    proof_policy
    proof_finality
    measured_work
    demand_fee
    subsidy_authorized
    destination_chain_id
    destination_recipient
    settled_at_height
}

The receipt is committed under the A-Chain receipt root. Only a finalized receipt with a consumed nullifier and nonzero accepted output is payout-actionable.

Proof policies

Deterministic recomputation

A-Chain validators or an assigned verifier set re-execute the canonical integer program. This is simple and has zero honest divergence, but verification costs the same order of work as execution.

Optimistic exact-integer proof

The miner commits a Merkle-rooted execution transcript. Independent watchers re-execute the admitted graph and may expose any committed invalid operation. For a matrix product C = A * B, Freivalds verifies an opened claim using:

A * (B * r) == C * r  over F_p, p = 2^61 - 1

One unpredictable vector has local error at most 1/p; k independent vectors have local error at most 1/p^k. This bound applies only after the invalid operation is selected or challenged. Random graph sampling has a separate coverage probability that MUST be stated in policy.

An optimistic receipt MUST NOT become issuance-final while its challenge window is open. The full transcript, or enough erasure-coded data to reconstruct every challenge opening, MUST remain available throughout that window.

Succinct proof

A governance-approved P3Q backend MAY replace the optimistic dispute path and serve as Z-Chain's succinct settlement verifier only after its exact PoAI AIR, parameter set, recursive batch policy, A-to-Z state binding, verifier, and deployment have passed audit and activation. P3Q is a Plonky3-derived, pairing-free STARK/FRI substrate; a generic library or registered precompile address is not sufficient evidence of a completed PoAI rollup.

Confidential execution

TEE evidence MAY be required for a confidential job. It must bind the actual hardware quote, firmware and runtime measurement, model, input commitment, output commitment, job, miner, freshness value, and destination. Vendor roots, TCB collateral, revocation, and measurement allowlists are explicit trust assumptions.

TEE attestation proves execution provenance, not semantic correctness. High-value confidential jobs MAY combine independent vendors, quorum, and another proof policy.

Subjective quorum

A quorum of cognitive nodes may settle a finite signed judgment or output hash. This proves attributable agreement. By itself it does not prove that the nodes performed costly model execution, so quorum-only work may earn demand fees but MUST NOT authorize subsidy.

Mining lifecycle

Requested
  -> Assigned/Open
  -> Committed
  -> Challengeable or Verifying
  -> Finalized | Rejected | Expired
  -> P3Q-settled on Z-Chain
  -> Receipt exported to the bound destination

1. A requester funds or authorizes an A-Chain job.
2. A miner executes the admitted model on CPU or GPU and posts its commitment.
3. A-Chain derives any challenges only after commitment.
4. A-Chain PoAI consensus resolves the configured proof policy to final or rejected and determines whether the admitted useful-work claim passed.
5. PoAI consensus checks metering, consumes the work nullifier, computes the available reward under the network-wide schedule, and finalizes one receipt atomically in A-Chain state.
6. The canonical asset ledger settles the authorized amount under LP-0130.
7. Z-Chain batches and settles the finalized A-Chain receipt under the activated P3Q policy; before activation, it may only checkpoint an authenticated final root without representing it as a proof of work.
8. A destination adapter verifies the Z-settled A-Chain receipt, Lux finality, receipt inclusion, destination binding, amount, recipient, and local non-consumption before releasing the representation.

Destination verification

A destination verifier MUST check:

1. an authenticated, monotonically advancing, Quasar-finalized Z-Chain settlement commitment to the corresponding A-Chain receipt root, or the explicitly activated native A/Z finality proof during a direct transition;
2. in succinct mode, that the activated P3Q verifier proves the specified A-to-Z receipt transition rather than an unrelated computation; during an explicitly activated direct transition, the authenticated checkpoint MUST bind the exact A-Chain receipt root instead;
3. Merkle inclusion of the complete canonical A-Chain receipt;
4. destination_chain_id == local_chain_id;
5. the bound destination recipient and amount;
6. final proof status and nonzero consumed work nullifier;
7. that this exact A-Chain receipt/nullifier has not been consumed locally.

It MUST NOT:

• accept raw miner work;
• run an alternate PoAI verifier;
• change the destination or recipient;
• recompute subsidy from a local clock;
• create a per-chain AI cap or halving schedule;
• treat an ML-DSA signature alone as proof of AI execution.

Economics

• The hard maximum supply is 2,000,000,000,000 AI network-wide.
• 1,000,000,000,000 AI is a fixed genesis allocation to the Hanzo DAO treasury. It is not mineable and MUST NOT be reclassified into mining rewards.
• 1,000,000,000,000 AI is reserved exclusively for PoAI miner and validator rewards. There is no discretionary mint path outside finalized A-Chain receipts.
• The mining pool follows a geometric halving allowance: at most 500B AI in the first era, 250B in the second, 125B in the third, and so on, converging to 1T.
• The precise halving interval and per-block/epoch distribution function MUST be fixed before activation and computed from finalized A-Chain height, not a local destination clock.
• There is no independent allocation, cap, or halving schedule per chain.
• Demand fees and subsidy are distinct. Demand pays for useful service; subsidy bootstraps the network under a capped schedule.
• Bare votes, signatures, and duplicate recomputation do not create subsidy.
• Destination-chain representations conserve against canonical settlement; they do not expand supply.

Cloud-provider incentive

An existing AI cloud provider may earn both its ordinary customer fee and a PoAI reward by producing proof evidence alongside a workload it is already contracted to execute. Decentralized providers and idle CPU/GPU operators use the same job and proof interface. This makes PoAI an incremental revenue rail for current clouds and a native market for open jobs.

The extra reward is valid only when the original job is independently admitted and the evidence is materially cheaper to validate than to reproduce. A provider MUST NOT receive subsidy for a self-generated circular job, a self-reported GPU-hour, a copied output, or a customer signature without execution evidence. Reward policy MUST cap each era, bind verifiable metering, consume the global nullifier, and define anti-self-dealing admission rules.

Authentication and post-quantum scope

Mining identities and A-Chain/Z-Chain finality certificates SHOULD use activated post-quantum authentication, including ML-DSA where deployed. Lux supplies the PQ-secured base-layer identity and finalized-root context; A-Chain PoAI supplies useful-work execution accountability; Z-Chain P3Q supplies succinct settlement. Selecting ML-DSA does not prove computation and does not make an unfinished threshold protocol production-ready. The complete security claim includes transcript commitments, beacon quality, availability, A-to-Z state binding, Quasar finality, relay verification, and validator key management.

Launch criteria

Activation remains disabled until all of the following are green:

• a production Zen model emits a complete deterministic integer transcript;
• CPU and at least one GPU backend produce byte-identical commitments;
• an adversarial test fabricates a real intermediate operation and is caught;
• transcript availability and challenge response are exercised under node loss;
• optimistic work cannot authorize issuance before proof finality;
• metering cannot be self-reported without a verifiable commitment;
• A-Chain consumes one global work nullifier atomically with finalization;
• a finalized A-Chain receipt is settled through Z-Chain and consumed exactly once on at least two destination environments;
• the canonical supply remains one network-wide schedule under failure and replay;
• any activated P3Q mode proves the exact PoAI A-to-Z transition end to end;
• all activated authentication and succinct-proof paths have deployment evidence.

Relationship to Thinking Chains

Thinking Chains permits heterogeneous private cognition to influence consensus through finite authenticated artifacts. LP-5200 is narrower: it specifies which of those artifacts may authorize mining subsidy. A signed judgment or PoT quorum receipt is accountable cognition; only a proof-bearing receipt finalized by A-Chain PoAI consensus, settled through the activated Z-Chain path, and secured by Lux base-layer finality is an issuance authorization.

Related proposals

• LP-0130 — canonical asset ownership and A-Chain settlement topology
• LP-5000 — A-Chain core
• LP-5300 — cognitive consensus and Proof-of-Thought receipts
• LP-5301 — deterministic receipt verification at the A-to-destination boundary

Copyright

Copyright and related rights waived via CC0.