Market vs Deployment Modules in Akash Node: Architectural Differences Explained

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, 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:

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 (lines 110-129) defines discrete fields for only the keepers it strictly requires:

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 (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 (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 (lines 47-52), the market module passes its entire keeper aggregation to a single server:

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 (lines 42-48) explicitly injects only the required dependencies:

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 line 80), reflecting substantial feature additions for the marketplace
• Deployment module: Consensus version 5 (as defined in 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, 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, 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 file signal to the Cosmos-SDK upgrade module which migration handlers to execute when restarting the chain with new software.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}