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

[ste316]

Hi, thanks for the proposal, honestly I don’t think this a good idea.

PoA is not aligned with Crypto fundamentals and I think Neutron chain is not a good example anyway…

Tell you more, if the security is inherited from an existing chain, e.g. Solana, the Whole security budget can be used as a concrete Incentive Mechanism to promote Akash Network Usage and attract more users!

The best logical option is Solana (I am sure at 90%) or maybe Bittensor even though they strongly lack Marketing and ease of use / ease of understanding

[clemensgg]

Thanks for your feedback, but your response does not contain any details on how such a migration would be implemented and how much it might cost. Let’s break things down:

1. Migrating to Solana would make it impossible for Akash to maintain most of its current tech stack, which means each level of this would require new integrations - wallets, explorers, DEXs, etc. We have factored this into our model based on Greg’s stated priorities.

2. All security has costs, so using “the Whole security budget” as a “concrete Incentive Mechanism” doesn’t really make sense. Migration costs are a large factor too.

3. “PoA is not aligned with Crypto fundamentals” -> Akash’s current Nakamoto coefficient is 6, but a migration to POA in the model we suggest above would actually raise that value to 8, making the chain more decentralized in a very meaningful sense. Validator set selection can be outsourced to governance. In addition, migrating back from POA to a chain with fully decentralized validator set in the future is MUCH easier than migrating back from a set of Solana smart contracts.

4. I think we can agree that sovereignty and transparency are certainly aligned with crypto fundamentals. As a POA chain, the Akash community would have far greater control over chain downtime, MEV, and other important infrastructure variables. On Solana, they would be entirely at the mercy of the Solana validator set, who are not at all inclined to keep Akash’s best interests in their business model.

All in all, it seems you have tried to make the claim that Solana is “The best logical option”, but have provided no details on how such a migration would (a) capture the stated priorities of the Akash community (like Greg) and (b) cost to realistically implement.