aere-docs/AERE-COMPUTE-MARKET-V3.md

Aere Compute Market V3

Proof-carrying decentralized compute (DePIN) settlement for Aere Network.

What it is

AereComputeMarketV3 is the on-chain verification and settlement rail for a decentralized compute marketplace. A REQUESTER posts a job (a commitment to the workload spec, a reward held in escrow, a deadline, and a required verification mode). A PROVIDER claims the job, runs the work off-chain, and submits a result. The provider is paid only against verifiable evidence, never on trust alone. Which evidence counts, and when payment releases, is decided by the job's VERIFICATION MODE.

V3 unifies the verification rails that were split across the earlier coordination layer (AereComputeMarketV2, which offered a single optimistic path with Foundation arbitration) and adds a post-quantum settlement gate. The deployed V1 and V2 DePIN contracts are untouched; V3 is a new, independent contract.

Source: aerenew/contracts/contracts/depin/AereComputeMarketV3.sol Test: aerenew/contracts/test/AereComputeMarketV3.test.js (13 passing)

The three verification modes

A requester picks one mode per job. Each mode answers one question: what makes a submitted result payable?

REPLAY (mode 0)

The result is a deterministic function of the input. On submission the provider posts the full result bytes, which the contract emits (and anchors as keccak256(result)), so any watcher can re-run the spec locally and compare keccak256(localResult) against the on-chain resultHash. The result is accepted after a challenge window unless a challenger posts a matching bond and disputes. On a dispute the challenger records the resultHash they recomputed, so the arbiter (and any observer) can mechanically verify who is correct. The arbiter then resolves.

When to use it. Workloads that are pure, deterministic, and cheap to re-execute (batch transforms, deterministic simulations, reproducible builds). Disputes are objectively decidable by re-running, so the arbiter's role is mechanical rather than judgemental.

ZK_VERIFIED (mode 1)

The result carries a zero-knowledge proof, verified ON-CHAIN through the existing deployed SP1 gateway verifier. The provider submits the SP1 public values (ABI-encoded as (bytes32 specHash, bytes32 resultHash)) and the proof. The contract binds the proof to the job by requiring the proven specHash to equal the job's committed spec, records the proven resultHash, then calls the gateway's verifyProof. The reward releases in the SAME transaction, and ONLY if the proof verifies. There is no other code path that pays a ZK_VERIFIED job, so paying one without a valid proof is impossible.

When to use it. Workloads where correctness must be enforced without trusting a challenge window or an arbiter: verifiable inference, zk coprocessing, anything where the requester wants finality on delivery rather than after a delay. The cost is that the provider must run a real prover.

The verifier reference. V3 calls the ISP1Verifier interface (aerenew/contracts/contracts/zkverify/ISP1Verifier.sol), the same interface implemented by the deployed SP1VerifierGateway at 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628 on Aere Network chain 2800. V3 does not reimplement proof verification; it references and calls the existing gateway. The gateway routes on the proof's first four bytes to the correct SP1 verifier and reverts on an invalid proof, which is exactly the fail-closed behavior V3 relies on.

OPTIMISTIC (mode 2)

The result is accepted after a challenge window unless a challenger posts a bond and disputes. A successful dispute slashes the PROVIDER bond to the CHALLENGER and refunds the reward to the requester. Unlike REPLAY, the result is not assumed cheaply re-derivable, so the provider stakes a bond as skin in the game and the challenge is a general fraud claim rather than a mechanical recomputation.

When to use it. Workloads that are checkable but not cheaply reproducible (large or non-deterministic pipelines, results that are expensive to recompute but easy to spot-check). The bond sizes the cost of lying.

Post-quantum settlement path

Any job (in any mode) can set pqcSettlement = true and register an 897-byte Falcon-512 settlement key. When set, the final release of funds to the provider additionally requires a Falcon-512 signature by that key over a domain-separated settlement digest binding (chainId, contract, jobId, provider, token, amount, resultHash). The signature is verified IN FULL on-chain by the live native precompile at 0x0AE1 (activated on Aere mainnet 2800 at block 9,189,161), using the same input encoding proven against the live precompile in AerePQCMessageVerifier.

The point: the payout authorization is post-quantum. A quantum adversary who forged the classical secp256k1 transaction sender still cannot authorize a payout without the Falcon private key. The digest binds the exact payout figure and result, so an authorization can never be replayed to another job, chain, contract, or amount. A tampered or missing signature reverts the release and nothing is paid (fail-closed).

Scope boundary. This gate authorizes PAYOUTS. It does NOT make Aere consensus post-quantum. Blocks remain Besu QBFT with classical secp256k1 validators. What is post-quantum here is the authenticity of the settlement authorization, not block production.

Disputed jobs are settled by the arbiter's ruling rather than the happy-path release, so the Falcon gate applies to the normal accept/finalize/ZK settle paths; arbiter resolution of a disputed job is the arbiter's authority.

Escrow-solvency guarantee

The contract tracks totalLiabilities[token] for every asset: the sum of open job rewards plus posted bonds in that asset. Every escrow or bond increments it; every payout, refund, or slash decrements it by the same amount, with effects applied before transfers. The invariant

balanceOf(contract, token) >= totalLiabilities[token]      for every asset

therefore holds at all times, where token == address(0) is native AERE. The public view isSolvent checks it. Rewards settle in native AERE or an allowlisted ERC-20; provider and challenger bonds are always native AERE, so solvency is tracked per asset. Fee-on-transfer or rebasing reward tokens are rejected at escrow time (the contract requires the received amount to equal the stated reward).

The test asserts isSolvent (and the raw balance-versus-liability comparison) after every mutating step of every scenario, including a mixed batch of jobs across all three modes carried to their terminal states.

Fail-closed properties

• No double-pay. Every job reaches a terminal status (Paid, Refunded, Slashed) exactly once. All fund-moving entrypoints are reentrancy-guarded and set the terminal status before any transfer.
• No pay-without-proof in ZK_VERIFIED. Settlement happens inside submitResultZK, after the gateway verifyProof call. An invalid proof reverts the whole transaction.
• No admin drain. There is no owner and no sweep. The arbiter can only route a DISPUTED job's escrow between its requester, provider, and challenger. Governance can only flip a token allowlist boolean. Neither can withdraw escrowed funds.
• Deadlines. A claimed job that misses its deadline without a submission lets the requester reclaim the reward and slashes the provider bond to the requester.

Job lifecycle (summary)

postJob        Open        requester escrows reward (+ mode/pqc params)
claimJob       Claimed     provider posts the required native-AERE bond (0 for ZK)
submitResult   Submitted   REPLAY / OPTIMISTIC: result bytes emitted, window starts
submitResultZK Paid        ZK_VERIFIED: proof verified on-chain, paid in the same tx
acceptResult   Paid        requester accepts a Submitted result early
finalize       Paid        anyone, after the window closes with no dispute
dispute        Disputed    challenger posts a matching bond within the window
resolveDispute Paid/Slashed arbiter rules; a bad result slashes the provider bond to the challenger
cancelJob      Refunded    requester reclaims an unclaimed job's escrow
reclaimExpired Refunded    requester reclaims a claimed job that blew its deadline (bond slashed)

Honest status

• Contract: built and tested. AereComputeMarketV3.sol compiles under solc 0.8.23 (the repo standard) and the 13-case Hardhat suite passes, covering all three modes, the Falcon settlement gate, the ERC-20 reward path, the solvency invariant, and no-double-pay.
• ZK verification path [VERIFY]: exercised against MockSp1Verifier, which mirrors the deployed gateway semantics (reverts on an invalid proof). The reference verifier is the deployed SP1VerifierGateway at 0x9ca479C8c52C0EbB4599319a36a5a017BCC70628; wiring V3 to it on mainnet is a deploy-time constructor argument.
• Falcon settlement path [VERIFY]: exercised against MockPQCPrecompile at 0x0AE1, which parses the Falcon-512 spec offsets. The real wire encoding is separately KAT-proven in AerePQCMessageVerifier and against the live mainnet precompile. On mainnet 2800 the precompile at 0x0AE1 is live.
• Real compute supply [MEASURE]: real GPU / accelerator supply, the off-chain provers, and the real SP1 proving are EXTERNAL to this contract. They require actual hardware providers running the reference provider daemon. This is adoption, not code, exactly like validator decentralization. V3 is the trust and settlement rail; it does not by itself constitute a live compute market with real providers.
• No new token. Rewards, escrow, bonds, and payment are native AERE or an allowlisted existing ERC-20.
• Not deployed. This contract is built for publication and review. Deployment is founder-gated.