Foundation

Research program 01

VirtEngine — a cloud marketplace no one can own

VirtEngine connects tenants who need compute with providers who have capacity to lease — on a blockchain that runs the entire deal: encrypted orders, open bidding, escrowed funds, metered usage, dispute-windowed settlement. Identity is verified without a central database, sensitive processing happens in attested hardware enclaves, and the whole protocol is open source and constitutionally locked to public benefit.

License
Apache-2.0
Stack
Go · CometBFT consensus · Cosmos SDK · single `virtengine` binary
Patent
AU2024203136B2 (accepted)
Lineage
partly derived from Akash Network

01The contrast

Cloud today — and the VirtEngine answer

The cloud works. What it lacks is a market anyone can enter, prices anyone can see, and trust anyone can verify. Side by side:

Cloud today

Closed markets, contractual trust

  • Concentration. A handful of hyperscalers operate most of the world's rentable compute. Capacity everywhere else — regional datacenters, universities, specialist operators — has no common market to sell into.

  • Opaque pricing. Negotiated discounts, regional variation, and egress surprises make like-for-like comparison hard. Price discovery happens inside sales calls, not in the open.

  • Trust by contract. You trust a provider because a contract says you can. Billing is the operator's own record of what you used; disputes run through support tickets and legal terms.

  • Anonymous or gatekept. Open platforms know almost nothing about counterparties; enterprise clouds solve that with paperwork and account managers. Neither gives verifiable identity without a central gatekeeper.

The VirtEngine answer

An open market with verifiable trust

  • An open marketplace. Any verified provider can list capacity; any verified tenant can order it. Orders, bids, and leases are on-chain state transitions on a public order book — not a private sales pipeline.

  • On-chain escrow & settlement. Funds are locked in escrow when a lease is matched and released against signed, metered usage records through a dispute-windowed settlement pipeline. The bill is a verifiable data structure.

  • Identity-gated participation. VEID scores every participant through privacy-preserving verification — accountability comes from cryptography and consensus, not from a platform's discretion.

  • Verified, not promised. Enclave attestation for sensitive computation, provider audits and fraud modules on-chain, and a patented verification method (AU2024203136B2) at the core of the design.

02The lifecycle

Walk through one deal, order to settlement

Six steps take a workload from an encrypted order to a settled payment — every one of them an on-chain state transition, not a trusted intermediary. Step through the lifecycle; the map highlights where you are.

fig 01 — the marketplace lifecycle: order → bid → lease → deploy → usage → settlement

Step 1 of 6

Order placed

A tenant publishes a deployment order on-chain: resource specification, pricing bounds, and a deposit. Sensitive order details are stored encrypted so only intended recipients can decrypt them, and participation is gated by VEID trust-score thresholds.

x/deployment · x/market · x/veid

Step 2 of 6

Providers bid

Provider daemons watch the order book and place priced bids. Bidders are VEID-verified operators whose standing is backed by on-chain audit and review records — an anonymous key cannot simply show up and win workloads.

x/market · x/provider · x/audit

Step 3 of 6

Lease matched

The chain matches a winning bid into a lease: the price is locked and an escrow account opens with the tenant's funds held by the protocol — not by the provider, not by the foundation. Either side can walk away only under the rules both agreed to.

x/market · x/escrow

Step 4 of 6

Workload deployed

The winning provider's daemon picks up the lease and instantiates the workload through its orchestration APIs — Kubernetes for cloud-native services, SLURM for HPC jobs — and reports deployment status back to the chain.

provider daemon · Kubernetes · SLURM · x/hpc

Step 5 of 6

Usage reported

The daemon meters actual consumption and submits signed usage records on a fixed schedule — hourly collection by default — into the settlement pipeline, where anomaly detection watches for implausible metering before anything is billed.

provider daemon · settlement pipeline

Step 6 of 6

Settlement

Usage enters a time-windowed dispute workflow (24 hours by default): disputed records cannot settle until resolved or corrected. Clean records are converted to billable line items, escrow pays the agreed amount to the provider with 0% marketplace commission, and unused deposit returns to the tenant. Low validator transaction fees apply separately to on-chain actions.

x/settlement · x/escrow · x/take · x/fraud

03Architecture

Protocol, marketplace, identity — one chain

A single binary runs a CometBFT-powered blockchain node implementing the decentralized exchange. Orders, bids, leases, identity verification, escrow, and settlement are all on-chain state transitions, not trusted intermediaries.

fig 02 — the VirtEngine protocol stack, from marketplace actors to real clusters

Marketplace

Tenants publish orders; providers bid; the chain matches them into leases. Sensitive order and offering data is stored encrypted so only the intended recipient can decrypt it. Escrow and settlement modules meter and pay for actual usage.

Provider daemon

Off-chain, each provider runs a daemon that watches for orders, places bids, instantiates workloads through orchestration APIs — Kubernetes for cloud-native workloads, SLURM for HPC — and records resource usage back on the chain.

Chain & token

A CometBFT/Cosmos-SDK proof-of-stake chain secures the exchange. Validators and staking partners secure consensus; the same staked nodes operate the identity network, giving verification consensus-grade accountability.

04The edge

What no other marketplace combines

Each of these exists somewhere. VirtEngine's claim is the combination — verified identity, attested hardware, protocol-native payment, HPC scheduling, and non-profit stewardship in one open-source chain.

VEID — verified humans, not anonymous keys

Every marketplace participant carries a privacy-preserving identity score computed by the validator set from encrypted evidence — documents, liveness, biometric hardware attestation — with zero-knowledge proofs for selective disclosure. Accountability without a central identity database.

x/veid · x/mfa · x/veid/zk

Trusted processing units

The VEID scoring service runs inside hardware-attested enclaves — AMD SEV-SNP confidential VMs, Intel SGX, AWS Nitro — whose attestations the chain verifies before trusting a result. Sensitive computation happens where no operator can look.

x/enclave · pkg/enclave_runtime

Escrow and dispute-windowed settlement

Payment flows are protocol machinery, not invoices: funds lock at lease time, release against signed usage records, and every record survives a dispute window before it can settle. Corrections and disputes are first-class on-chain workflows.

x/escrow · x/settlement · x/take

HPC as a marketplace lane

Beyond cloud-native workloads, VirtEngine schedules high-performance computing: SLURM cluster integration, dedicated HPC node agents, and a workload publishing pipeline — bringing batch scientific compute into the same order-bid-lease-settle flow.

x/hpc · docs/hpc-provider-operations

Public-benefit stewardship

The protocol, its patent, and its identity system are held by a not-for-profit constitutionally barred from private capture. Licensing must prefer models that support safety, interoperability, and decentralisation.

AU2024203136B2 · constitution cl 32, 37

05Trusted processing

The lock and the key: computation no one can open

The most sensitive computation in the protocol — scoring identity evidence — runs inside hardware trusted-execution environments. Not policy-protected: physics-and-cryptography protected.

fig 03 — attested enclaves: data sealed in, keys sealed in hardware, only results out

The lock

The VEID scoring service deploys in confidential-VM environments — AMD SEV-SNP, Intel SGX, AWS Nitro — where memory is encrypted by the CPU itself. The enclave's contents cannot be inspected by the host operator, the provider running the hardware, or the foundation.

The key

Encryption keys are derived and sealed inside the hardware (vTPM key sealing, hardware-based key derivation). Attestation — real /dev/sev-guest reports, the AMD KDS certificate chain, TCB validation — proves the exact measured code is running before any data is released to it.

What ever leaves

Only verification results — pass/fail and a trust score — are ever shared; raw biometric data never is. The biometric data addendum commits to automatic destruction at retention end and honours consent withdrawal. The chain verifies enclave attestations on-chain through x/enclave.

06VEID

Identity that proves without exposing

VEID is VirtEngine's privacy-preserving decentralized identity layer — the mechanism that lets marketplace parties verify each other without surrendering their documents to a central database.

How verification works

Users capture identity evidence — documents, selfie with active liveness, fingerprint or iris with biometric hardware attestation, device integrity attestation — in the mobile wallet. Payloads are encrypted and uploaded as identity scopes. Block-proposing validators decrypt with their private keys, score the evidence with machine-learning models, and write the resulting identity trust score into the proposed block; consensus validators repeat the computation and vote. The score, never the raw evidence, becomes ledger state.

Privacy machinery

  • Zero-knowledge proofs (x/veid/zk) — prove a requirement is met without revealing the underlying data
  • Selective disclosure by scope — services see only what they ask for and are consented to
  • On-chain multifactor authentication (x/mfa) guarding sensitive transactions and account recovery
  • Public-key encryption for data in transit and at rest — only intended recipients decrypt
  • Device integrity via Play Integrity / App Attest before capture is trusted

VEID is presented in depth on the foundation's Identity program page; its citizen-facing home is identity.org.au — plain-language explanations for individuals and relying services.

07Stewardship

Patented — and locked to the public

Patent AU2024203136B2 covers the decentralized computing system: the identity-scoring blockchain control layer, on-chain MFA, encrypted marketplace, provider daemon, staking-identity network, and encryption subsystem.

Why hold a patent at all?

Defensively. The constitution requires the foundation to seek ownership or control of VirtEngine's patent rights — including continuations, divisionals, and foreign equivalents — precisely so they cannot be captured and turned against the commons cl 32.1. Licensing must prefer models that support safety, interoperability, and decentralisation, and that prevent private capture of core public-benefit protocols cl 37.2.

The code itself is Apache-2.0: free to use, modify, and distribute, with the patent licensed to the extent of the patent holder's contributions to the project.

Mainnet posture

The repository's checked-in mainnet decision is GO, reaffirmed 2026-08-03 and rescheduled to the January 2027 launch window after the original 2026-04-18 / 2026-04-19 UTC window did not proceed. Final canonical allocations and the genesis publication bundle remain checked in as a baseline. Per the project's own guidance, the network should not be described as live before the approved window begins.

Decision
GO — delayed, 2026-08-03
Launch window
2027-01-01 / 2027-01-31 UTC
Source
_docs/operations/mainnet-go-no-go-decision.md

08Who benefits

What each participant gets

The marketplace only works if every side is better off inside it than outside it. Concretely:

For providers

  • Sell spare or dedicated capacity into an open order book instead of building a sales channel
  • Get paid from escrow against signed usage records — no invoicing, no collection risk beyond the dispute window
  • Build portable, on-chain reputation through audits, reviews, and completed leases

For tenants & deployers

  • Compare priced bids from verified operators on like-for-like resource specs
  • Funds stay in protocol escrow until metered usage is settled — contested records are held back automatically
  • Deploy cloud-native or HPC workloads through one marketplace with encrypted order details

For validators & staking partners

  • Secure consensus and earn from the same staked infrastructure that runs the identity network
  • Score encrypted identity scopes inside the consensus process — verification with consensus-grade accountability
  • Participate in governance of a protocol constitutionally locked to public benefit

09Go deeper

The program in the ecosystem