A-Chain - Core AI/Attestation Specification

Implementation status (code-audited 2026-08-18): PARTIAL. luxfi/chains/aivm contains the A-Chain VM, quorum settlement, receipt root, export proof, provider bonding, and deterministic state transitions. hanzo-engine and luxfi/crypto/poi contain exact-integer PoAI components. The production inference RPC, execution transcript, proof-finality gate, global work nullifier, and destination settlement path are not yet wired end to end.

Normative topology + fee model: LP-0130. A-Chain rides B-Chain's settlement engine (LP-0130 §9). Inference receipts + attestation state MUST NOT hold canonical UTXO asset supply; worker rewards settle to X via the epoch fee root reconciled at Q finality.

Abstract

LP-5000 specifies the A-Chain (AI Virtual Machine), Lux Network's canonical Proof-of-AI consensus for useful AI jobs, execution evidence, device attestations, model and runtime policy, work nullifiers, and inference receipts. A-Chain is the single source of truth for PoAI mining finality: it validates that a pre-admitted, demand-backed computation was actually performed. Z-Chain is the Plonky3-derived P3Q proof-compression and settlement rollup for finalized A-Chain receipt transitions; it is not a second mining authority. Lux Quasar orders and finalizes both states on the post-quantum base layer. Trusted execution environments are optional; public deterministic integer work does not require a TEE or GPU.

Motivation

A unified attestation layer provides:

1. PoAI useful-work consensus: one chain admits useful jobs, validates that their bound computation was done, and finalizes AI mining receipts
2. Hardware independence: deterministic integer execution on CPU or GPU
3. Evidence agility: exact replay, optimistic proofs, succinct proofs, and confidential-compute attestations under explicit policy
4. Interoperability: any destination can verify finalized A-Chain receipts
5. Economics: one global work-nullifier set and one issuance authorization
6. Succinct settlement: Z-Chain batches finalized receipt transitions under the activated P3Q proof policy without admitting raw mining work

Mining authority (normative)

Only PoAI consensus on A-Chain may decide that Proof-of-AI work is useful under policy, was actually performed, and is final. A job may bind a payout destination on Hanzo, Zoo, Lux C-Chain, X-Chain settlement, or another supported network, but neither Z-Chain nor the destination is a proof authority for the underlying work. Z-Chain settles the finalized A-Chain transition; the destination verifies the Z-settled, PQ-finalized receipt and consumes it exactly once.

A destination MUST NOT accept a raw miner signature, TEE quote, output quorum, Freivalds opening, or destination-local spent key as proof of mining. See LP-5200 for the mining protocol and LP-5301 for receipt verification.

Specification

Chain Parameters

Parameter	Value
Chain ID	A
VM ID	aivm
VM Name	aivm
Block Time	2 seconds
Consensus	A-Chain PoAI useful-work state machine; Z-Chain P3Q settlement rollup; both ordered and finalized by Lux Quasar

Implementation

Canonical Go package: github.com/luxfi/chains/aivm

The buildable VM plugin entry point lives at aivm/cmd/plugin. Older references to github.com/luxfi/node/vms/aivm are historical and non-normative.

Directory Structure

chains/aivm/
├── cmd/plugin/               # VM plugin entry point
├── quorum_engine.go          # deterministic commit/reveal settlement
├── quorum_state.go           # consensus state
├── import_c_intent.go        # verified intent admission
├── settlement.go             # atomic settlement and slashing plan
├── receipts.go               # canonical receipt + receipt root
├── export.go                 # receipt inclusion proof export
└── *_test.go                 # component and cross-module tests

Core Components

1. Attestation Registry

type DeviceStatus struct {
    DeviceID    ids.ID
    Attested    bool
    TrustScore  uint8     // 0-100
    LastSeen    time.Time
    Operator    Address
    Vendor      TEEVendor
    ComputeType ComputeClass // CPU, GPU, NPU, ASIC
}

type AttestationRegistry struct {
    Devices     map[ids.ID]*DeviceStatus
    RootCAs     map[TEEVendor][]byte
    MerkleRoot  [32]byte
}

2. Execution evidence

type ExecutionEvidence struct {
    JobID               [32]byte
    MinerID             [32]byte
    ModelSpecHash       [32]byte
    InputCommitment     [32]byte
    OutputCommitment    [32]byte
    ExecutionSpecHash   [32]byte
    TranscriptRoot      [32]byte
    MeteringRoot        [32]byte
    ProofPolicy         uint8
    Evidence            []byte
}

Evidence is interpreted only by the proof backend fixed in the A-Chain job. The public deterministic path uses exact integer execution and does not require a device certificate. Confidential jobs may require vendor attestation as an additional policy.

3. A-Chain work nullifier and destination binding

The double-mint invariant is enforced once, in A-Chain consensus:

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

A-Chain consumes this nullifier atomically with final receipt creation. The job already binds destination_chain_id and destination_recipient; those fields route the payout but do not scope proof validity.

func (vm *VM) FinalizeWork(job Job, result Result) (Receipt, error) {
    if err := vm.verifyJobBinding(job, result); err != nil {
        return Receipt{}, err
    }
    if err := vm.requireFinalExecutionEvidence(job.ProofPolicy, result); err != nil {
        return Receipt{}, err
    }
    nullifier := WorkNullifier(job, result.ExecutionCommitment)
    if vm.workNullifiers.Contains(nullifier) {
        return Receipt{}, ErrWorkAlreadyFinalized
    }

    // One A-Chain state transition: consume work, calculate the network-wide
    // allowance, and create the destination-bound receipt.
    vm.workNullifiers.Add(nullifier)
    return vm.finalizeReceipt(job, result, nullifier)
}

The canonical settlement flow is:

1. A-Chain PoAI consensus admits a demand-backed job and binds its consumer, deliverable, execution policy, and payout destination before mining.
2. A miner executes it on CPU or GPU.
3. PoAI consensus resolves the configured proof policy and determines that the bound computation was actually performed or rejects it.
4. A-Chain consumes the global work nullifier and emits one receipt under its receipt root.
5. Z-Chain batches the finalized A-Chain receipt transition and verifies its activated Plonky3-derived P3Q settlement proof. Before that proof path is enabled, Z-Chain may checkpoint only an independently authenticated final A-Chain root and MUST NOT claim succinct proof authority.
6. Quasar finalizes the corresponding A-Chain and Z-Chain roots; the activated PQ validator policy authenticates them; X/canonical settlement applies the authorized reward under LP-0130.
7. Warp/Teleport, a native boundary, or an authenticated relay carries the Z-settled receipt and inclusion proof to the named destination.
8. The destination verifies and consumes the receipt locally exactly once.

The same physical device may execute many A-Chain jobs concurrently. Each is a different A-Chain job and challenge; there is no independent "Hanzo proof, Zoo proof, Lux proof" for the same work.

4. Confidential-compute profiles

Vendor attestation is optional evidence for jobs requiring prompt, weight, or output confidentiality. A production profile MUST define quote format, complete certificate chain, TCB collateral, freshness, revocation, measurement allowlist, and exact binding to the A-Chain job/model/input/output/runtime.

No static model-to-"trust score" table is normative. Hardware availability and vendor claims change over time; governance activates a measured profile, not a marketing GPU name. A software-only device remains eligible for deterministic integer jobs when the selected proof policy does not require a TEE.

Evidence profiles

Profile	Typical environment	What it establishes
Deterministic integer	CPU, GPU, NPU	Canonical execution under the admitted integer spec
Optimistic transcript	CPU or accelerator + watchers	Challengeable committed execution
Succinct proof	Any prover	Validity under an activated circuit and verifier
Confidential compute	SGX, TDX, SEV-SNP, NVIDIA CC, ARM CCA	Provenance under an approved measured environment
Quorum judgment	Heterogeneous cognitive nodes	Attributable agreement over a finite result

Quorum judgment without separate execution evidence is not subsidy-bearing.

Consensus transaction families

Type	Description
RegisterProvider	Bond and register an execution provider
RegisterEvidenceProfile	Activate a measured runtime/proof policy
ImportIntent	Admit a finalized source-chain intent
CreateMiningJob	Create an A-Chain-native proof-bearing job
CommitResult	Commit output, transcript, and metering roots
RevealResult	Reveal the quorum/result payload when required
ChallengeResult	Submit objective fraud evidence
FinalizeResult	Resolve proof policy, consume nullifier, emit receipt
ExportReceipt	Pure read producing receipt and inclusion proof

Public RPC methods are submission and query interfaces for these consensus transactions. A legacy in-memory HTTP task handler MUST NOT be treated as the canonical mining state machine.

Precompile and address status

Historical addresses 0xAAA0--0xAAA2 and their fixed gas figures were never built and are non-normative. Activated precompile addresses come from the unified Lux registry and require deployed code plus gas benchmarks. Merkle proof generation is an off-chain read; consensus paths verify proofs.

Configuration requirements

An A-Chain deployment configuration MUST bind, at minimum:

{
  "aivm": {
    "miningEnabled": false,
    "policyEpoch": 0,
    "acceptedExecutionSpecs": [],
    "acceptedProofPolicies": [],
    "challengeWindowBlocks": 0,
    "availabilityPolicy": "disabled-until-configured",
    "maxJobsPerBlock": 0,
    "receiptExportEnabled": false
  }
}

Defaults fail closed. Vendor names and subjective trust scores are not sufficient configuration; a confidential-compute profile pins roots, collateral policy, measurements, freshness, and revocation behavior.

Performance claims

No fixed latency in this LP is normative. Launch evidence MUST report the exact hardware, model, dimensions, proof policy, payload size, gas or native execution cost, concurrency, and percentile distribution. Small fixture benchmarks MUST NOT be presented as production-model throughput.

Rationale

1. One PoAI consensus proves that admitted useful work was actually done and prevents it from creating supply on many chains.
2. Integer execution makes CPU validation possible and removes floating-point consensus tolerance.
3. Evidence agility permits confidential and succinct paths without making a vendor the definition of PoAI.
4. P3Q settlement and PQ-rooted export give omnichain payout without omnichain mining authority: Z-Chain compresses A-Chain receipt transitions, while Lux finality is the common root every destination verifies.
5. LP-0130 settlement keeps domain receipts separate from canonical asset ownership.

Backwards compatibility

LP-5000 supersedes LP-0080. The old destination-bound SpentKey and VerifyAndMint model is explicitly superseded by the A-Chain work-nullifier and finalized-receipt model. Existing destination deployments MUST disable raw work acceptance before PoAI activation.

Required tests

The reference implementation MUST cover:

• deterministic job and nullifier derivation;
• CPU/GPU commitment parity for the same execution spec;
• commit-before-beacon enforcement;
• objective fraud detection and honest-opening safety;
• transcript withholding during the challenge window;
• no issuance authorization while an optimistic proof is pending;
• atomic settlement with no partial slashing or nullifier consumption;
• receipt-root reconstruction and inclusion export;
• destination binding and exactly-once consumption;
• cross-destination replay rejection;
• one network-wide issuance allowance.

Reference implementation

• A-Chain VM and quorum settlement: github.com/luxfi/chains/aivm
• Exact-integer prover components: github.com/hanzoai/engine, hanzo-engine/src/poi*.rs
• Canonical Go verifier: github.com/luxfi/crypto/poi
• Receipt bridge verifier: github.com/luxfi/precompile/aivmbridge
• P3Q settlement substrate: github.com/luxfi/p3q
• Reference AI contracts: github.com/luxfi/standard/contracts/ai

Security considerations

1. Authority split: A-Chain PoAI consensus validates that admitted useful work was done; Z-Chain P3Q compresses and settles finalized receipt transitions; Lux Quasar finalizes the states; canonical settlement owns supply; destinations only consume authorizations.
2. Availability: optimistic fraud proofs are ineffective without transcript availability and a finality delay.
3. Coverage: Freivalds' local error does not include graph sampling misses.
4. Metering: time, FLOPs, and tokens cannot be accepted as self-reported reward inputs.
5. Attestation: quotes must bind the actual job/model/input/output/runtime and validate collateral, measurement, freshness, and revocation.
6. Proof maturity: registered P3Q or threshold-signature code is not a production claim without the activated PoAI AIR, A-to-Z state binding, recursive policy, verifier, protocol, and node wiring.
7. Semantic limits: pre-admission and demand establish protocol usefulness; execution evidence establishes that the job was done. Neither proves universal answer truth, ownership, safety, or broader social value.

Related LPs

LP	Title	Relationship
LP-0080	A-Chain Specification	Superseded by this LP
LP-0130	Chain topology and settlement	Canonical ownership and reward settlement
LP-5200	A-Chain Proof-of-AI Mining	Normative mining protocol
LP-5300	Thinking Chains / Proof-of-Thought	Cognitive settlement
LP-5301	AIVM bridge	Destination receipt verification

Copyright

Copyright and related rights waived via CC0.