Protocol

One chain that runs a cloud marketplace end to end

VirtEngine is a purpose-built blockchain: consensus, identity verification, resource exchange, and payment settlement in a single Go binary. Here is how it fits together.

A data-centre aisle: racks of servers receding into the distance.
One binary: consensus, market, identity, settlement.

Architecture

From client to cluster

Four layers: clients sign transactions; the chain orders and executes them by consensus; provider daemons translate leases into running workloads; infrastructure delivers the compute.

fig 01 — VirtEngine Suite: single `virtengine` binary, CometBFT consensus, Cosmos SDK application
Input
A signed instruction from a user, tenant or service.
Output
A transaction submitted to the network.
Guarantee
Only the holder of the keys can authorise the action — intent cannot be forged.
Input
Orders, bids, identity scopes and funded escrow.
Output
Matches, leases and settlement state.
Guarantee
Matching and escrow follow protocol rules; VEID is an optional, scoped trust signal, not a universal marketplace gate.
Input
Transactions from every client and provider daemon.
Output
Ordered, replicated chain state.
Guarantee
Every validator executes the same modules under the same rules; the state is verifiable.
Input
Lease events and lifecycle actions.
Output
Running resources and signed usage records.
Guarantee
The chain does not provision; the provider's control plane does, and reports back under signature.

signed usage returns through the stack ↑

Module map

Twenty-seven modules, four domains

Everything the marketplace needs lives in x/ modules on the chain — every module has a dedicated reference page.

Lifecycle

Order to settlement, on chain

The five-stage marketplace lifecycle in brief. The canonical guide owns the full stage-by-stage explanation.

Economics

Tokenomics — detail lives in the guide

Supply, issuance and rewards are owned by the tokenomics guide. This page keeps architecture only.

Initial supply zero, identity-led issuance, governed parameters. Tokenomics explained → Staking roles: Staking overview →

Governance & security

Run by stakeholders, engineered defensively

On-chain governance

Bonded stake governs the network: validators and delegators vote on parameter changes, upgrades, and chain configuration — including the list of approved client interfaces permitted to submit identity data. Economic parameters are chain state, adjustable by proposal rather than by decree.

Security posture

Sensitive on-chain data is public-key encrypted end to end — only intended recipients can decrypt. Validators verify client and user signatures before scoring identity data. Slashing punishes consensus misbehavior, the fraud and audit modules police marketplace conduct, and the economic model is stress-tested against 51%, spam, long-range, and cartel attack scenarios.