Decentralized Cloud Standards (DCSs) describe standards for the Akash platform, including core protocol specifications, client APIs, and SDL standards.
DCS status terms
- Draft - a DCS that is open for consideration and is undergoing rapid iteration and changes.
- Last Call - a DCS that is done with its initial iteration and ready for review by a wide audience.
- Accepted - a core DCS that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode an DCS into their clients as part of a hard fork is not part of the DCS process. If such a decision is made, the DCS will move to final.
- Final (non-Core) - a DCS that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
- Final (Core) - a DCS that the Core Devs have decided to implement and release in a future hard fork or has already been released in a hard fork.
DCSs are separated into a number of types, and each has its own list of DCSs.
Standard Track (8)
Describes any change that affects most or all Akash implementations, such as a change to the the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Akash. Furthermore Standard DCSs can be broken down into the following categories.
Improvements around client API specifications and standards, and also certain language-level standards like method names (DCS-3).
Improvements around Akash Economic Model with regards to Staking or Subsidy distribution (DCS-9).
Describes a process surrounding Akash or proposes a change to (or an event in) a process. Process DCSs are like Standards Track DCSs but apply to areas other than the Akash protocol itself. They may propose an implementation, but not to Akash's codebase; they often require community consensus; unlike Informational DCSs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Akash development. Any meta-DCS is also considered a Process DCS.
Describes a Akash design issue, or provides general guidelines or information to the Akash community, but does not propose a new feature. Informational DCSs do not necessarily represent Akash community consensus or a recommendation, so users and implementers are free to ignore Informational DCSs or follow their advice.