Solutions · Web3 developers
Build on VirtEngine: Cosmos SDK for Developers
VirtEngine is a Cosmos SDK chain whose state machine runs a real economy: orders, leases, usage, settlement, identity. For developers, that means a rich, typed module surface to build against — and a marketplace whose transactions do something physical.
Who this is for: Developers building wallets, tooling, marketplaces, and applications on the protocol.
At a glance
The short version for web3 developers
-
Surface
Twenty-seven typed modules
Query orders and bids, inspect provider records, track settlement and escrow, resolve VEID registry state — all over standard Cosmos SDK gRPC and REST.
-
Client
One binary, node and client
Create deployments, manage mTLS certificates, fund escrow, and query lease state from the CLI or programmatically.
-
Identity
A governed path for identity apps
Identity-data submission runs through the x/config approved-client list — study the VEID capture reference app to walk it.
The problem
The context: most chains have nothing to integrate with
Generic L1s offer developers token transfers and smart-contract sandboxes. Application-specific chains offer something better: domain state machines with real workflows — but only if the module surface is coherent and documented.
In one view
Audience-specific visual
Each solution gets its own explanatory figure — not the same template art.
gRPC / REST
│
┌──┼───────────┐
x/market
x/provider
x/escrow
x/veid
x/settlement One code example in docs: query orders, submit bids, track leases. Docs ↗
The mechanism
How the protocol carries it
How VirtEngine addresses it
Grounded in what the protocol actually does
A typed module surface
Twenty-seven modules expose the marketplace as protocol state: query orders and bids (x/market), inspect provider records and attributes (x/provider), track settlement and escrow flows, resolve identity state through the VEID registry. Standard Cosmos SDK gRPC and REST endpoints serve all of it.
Deployment tooling
The virtengine binary is both node and client: create deployments, manage certificates for mTLS with providers, fund escrow, and query lease state from the CLI or programmatically. Workloads are described declaratively and fan out to orders via deployment groups.
The approved-client path
Identity-submitting clients are governed: the x/config approved-client list controls which interfaces may submit VEID identity data, and validators verify client and user signatures before scoring. If you are building identity-capable clients, that governance process is your integration path — study the VEID capture reference app in mobile/veid-capture-app/.
How it works
The path through the protocol, step by step
Select each step — the panel walks the sequence in order, from first action to settled outcome.
Step 1 · Clone
Clone the repo
github.com/virtengine/virtengine — Go 1.25.5, `make virtengine` builds the binary. Apache 2.0 throughout.
Step 2 · Read
Read the module docs
The module reference on this site plus protocol docs at docs.virtengine.com cover every message and query surface.
Step 3 · Run
Run a local environment
The development-environment guide walks through local chain setup so you can exercise the full lifecycle offline.
Step 4 · Build
Build against gRPC/REST
Standard Cosmos SDK client patterns apply across all modules — wallets, dashboards, marketplaces, analytics.
Step 5 · Ship
Ship without permission
Deployment tooling, provider dashboards, staking interfaces, and analytics require no approval. Only identity-data submission needs approved-client governance.
Economics
Economics for builders
Marketplace transactions carry standard chain fees, and services priced in tokens settle through escrow with the governed take. Building deployment tooling, provider dashboards, staking interfaces, or analytics requires no permission — the chain surface is open. Identity-data submission alone requires approved-client governance.
Getting started
The path in
-
Clone the repo
github.com/virtengine/virtengine — Go 1.25.5, make virtengine builds the binary.
-
Read the module docs
Module reference on this site plus protocol docs at docs.virtengine.com.
-
Run a local environment
_docs/development-environment.md walks through local chain setup.
-
Build against gRPC/REST
Standard Cosmos SDK client patterns apply across all modules.
Questions
Asked about web3 developers
What stack is VirtEngine built on?
A CometBFT/Cosmos SDK chain written in Go, partly derived from the Akash Network codebase. If you have built on any Cosmos SDK chain, the client patterns — gRPC, REST, CLI — transfer directly.
Do I need permission to build?
No — except for one path. Deployment tooling, dashboards, staking interfaces, and analytics need no approval. Submitting VEID identity data requires going through approved-client governance in x/config, since validators only score submissions from approved clients.
Where is the module surface documented?
Start with the module reference on this site for what each module does and how they connect, then docs.virtengine.com for message-level and API documentation.
Related
Continue from here
More solutions