# Market vs Deployment Modules in Akash Node: Architectural Differences Explained

> Explore the architectural differences between Akash Node's market and deployment modules. Understand how market orchestrates keepers while deployment manages isolated state.

- Repository: [Akash Network/node](https://github.com/akash-network/node)
- Tags: architecture
- Published: 2026-02-24

---

**The market module functions as a central orchestrator that aggregates all core keepers into a unified `handler.Keepers` struct, while the deployment module maintains isolated state management with explicit, minimal dependencies on only the market and escrow keepers.**

The Akash Network node separates marketplace operations from workload lifecycle management through two distinct Cosmos-SDK modules. Understanding the architectural difference between the market and deployment modules in Akash Node reveals how each handles dependencies, state persistence, and cross-module communication.

## Module Wiring and Keeper Architecture

The fundamental architectural divergence appears in how each module initializes and exposes its keeper dependencies.

### Market Module: Unified Keeper Aggregation

In [`x/market/module.go`](https://github.com/akash-network/node/blob/main/x/market/module.go), the market module bundles **all** required keepers into a single composite struct. The `NewAppModule` constructor (lines 109-134) accepts eight separate keeper instances and collapses them into a `handler.Keepers` struct:

```go
func NewAppModule(
    cdc codec.Codec,
    keeper keeper.IKeeper,
    ekeeper ekeeper.Keeper,
    akeeper akeeper.Keeper,
    dkeeper handler.DeploymentKeeper,
    pkeeper handler.ProviderKeeper,
    acckeeper govtypes.AccountKeeper,
    authzkeeper authzkeeper.Keeper,
    bkeeper bankkeeper.Keeper,
) AppModule {
    return AppModule{
        AppModuleBasic: AppModuleBasic{cdc: cdc},
        keepers: handler.Keepers{
            Account:    acckeeper,
            Escrow:     ekeeper,
            Audit:      akeeper,
            Market:     keeper,
            Deployment: dkeeper,
            Provider:   pkeeper,
            Authz:      authzkeeper,
            Bank:       bkeeper,
        },
    }
}

```

This design allows the market MsgServer to invoke any module directly—whether checking provider status, querying deployment state, or managing escrow accounts—without additional interface plumbing.

### Deployment Module: Explicit Dependency Injection

Conversely, [`x/deployment/module.go`](https://github.com/akash-network/node/blob/main/x/deployment/module.go) (lines 110-129) defines discrete fields for only the keepers it strictly requires:

```go
func NewAppModule(
    cdc codec.Codec,
    k keeper.IKeeper,
    mkeeper handler.MarketKeeper,
    ekeeper handler.EscrowKeeper,
    acckeeper govtypes.AccountKeeper,
    bankKeeper bankkeeper.Keeper,
    authzKeeper handler.AuthzKeeper,
) AppModule {
    return AppModule{
        AppModuleBasic: AppModuleBasic{cdc: cdc},
        keeper:         k,
        mkeeper:        mkeeper,
        ekeeper:        ekeeper,
        acckeeper:      acckeeper,
        coinKeeper:     bankKeeper,
        authzKeeper:    authzKeeper,
    }
}

```

The deployment module holds its own `keeper.IKeeper` for state management plus **interface references** to `handler.MarketKeeper` (for pricing lookups) and `handler.EscrowKeeper` (for payments), maintaining a narrow dependency graph.

## Genesis State Management

Each module maintains distinct genesis state schemas reflecting their specialized concerns.

### Market Genesis: Orders, Bids, and Leases

The market module's `InitGenesis` function in [`x/market/genesis.go`](https://github.com/akash-network/node/blob/main/x/market/genesis.go) (lines 34-44, 80-84) initializes three separate object collections:

- **Orders** – open requests for compute resources
- **Bids** – provider responses to orders
- **Leases** – active agreements between tenants and providers

Additionally, it stores module-specific parameters controlling pricing and matching logic.

### Deployment Genesis: Workload Records

The deployment module focuses exclusively on deployment lifecycle data. Its genesis handling in [`x/deployment/module.go`](https://github.com/akash-network/node/blob/main/x/deployment/module.go) (lines 62-69) unmarshals `types.GenesisState` containing:

- Deployment records and metadata
- Deployment groups and versioning information
- Module parameters for deployment constraints

This narrower scope reflects the module's responsibility for manifest storage and status tracking rather than marketplace mechanics.

## Service Registration Patterns

The architectural split extends to how each module registers its message servers.

In [`x/market/module.go`](https://github.com/akash-network/node/blob/main/x/market/module.go) (lines 47-52), the market module passes its entire keeper aggregation to a single server:

```go
func (am AppModule) RegisterServices(cfg module.Configurator) {
    types.RegisterMsgServer(cfg.MsgServer(), handler.NewServer(am.keepers))
    querier := am.keepers.Market.NewQuerier()
    types.RegisterQueryServer(cfg.QueryServer(), querier)
}

```

The deployment module in [`x/deployment/module.go`](https://github.com/akash-network/node/blob/main/x/deployment/module.go) (lines 42-48) explicitly injects only the required dependencies:

```go
func (am AppModule) RegisterServices(cfg module.Configurator) {
    types.RegisterMsgServer(cfg.MsgServer(),
        handler.NewServer(am.keeper, am.mkeeper, am.ekeeper))

    querier := am.keeper.NewQuerier()
    types.RegisterQueryServer(cfg.QueryServer(), querier)
}

```

## Consensus Version and Schema Evolution

The modules exist at different stages of protocol evolution:

- **Market module**: Consensus version `8` (as defined in [`x/market/module.go`](https://github.com/akash-network/node/blob/main/x/market/module.go) line 80), reflecting substantial feature additions for the marketplace
- **Deployment module**: Consensus version `5` (as defined in [`x/deployment/module.go`](https://github.com/akash-network/node/blob/main/x/deployment/module.go) line 78), indicating a more stable state schema

These version numbers inform the chain's migration strategy when upgrading state between releases.

## Summary

- **Market module** acts as a **central coordinator** using a composite `handler.Keepers` struct to access account, escrow, audit, deployment, provider, authz, and bank keepers
- **Deployment module** maintains **minimal dependencies**, holding only its own keeper plus market and escrow interfaces for price lookups and payments
- **Genesis handling** differs by scope: market manages orders/bids/leases while deployment manages workload manifests and groups
- **Consensus versions** reflect different maturity levels (version 8 for market vs version 5 for deployment)
- **Service registration** follows dependency patterns: market passes a unified struct; deployment passes explicit arguments

## Frequently Asked Questions

### What is the primary architectural difference between the market and deployment modules?

The market module implements a **unified keeper aggregation pattern**, storing all dependencies in a single `handler.Keepers` struct that allows direct access to eight different keepers. The deployment module uses **explicit dependency injection**, maintaining separate fields for only the market and escrow keepers it requires, promoting better encapsulation and reduced coupling.

### How does the deployment module communicate with the market module?

According to the source code in [`x/deployment/module.go`](https://github.com/akash-network/node/blob/main/x/deployment/module.go), the deployment module receives a `handler.MarketKeeper` interface during initialization. This interface provides read-only access to market data (such as pricing information) without exposing the full market keeper implementation, allowing the deployment module to query bid and lease status during workload lifecycle management.

### Why does the market module need access to so many keepers?

The market module orchestrates the entire economic layer of Akash, requiring direct access to escrow keepers for payment processing, provider keepers for host validation, audit keepers for attribute verification, and deployment keepers for manifest correlation. As implemented in [`x/market/module.go`](https://github.com/akash-network/node/blob/main/x/market/module.go), the `handler.Keepers` struct enables the market MsgServer to atomically coordinate transactions across all these domains.

### What do the different consensus versions indicate?

Consensus version `8` for the market module versus version `5` for the deployment module indicates the market schema has undergone more breaking changes requiring migration logic. These version constants defined in each [`module.go`](https://github.com/akash-network/node/blob/main/module.go) file signal to the Cosmos-SDK upgrade module which migration handlers to execute when restarting the chain with new software.