5AKT lock on every deployment is killing Spheron Scalability & Demand

[izrake]

5 AKT is the first bottleneck for anyone to scale in Akash Ecosystem

Spheron Network, a significant deployment activity driver of the Akash Network, has recently faced a critical challenge due to the unexpected depletion of Akash Token (AKT) reserves, which are essential for maintaining our active leases and CPU utilization. Despite a robust increase in deployment activities, peaking at nearly 5,000 deployments within the first half of January, we encountered a severe setback. The unexpected loss of all our AKT in lease creation necessitated an urgent purchase of AKT at a premium from the market, straining our resources and negatively impacting our service quality and user trust.

Situation Overview:

High Activity Levels:

Spheron Network recently scaled to whooping 650+ active leases via its platform & then we hit this scaling bottleneck issue.

Unforeseen Resource Drain:

The complete depletion of our AKT reserves during lease creation was unforeseen and has placed considerable operational stress on our treasury.

Immediate Response Required:

The current situation demands a quick response to avoid further negative impacts on our user base and to keep the growth and health of the Akash Network.

Proposal:

We propose to reduce the price of the lease creation & must be pegged to USD value instead of token value. Must be set to as minimum as possible.

Impact Analysis:

User Trust and Network Growth:

I'd like to point out that this issue will quickly restore user confidence in the Spheron Network and the Akash Network, fostering a healthy, growing ecosystem.

Conclusion:

Reducing the cost of the lease will reduce the friction of scaling.

[cloud-j-luna]

Thank you for such a detailed post. I understand very well your challenges and we are facing those ourselves as we develop our platform on top of Akash. As more and more of these platforms appear on the market these will face this same issue.

With this being said, we found a solution that works for our scale. We believe that asking for liquidity in this way will not solve the problem, if users are paying for your their deployments part of those would go towards increasing your liquidity. It's against the principles of the community to use community pool resources to fund closed source projects (apologies if I'm wrong on this and you are open sourced). I think it would create a negative precedent on the network. Again, we face the same challenges as you and we are not yet live, but there are ways this can be solved in a more scalable way.

[izrake]

Hey,

Yes, you are right & why we are closed source because we are making some changes in the code to make it open source & allow other community members to participate.

We are not asking for any grant to fill our treasury; we are requesting loaning the AKT, causing the scalability issue.

Also, we did fund public source projects but check the metric where they are & where we are; I think supporting projects, whether they are public or private, should not be a matter if the chain is gaining activity & we are riding on the numbers in terms of chain activities every day on socials, is not that also bad that showing the numbers which are driven by private source code startup at the moment?

Negative precedence will be set when a project like ours stops using the Akash chain to manage resources. But I appreciate your thoughts on how the community fund must be used.

[izrake]

Hey Everyone,

We have made some changes to the discussion. I thought this place wouldn't be asking for a community pool fund. I made some necessary changes in the proposal & looking forward to seeing the progress in this direction.

[cloud-j-luna]

Thank you for your effort! I understand the concern over the 5AKT deposit for deployments. I also think that it does not scale well as the token price fluctuates.

My concern here is:

Must be set to as minimum as possible.

We have to be careful as setting this value too low could have negative impact on UX as deployments could close soon after being created.

Reducing the cost of the lease will reduce the friction of scaling.
You are not reducing the cost of the lease, this is misleading. You are lowering the starting amount of the escrow account.

I'm not as experience as Artur from OCL on this matter so I'm sure he'll have a lot to add to this discussion.
I do believe lowering this value through proposals or introducing some dynamic mechanism for setting this sounds like a good idea.

[troian]

thanks @izrake for bringing this up.

at first let me put some clarification into the workflow.

• Deployment deposit is a deposit, not a withdraw.
• Deposit is placed into escrow account, from which network performs withdraw of funds for used compute time (per block) on provider's request.
• When amount in escrow account is 0, network closes lease immediately. To prevent that tenant must keep an eye on escrow account.
• Lease cannot be created until escrow account has funds in it

now moving on:
simply reducing Deposit amount does not solve the issue of having sufficient balance of AKT when scaling up as AKT is volatile asset.

as summary from above, deposit must be present at time of deployment create. we're considering to lower it, however it is likely going to be around 1akt or so.

some comments to actual wording

The unexpected loss of all our AKT in lease creation necessitated an urgent purchase of AKT at a premium from the market, straining our resources and negatively impacting our service quality and user trust.

1. it's not a loss, neither it is unexpected. funds are on hold as deposit and returned back to your accounts as soon as lease gets closed.
2. could you describe what kind of premium is that? there are many ways to purchase AKT at market price.

[izrake]

1. it's not a loss, neither it is unexpected. funds are on hold as deposit and returned back to your accounts as soon as lease gets closed. - What I meant was, during scale, those AKTs are blocked & that basically means now, in the second lease, we cannot use the same AKT anymore. A loss there means losing on every lease creation. For example, we have created 10K Leases in total, so we need to have 50K AKT in value; now all these happen in parallel, which basically means there is also a delay of these locked AKT to be back & if we keep that delay in the account building parallel scalability around the same will be hit. I hope I am able to explain it here.

2. could you describe what kind of premium is that? there are many ways to purchase AKT at market price -> Premium basically comes when we have to buy over market fluctuating price. Take the above case again; if the token price is $1, it will take $50K liquidity to reach there, but if the token price becomes $3, then we need $150K now. This is what I mean here. Also, then as a entity we have to pay fees as well which is minimum & then accounts fees because that also comes on our books & many more which make it premium price for us

[heyhewi]

@izrake Proposal 12 dropped the min deposit from 50 to 5 AKT. If you feel reducing min deposit would help your operations, you can always submit a parameter change proposal as it is permissionless.

[brewsterdrinkwater]

Hello.

Thank you to @izrake for starting this discussion. After much discussion in special interest groups and elsewhere, the core team is going to recommend a parameter change from 5 akt to .5 akt for the bid deposit.

[cloud-j-luna]

This will enable improved scalability for services integrating with Akash Deployments. Currently there is almost a 20$ commitment to create a deployment. Great initiative!

[baktun14]

Proposl 248 Fixes this

[brewsterdrinkwater]

This parameter has passed on chain, and is now working. https://www.mintscan.io/akash/proposals/248

The minimum bid is 0.5 AKT.