Akash is running two economies at once, and AKT has to underwrite both
Akash is a decentralized marketplace for cloud compute. Tenants post deployments, providers bid, and leases stream payments out of escrow per block. That part looks like a classic two-sided market.
The other economy is the chain itself. Akash is a Cosmos-SDK Proof-of-Stake network where AKT is staked for security, earns inflationary rewards, and controls governance parameters like inflation and take rates.
Those two systems collide in one place: the security budget. If compute demand grows but most settlement happens in stablecoins, AKT’s fee capture can weaken. If issuance is cut faster than fees grow, validator incentives thin out. Akash’s own roadmap language is unusually explicit about this trade-off. It frames stable payments as helpful for adoption, while warning that reduced AKT demand can “potentially compromise” network security without compensating protocol fees.
Supply and emissions: where the chain’s security budget really comes from
Public token trackers commonly cite Max Supply: 388,539,008 AKT, with total supply around 288 million AKT. That matters because it sets expectations for dilution and for how long emissions can keep paying validators.
Akash’s original “Token & Mining Economics” paper describes a supply curve that asymptotically approaches about 3.89× the genesis supply. It states an initial 100,000,000 tokens at genesis and that “the maximum amount of tokens ever created will be 389 million.” The widely cited max supply figure (388,539,008) is consistent with that design intent.
From a security-budget perspective, the important question is not the narrative “cap.” It is the ongoing emission rate that pays validators and delegators today, and how quickly that rate can fall relative to real fee income.
Recent on-chain parameters imply a minting regime with inflation min 4%, inflation max 8%, and a goal bonded ratio 67%, with an expected 5,256,000 blocks per year. The same dataset shows the current minting inflation value at 8% and annual provisions around 23,024,139 AKT.
Governance has actively pushed emissions downward. Proposal #283 (“Akash Inflation Update Proposal - March 6 2025”) passed and explicitly reduced inflation max from 13% to 8% and inflation min from 8% to 4%.
Here is the tension a security-budget maximalist cares about: Akash is choosing lower ongoing issuance, which is good for dilution optics. But it is also choosing to put more weight on fee capture and on discretionary spending from the community pool to keep validator economics healthy. That can work. It just makes sustainability more path-dependent on governance competence and real marketplace throughput. For a broader framework on evaluating these trade-offs, see our tokenomics research.
Genesis allocations: who started with AKT, and what that implies for security
Akash did not start as a fair launch. It started with a 100 million genesis supply allocated across investors, team, foundation, and ecosystem buckets, alongside a larger future issuance stream intended to fund staking rewards over time.
The most concrete breakdown in widely accessible public materials appears in exchange and research disclosures rather than in a single canonical “foundation report” page. A disclosure document provides a genesis breakdown stating that the initial supply of 100,000,000 AKT was distributed across the following buckets and percentages.
- Private investors: ~34.5% (~34.5M AKT).
- Team & advisors: 27% (27M AKT).
- Foundation: ~19.7% (~19.7M AKT).
- Ecosystem: 8%.
- Testnet: 5%.
- Vendors & marketing: 4%.
- Public sale: 1.8%.
Why does this matter for security? Because the validator set’s economic weight is influenced by early ownership and long-run staking behavior. If large early holders stake heavily, the chain can look “secure” by bonded ratio while still being politically concentrated. If large early holders disengage, the chain has to buy security in a market where the next marginal staker is more price sensitive.
Utility and fiscal flows: escrow, take rates, community pool, and who gets paid
AKT’s product utility is direct. In product terms, a tenant funds an escrow account, the protocol pays providers per block, and unused escrow is refunded on close.
Akash’s docs describe escrow funding as AKT/USDC deposits (with a stated minimum of 0.5), followed by automated per-block payments to providers. Providers can withdraw earnings, and tenants can top up escrow.
Those payment rails create a value-capture problem that most DePIN projects eventually face: payment convenience competes with native-token demand. Akash’s roadmap AEP-55 calls this out directly. It says USDC-based payments can “reduce AKT demand” and that this can “potentially compromise” security, then proposes a protocol “Take Fee” on USDC payments to compensate. If you’re mapping these flows end-to-end, a quick review of token economy components can help.
On-chain, this concept is implemented via a dedicated Take module (x/take). Akash’s docs describe it as “Network income distribution,” with parameters including a default take rate and denom-specific take rates. The stated purpose is to collect marketplace fees, fund the community pool, and support “sustainable network economics.”
The practical details have been iterating in public specs. A public “Stable payments & Take rates” discussion includes a draft table with AKT take rate 4% and Axelar USDC take rate 20%, and states that take rates should be adjustable via governance. That same discussion also notes that, at the time it was written, “the only supported form of payment and settlement on Akash Network is the network’s native AKT coin,” which gives you a clean before-and-after framing: stable settlement is an intentional shift, not a genesis assumption.
Governance has also discussed lowering take rates as the network matures. A proposal to “Reduce Take Rate for uAKT and axlUSDC denoms” proposes setting a 1% take rate for uAKT and a 2% take rate for axlUSDC. If those values are adopted, Akash is making a clear bet that reduced friction increases throughput enough to maintain fee revenue while improving user experience.
Now tie this back to PoS compensation. Akash’s on-chain distribution parameters show a community pool tax of 50%. That means a large share of issuance is routed to a governance-controlled pool rather than directly to validators and delegators as staking rewards. It can still support security if it is spent on security-critical incentives. It can also dilute security if it becomes a general-purpose slush fund or if it is underutilized while validator economics degrade.
Governance and parameter control: emissions are political, take rates are political
Akash is explicit that AKT holders govern critical parameters such as inflation rate and take rates. In practice that means emissions, fee capture, and even marketplace affordability are downstream of governance outcomes. If you want a process for stress-testing governance-controlled levers, our tokenomics methodology is a useful starting point.
On-chain governance constraints shape who can realistically influence those outcomes. Current governance parameters include a minimum deposit of 1,000 AKT, a voting period of 7 days, and quorum and veto thresholds at 33.4%, with a 50% passing threshold.
Validator economics are constrained too. Akash currently enforces a minimum commission rate of 5%. That is a subtle but important “security hygiene” parameter. It prevents a race to zero commission that can starve operators, then forces them to monetize via side deals or by cutting corners on ops.
Finally, PoS security is only as credible as its liveness and slashing regime. Akash’s indexed slashing parameters show a signed blocks window of 10,000, min signed per window of 5%, downtime jail duration of 10 minutes, and slashing fractions of 5% for double-sign and 0.01% for downtime. These values do not guarantee security. They do define the operating envelope for professional validators and the expected cost of misbehavior.
Risk analysis: the dominant risk is security-budget fragility during fee-transition
Dominant risk: Security budget compression before fee capture is proven.
Akash is intentionally transitioning from “pay security with issuance” toward “pay security with a mix of issuance plus marketplace fees.” We’ve seen similar security-budget transitions discussed in Helium tokenomics, where usage-driven revenue must eventually carry more of the load.
You can see this transition in three separate public artifacts. First, governance cut inflation bounds (Proposal #283 reduced inflation max to 8% and min to 4%). Second, the protocol has a Take module designed to capture marketplace fees and route them into collective pools. Third, Akash’s own roadmap AEP-55 states that stable payments reduce AKT demand and can compromise security, then proposes USDC take fees that buy AKT and burn some of it while earmarking some for future staker distribution.
From a security-budget maximalist lens, the failure mode is straightforward. If issuance is reduced and stable settlement grows faster than native-token settlement, then the chain’s security spend becomes dependent on take-rate design, fee enforcement, and governance execution. That can be fine when revenues are large, predictable, and strongly aligned with validator income. It is dangerous when revenues are lumpy, routed into a community pool, and subject to political allocation.
The current on-chain configuration increases that dependency. A 50% community pool tax is a strong statement that governance wants discretionary budget. If the community pool is not transparently and consistently deployed to defend decentralization and liveness, the validator set is left with thinner direct rewards at exactly the moment Akash is pushing hard on product adoption and multi-currency payments.
There is no purely technical fix here. It is a policy problem. Akash needs either (1) sustained, enforceable fee flows that accrue to security providers in a predictable way, or (2) willingness to keep issuance meaningfully positive until fee flows are demonstrated at scale. Cutting issuance first and hoping fee volume catches up is the unstable ordering.
Top 3 risks
-
Security budget shortfall during adoption churn. Trigger: governance reduces inflation or take rates while marketplace volume or AKT price falls. Mechanism: validator revenue drops, marginal operators exit, stake concentrates, and censorship or liveness risk rises. Who bears it: tenants (downtime), delegators (missed rewards and slashing spillover), and the protocol (trust loss). Measurable indicators: inflation parameters drifting down, annual provisions declining, validator set concentration increasing, and persistent reliance on “current inflation = max” behavior (suggesting bonded-ratio targeting is not lowering issuance).
-
Fee capture misalignment under multi-currency settlement. Trigger: stablecoin payment becomes the dominant rail without a compensating take fee that effectively recycles value into AKT security. Mechanism: users get compute without touching AKT, weakening the link between product-market fit and staking demand, and pushing the chain back toward “security funded by inflation.” Who bears it: long-term AKT holders (dilution without offsetting demand) and validators (weaker fee tail). Measurable indicators: share of deployments funded with USDC rising, governance debates pushing take rates toward zero, and buyback-and-burn mechanisms staying in “draft” status rather than shipping.
-
Governance capture and discretionary-spend drift. Trigger: large stakeholders coordinate to steer community-pool spending or economic parameters toward short-term price optics instead of decentralization. Mechanism: community pool accumulates via high tax while direct validator incentives weaken, then funds are spent on initiatives that do not improve censorship resistance or validator diversity. Who bears it: delegators and tenants via degraded neutrality. Measurable indicators: sustained high community tax, repeated emissions cuts without fee replacement, and low validator profitability signals like rising commission pressure or shrinking active-set diversity.
One practical note for teams building on Akash: the technical docs are strong, but the economic surface area is increasingly governance-defined. If you are budgeting compute costs, you are implicitly budgeting future take-rate policy too. For treasury design or parameter stress tests, it can be worth a short engagement with a tokenomics design firm comfortable modeling validator incentives under multiple fee and issuance regimes.
This article is part of our Tokenomics Deep Dive series.








