Akash Network RPC: Querying a Decentralized Compute Marketplace

Akash Network is one of the more interesting chains to connect an RPC endpoint to, because the chain itself isn't the product — the chain is the settlement layer for a decentralized compute marketplace. Developers who first query Akash often expect a familiar Cosmos pattern and miss the parts that make it different. The compute marketplace (deployments, bids, leases) lives in Akash-specific modules, not in the standard bank/staking queries. And the workloads themselves — containers running on provider GPUs — don't live on-chain at all. Here's the map.

What Akash actually does

Akash is a decentralized cloud compute marketplace built on the Cosmos SDK with CometBFT consensus. The pitch: instead of renting GPUs from AWS at $3.93/hr for an H100, you describe your workload, providers bid against each other in a reverse auction, and you pay market price (currently around $1.33/hr for the same H100). The chain records the leases and handles settlement; the actual compute runs in provider-operated Kubernetes clusters off-chain.

The numbers as of September 2026: ~59 active providers, ~15,000 vCPUs, ~433 GPUs (H100, A100, H200, RTX 5090), ~89 TB memory, ~785 TB storage. The AI inference wave has been the main demand driver — Akash ships pre-configured templates for Llama 3, DeepSeek, and Stable Diffusion, plus Ray cluster support for multi-node training.

The deployment flow has three steps:

1. Deploy: you describe your workload in an SDL (Stack Definition Language) file — CPU, memory, GPU, storage, exposed ports, max price. This creates a deployment on-chain.
2. Bid: independent providers submit competing bids. This is the reverse auction — providers undercut each other, and the market sets the price.
3. Lease: you accept a bid. A lease is recorded on-chain, and the provider initializes your container in their Kubernetes cluster.

The chain handles the marketplace, the lease accounting, and the payment settlement. The compute itself is off-chain — you won't find container logs or execution results by querying the chain.

The RPC: CometBFT JSON-RPC, same as other Cosmos chains

Akash runs on akashnet-2, uses CometBFT v0.38.x, has ~6-second blocks, and the AKT token has 6 decimals. The RPC is the standard CometBFT JSON-RPC — the same surface you'd use for Osmosis, Injective, or Celestia. No eth_*, no EVM. The chain ID is the string akashnet-2, not a numeric EVM ID.

SwiftNodes serves the CometBFT JSON-RPC endpoint:

# Node status
curl -s -X POST https://rpc.swiftnodes.io/rpc/akash?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"status","params":[],"id":1}'
# -> {"result":{"node_info":{"network":"akashnet-2",...},"sync_info":{"latest_block_height":"28455984",...}}}

The core methods you'll use:

These are the consensus-layer queries — reading blocks, monitoring chain activity, broadcasting transactions. They work the same way across every Cosmos chain.

Where the special part lives: Akash modules

Here's where Akash diverges from a plain Cosmos chain. The marketplace state — deployments, bids, leases, providers — lives in Akash-specific protobuf modules. You query these through abci_query with the module's gRPC query path:

The abci_query method takes four parameters: the query path, hex-encoded protobuf request data, a block height (0 = latest), and a prove flag. The protobuf encoding is the tricky part — you typically generate the request bytes from a Cosmos SDK client library rather than hand-crafting them. If you're using akash-cli or a Cosmos SDK integration, the module queries are wrapped for you.

The practical split:

• Consensus RPC (CometBFT) — reading blocks, monitoring the chain, broadcasting standard transactions. This is what a flat-rate RPC endpoint gives you.
• Module queries (abci_query) — reading marketplace state (deployments, bids, leases, providers). Requires protobuf-encoded request data.
• Workload management — actually deploying containers, accepting bids, managing leases. This happens through the Akash Console or CLI, which wraps the module transactions.

If you're building a dashboard that tracks active deployments, monitors provider capacity, or indexes lease pricing data, you need the CometBFT RPC for chain state plus abci_query for the marketplace modules. If you're deploying workloads, you'll use the Akash CLI or Console on top.

Finality and block structure

Akash has single-block deterministic finality via CometBFT BFT consensus — once a block is committed by the validator set, it's final. No reorgs, no probabilistic confirmation waits. Recent blocks carry ~84 validator signatures in the commit, and blocks contain a handful of transactions (9 txs in a typical recent block at height 28,455,980).

For an indexer, this means you can trust a committed block immediately. Read blocks via block, transaction results via block_results, and the validator commit via commit. The same reorg-handling patterns you'd build for probabilistic chains like Ethereum don't apply here — once it's committed, it's done.

How this compares to other Cosmos chains

Akash shares the CometBFT RPC surface with every other Cosmos chain, but the application layer is where it diverges. Injective puts an orderbook in a module. Osmosis puts a DEX in modules. Akash puts a compute marketplace in modules. The pattern is the same — Cosmos SDK modules extend the base chain with application-specific state — but the domain is different each time.

The difference from Celestia is architectural: Celestia is a data availability layer (its special part is blob posting, which happens through a separate node API, not the core RPC). Akash's marketplace state is fully queryable through the standard CometBFT RPC via abci_query — there's no separate "Akash node API" you need to run.

The short version

Akash is a decentralized compute marketplace built on the Cosmos SDK. Its RPC is CometBFT JSON-RPC — the same surface as every other Cosmos chain. Use status, block, block_results, and commit to read chain state. Use abci_query with Akash-specific module paths (akash.deployment, akash.market, akash.provider) to read marketplace state: deployments, bids, leases, and provider registrations. The workloads themselves run off-chain in Kubernetes. It has single-block BFT finality, ~6-second blocks, and the AKT token (6 decimals).

For monitoring Akash chain activity, tracking marketplace state, or broadcasting transactions, you need a reliable CometBFT endpoint. A flat-rate Akash RPC endpoint gives you that across load-balanced nodes, alongside 74 other chains under one key. Grab a free key and point your app at:

https://rpc.swiftnodes.io/rpc/akash?key=YOUR_API_KEY