Proof of Authority for Akash: Cutting Security Costs by 95%

[clemensgg]

Proposal

Abstract

With only minimal changes to their current software stack, Akash network could reduce their security budget by 95% or more, retain full sovereignty over their chain, and avoid extensive functionality rewrites. In this proposal, we outline two models with adjustable parameters that take advantage of the Cosmos SDK’s compatibility with Proof of Authority (POA).

Pretense

• Priority: Keep IBC, Osmosis, and Keplr as pillars of the future Akash stack

https://x.com/gregosuri/status/1977370418794086528

• Goal: Reduce Security Expenditures

https://x.com/gregosuri/status/1978297944894808262

Considerations

• Most viable possibilities: (1) CosmWasm (CW) application on other IBC-enabled chain (ie Cosmos Hub) (2) Proof of Authority (POA) Chain
• (1) Imposes some significant changes:
  • Rewriting all custom models as CW contracts
  • Changes to explorer + Keplr integration + other infra
  • Loss of sovereignty (risking MEV, chain downtime, etc)
  • Difficulty to ever move back to independent chain again
• (2) Apart from a drastic reduction of security budget, option (2) has some clear advantages:
  • Less migration overhead needed since no rewrites in CW
  • Retains sovereignty
  • Can keep current custom modules
  • Easily scalable & adaptable

Current State Of Security Budget

Akash Onchain Parameters	Results
Circulation Supply: ~ 280,000,000 AKT	Total Security Budget: ~ $2M per month (~ $24M per year)
Inflation: 8%	To Stakers: $1.9M (95%)
Bonded Ratio: 37.5%	To Validators: $100k (5%)
Community Tax: 50%
Staking APR: 10.67%
Price: $0.80 (Oct 2025)
Current Number of Validators: 100
Average Validator commission: 5%

Proposal: Proof of Authority (POA)

Proof of Authority serves as an alternate, but very similar, consensus mechanism to Proof of Stake. The primary difference between the two is that the active validator set is not determined by a decentralized process (like stake weight via delegations), but is chosen by an authority (which can even be a decentralized governance process).

• Reduction of validator set: 100 —> 21
• Removal of staking
• Private contracts with 21 validators (SLA)
• Service provision: Since many current services may be provisioned through foundation delegations, these also need to be factored in.
• Solution: distribute total budget across validation and service provision as required (examples given below)
• Two example models:

Model 1

• Keep the total current portion of security budget used for validator income: ~$100k per month
• Split this between validation and service provision budgets. We will use a 70/30 split as an example.
  • Services Budget (30%) = $30k / month
  • Validation Budget (70%) = $70k / month —> Evenly split across 21 POA validator contracts: —> $3.3k per validator per month
• This model reduces the current security budget by 95%.

Model 2

• The top 21 existing validators make up about ~70% of total security (voting power)
• A more aggressive reduction would keep 70% of the validator income ($70k). Again keeping an example 70/30 split between validation and services:
  • Services Budget (30%) = $21k / month
  • Validation Budget (70%) = $49k / month —> Evenly split across 21 POA validator contracts: —> $2.3k per validator per month
• This model reduces the security budget by 96.5% - an additional 30% reduction from Model 1.

Conclusion

We present these models as examples that are closely in line with the current model utilized by Neutron, who have entirely maintained their software stack by engaging 20 POA validators with a fee of $3k per month.

As an interesting thought experiment, even with no increase in the price of AKT resulting from the reduced sell pressure, one year’s worth of current security budget (~$24M) would be sufficient to entirely fund security and services for ~20 years (under Model 1) and ~28 years (under Model 2), while simultaneously:

• Reducing development overhead from rewriting modules
• Keeping all desired parts of the current stack (IBC, Keplr, Osmosis, etc)
• Maintaining full sovereignty over chain-level functionality
• Massively reduced difficulty in decentralizing the chain later as needed

We would be delighted to discuss any details or additional considerations further!

Authors:
Robin Tunley, Clemens Scarpatetti
CryptoCrew Validators