CommunityLive ChatCareersSupport
Search…
Akash Guidebook
Intro to Akash
Tokens and Wallets
Deployments
Integrations
Providers
Akash Nodes
Validating
Command Line
Features
Other Resources
Experimental
Security
Containers
Marketplace
Payments
Authentication
Akash Provider Migration Guide - 0.14.X to 0.16.3
Powered By GitBook
Marketplace
Contents:

How does the Marketplace work?

The Akash Marketplace revolves around Deployments, which fully describe the resources that a tenant is requesting from the network. Deployments contain Groups, which is a grouping of resources that are meant to be leased together from a single provider.
Deploying applications onto Akash involves two types of users:
  1. 1.
    The Tenant: the entity that deploys the application.
  2. 2.
    The Provider: the entity that hosts the application.

What is a Reverse Auction?

Akash uses a reverse auction. Tenants set the price and terms of their deployment, and the Cloud providers bid on the deployments.
In a very simple reverse auction:
  1. 1.
    A tenant creates orders.
  2. 2.
    Providers bid on orders.
  3. 3.
    Tenants choose winning bids and create leases.
A typical application deployment on Akash will follow this flow:
  1. 1.
    The tenant describes their desired deployment in [SDL], called a deployment.
  2. 2.
    The tenant submits that definition to the blockchain.
  3. 3.
    Their submission generates an order on the marketplace.
  4. 4.
    Providers that would like to fulfill that order bid on it.
  5. 5.
    After some period of time, a winning bid for the order is chosen, and a lease is created.
  6. 6.
    Once a lease has been created, the tenant submits a manifest to the provider.
  7. 7.
    The provider executes workloads as instructed by the manifest.
  8. 8.
    The workload is running - if it is a web application it can be visited
  9. 9.
    The provider or tenant eventually closes the lease, shutting down the workload.
The general workflow is:
  1. 1.
    A tenant creates orders.
  2. 2.
    Providers bid on orders.
  3. 3.
    Tenants choose winning bids and create leases.

Lifecycle of a Deployment

The lifecycle of a typical application deployment is as follows:
  1. 1.
    The tenant describes their desired deployment in [SDL], called a deployment.
  2. 2.
    The tenant submits that definition to the blockchain.
  3. 3.
    Their submission generates an order on the marketplace.
  4. 4.
    Providers that would like to fulfill that order bid on it.
  5. 5.
    After some period of time, a winning bid for the order is chosen, and a lease is created.
  6. 6.
    Once a lease has been created, the tenant submits a manifest to the provider.
  7. 7.
    The provider executes workloads as instructed by the manifest.
  8. 8.
    The workload is running - if it is a web application it can be visited
  9. 9.
    The provider or tenant eventually closes the lease, shutting down the workload.

Payments

Leases are paid from deployment owner (tenant) to the provider through a deposit & withdraw mechanism.
Tenants are required to submit a deposit when creating a deployment. Leases will be paid passively from the balance of this deposit. At any time, a lease provider may withdraw the balance owed to them from this deposit.
If the available funds in the deposit ever reaches zero, a provider may close the lease. A tenant can add funds to their deposit at any time. When a deployment is closed, the unspent portion of the balance will be returned to the tenant.

Escrow Accounts

​Escrow accounts are a mechanism that allow for time-based payments from one account to another without block-by-block micropayments. They also support holding funds for an account until an arbitrary event occurs.
Escrow accounts are necessary in akash for two primary reasons:
  1. 1.
    Leases in Akash are priced in blocks - every new block, a payment from the tenant (deployment owner) to the provider (lease holder) is due. Performance and security considerations prohibit the naive approach of transferring tokens on every block.
  2. 2.
    Bidding on an order should not be free (for various reasons, including performance and security). Akash requires a deposit for every bid. The deposit is returned to the bidder when the bid is closed.

Bid Deposits

Bidding on an order requires a deposit to be made. The deposit will be returned to the provider account when the bid transitions to state CLOSED.
Bid deposits are implemented with an escrow account module. See here for more information.

Audited Attributes

Audited attributes allow users deploying applications to be more selective about which providers can run their apps. Anyone on the Akash Network can assign these attributes to Providers via an on-chain transaction.

On-Chain Parameters

Name
Initial Value
Description
deployment_min_deposit
5akt
Minimum deposit to make deployments. Target: ~$10
bid_min_deposit
50akt
Deposit amount required to bid. Target: ~$100

Transactions

DeploymentCreate

Creates a deployment, and open groups and orders for it.

Parameters

Name
Description
DeploymentID
ID of Deployment.
DepositAmount
Deposit amount. Must be greater than deployment_min_deposit.
Version
Hash of the manifest that is sent to the providers.
Groups
A list of group descriptons.

DeploymentDeposit

Add funds to a deployment's balance.

Parameters

Name
Description
DeploymentID
ID of Deployment.
DepositAmount
Deposit amount. Must be greater than deployment_min_deposit

GroupClose

Closes a group and any orders for it. Sent by the tenant.

Parameters

Name
Description
ID
ID of Group.

GroupPause

Puts a PAUSED state, and closes any and orders for it. Sent by the tenant.

Parameters

Name
Description
ID
ID of Group.

GroupStart

Transitions a group from state PAUSED to state OPEN. Sent by the tenant.

Parameters

Name
Description
ID
ID of Group.

BidCreate

Sent by a provider to bid on an open order. The required deposit will be returned when the bid transitions to state CLOSED.

Parameters

name
description
OrderID
ID of Order
TTL
Number of blocks this bid is valid for
Deposit
Deposit amount. bid_min_deposit if empty.

BidClose

Sent by provider to close a bid or a lease from an existing bid.
When closing a lease, the bid's group will be put in state PAUSED.

Parameters

name
description
BidID
ID of Bid

State Transitions

Object
Previous State
New State
Bid
ACTIVE
CLOSED
Lease
ACTIVE
CLOSED
Order
ACTIVE
CLOSED
Group
OPEN
PAUSED

LeaseCreate

Sent by tenant to create a lease.
  1. 1.
    Creates a Lease from the given bid.
  2. 2.
    Sets all non-winning bids to state CLOSED (deposit returned).

Parameters

name
description
BidID
​Bid to create a lease from

MarketWithdraw

This withdraws balances earned by providing for leases and deposits of bids that have expired.

Parameters

name
description
Owner
Provider ID to withdraw funds for.

Models

Deployment

Name
Description
ID.Owner
account addres of tenant
ID.DSeq
Arbitrary sequence number that identifies the deployment. Defaults to block height.
State
State of the deployment.
Version
Hash of the manifest that is sent to the providers.

State

Name
Description
OPEN
Orders may be created.
CLOSED
All groups are closed. Terminal.

Group

Name
Description
ID.DeploymentID
​Deployment ID of group.
ID.GSeq
Arbitrary sequence number. Internally incremented, starting at 1.
State
State of the group.

State

Name
Description
OPEN
Has an open or active order.
PAUSED
Bid closed by provider. May be restarted.
CLOSED
No open or active orders. Terminal.

Order

Name
Description
ID.GroupID
​Group ID of group.
ID.OSeq
Arbitrary sequence number. Internally incremented, starting at 1.
State
State of the order.

State

Name
Description
OPEN
Accepting bids.
ACTIVE
Open lease has been created.
CLOSED
No active leases and not accepting bids. Terminal.

Bid

Name
Description
ID.OrderID
​Group ID of group.
ID.Provider
Account address of provider.
State
State of the bid.
EndsOn
Height at which the bid ends if it is not already matched.
Price
Bid price - amount to be paid on every block.

State

Name
Description
OPEN
Awaiting matching.
ACTIVE
Bid for an active lease (winner).
CLOSED
No active leases for this bid. Terminal.

Lease

Name
Description
ID
The same as the bid ID for the lease.
State
State of the bid.

State

Name
Description
ACTIVE
Active lease - tenant is paying provider on every block.
CLOSED
No payments being made. Terminal.
Previous
Containers
Next
Payments
Last modified 21d ago
Copy link
Contents
How does the Marketplace work?
What is a Reverse Auction?
Lifecycle of a Deployment
Payments
Escrow Accounts
Bid Deposits
Audited Attributes
On-Chain Parameters
Transactions
DeploymentCreate
DeploymentDeposit
GroupClose
GroupPause
GroupStart
BidCreate
BidClose
LeaseCreate
MarketWithdraw
Models
Deployment
Group
Order
Bid
Lease