VirtEngine

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.

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

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

Every marketplace interaction follows the same five-stage state machine.

fig 02 — order → bid → lease → usage → settlement
01 Order
A tenant posts a deployment order on-chain describing the resources they need — compute, memory, storage, region, and attributes.
02 Bid
Provider daemons watching the chain place competing bids against open orders on behalf of their configured providers.
03 Lease
The tenant's winning bid becomes a lease. Escrow is funded, and the provider daemon instantiates the workload through its orchestration layer.
04 Usage
The provider daemon meters running workloads and submits signed usage records to the chain on a scheduled cadence.
05 Settlement
After a 24-hour dispute window, the settlement module converts usage into billable line items and releases the agreed escrowed funds to the provider with no marketplace commission deducted.

Economics

Tokenomics designed for a self-balancing network

The economic model is validated by an in-repo simulation and audit framework (pkg/economics) covering inflation dynamics, staking rewards, fee markets, distribution fairness, and attack costs.

1B → 10B

Initial supply, hard maximum supply

docs/tokenomics-analysis.md

14 : 1

Eligible humans to Foundation genesis allocation per 15 issued

Proposed policy

Identity-led

Proposed issuance model

Proposed policy

0%

Marketplace commission; validator transaction fees are separate

Proposed policy

Inflation adjusts dynamically: when the staking ratio falls below target, inflation — and therefore staking APR — rises to attract bonding; above target it falls. The 21-day unbonding period, burn-and-mint mechanics (x/bme), and a conservative staking rewards round out the incentive design. Details on the staking page and in the protocol documentation.

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.