Enhancing the Evolution of SKALE Chain Pricing and Moving into Network Growth Phase 2

[TheGreatAxios]

Hey @payvint

Thanks for putting this together!
I think it fits the initial proposal quite nicely. I don’t have any comments or concerns on the validator requirements. My only request is for clarification on SKALE Chain Deletion timing.

I see in the Operations section, that there is a note that SKALE Chains can be deleted taking place on the first day of the next month. Confirming this means that there is actually an N + 1 runway for the chain.

Meaning if the first chain payment is due on Dec 1 and max # of months you can go without paying (N) is set to 2 (for example), then if the chain runs through January and gets to Feb 1 with no payment it can be scheduled for deletion? Or does it then need to wait until March 1?

[olehnikolaiev]

hey @payvint ! glad to see SKALE Chain Pricing discussion going! is it planned to add automated checks or SLA at stage 3 to check validators compliance? if so does it mean that in after the stage 3 there will be no need in decentralized security committee?

[payvint]

Hey @TheGreatAxios

Good question!

So if SKALE chain “A” was paid for one months starting 1 Dec(Owner of this chain paid in November)

It is necessary to pay for January months in Dec(for example in 29 Dec)
If the payment is missing and 1 January already come - this month would be considered as a missing month and would collect debt.

After the 1 January Owner of SKALE chain “A” need to pay debt first and after that pay the next month/months

Debt can be collected for up to 3 months - after that ownership of SKALE chain would be passed to SKALE Multisig, it is not correct for users to delete a SKALE chain if it was not payed by the owner.

So in this case if the debt for the chain was not payed until the 1 April - SKALE chain ownership would be transferred to the SKALE Multisig.

If the Owner of SKALE chain “A” decided to cover the debt on 31 March - Owner need to pay debt first (January, February, March) and then owner can pay for April and etc

Thanks!

[payvint]

Hey @olehnikolaiev

You are right!

In first implementation of SKALE Manager(Set of smart contract on Ethereum which controlling the whole SKALE Network) there was a first implementation of SLA to check node characteristics/stats/requirements and etc
But it was a proposal to remove it because of amount of computation which is needed on Ethereum and costs.

So Decentralized SLA would be a Decentralized security committee by itself:)

There are plans to run it on SKALE chain and roll it up to Ethereum via Levitation protocol.

So each validator node would checks other validator nodes and send verdicts regarding the operational health to the smart contract, which would analyze all the verdicts and slash or benefit depends on results.

Also thanks to SKALE Connect(Built in Oracle into the skale-node) - it would be possible to verify different off-chain requests(like time to response, skale chain docker containers health and etc).

Decentralized SLA on SKALE chain would be much more powerful than it was in a first implementation thanks to SKALE ecosystem features development and improvements.

[Edouard_Stakin]

Hi everybody,

As a validator operator at Stakin and a long-term supporter of the Skale ecosystem, it’s exciting to see this plan about Skale Chain Pricing going live and the transition into Phase 2 of Skale’s development, as well as the upcoming Phase 3.

Skale has achieved significant traction in the number of active Skale chains, and transactions, and contributed to saving billions of dollars of gas fees for the end users. Now that Skale has achieved a certain level of traction, it seems like a natural evolution to open up the discussion of Chain Pricing and progressively move away from a free model.

I believe that Skale Chain Pricing going live represents a big opportunity to further strengthen the ecosystem, giving additional value to the SKL token (more demand, less need for inflation), and further incentivizing stakers and validator node operators.

It’s important to strike the right balance in terms of pricing to ensure Skale remains attractive for builders. I would love to see an iterative approach in the future with regular reviews of the Chain Pricing model and open discussions like this one, to ensure we all benefit from ecosystem builders to stakers to validators.

I don’t have many questions at this stage. The plan is well-structured and makes sense. All in all, my opinion is that this proposal should benefit the ecosystem in the long term and will happily support this plan. Would love to read some thoughts from delegators and other ecosystem participants too.

[delightlabs_io]

Hi SKALE community,

As DELIGHT LABS has been validating since its genesis, we’re very glad to hear about this and more upcoming proposals. The community would be excited that SKL becomes no longer an inflationary currency but will activate its own function. I’m glad to see that the roadmap on the whitepaper turns into the real.

There’s no objection in the overview but some questions about the network utilization - pricing graph.

1. How much is the utilization now?
2. Is there any reason why the pricing hugely increases between 45% and 50%, about 10x? If it is around 50%, I wonder which dApp company could pay tens of thousand USD monthly.

• Could the multiplier be lower?
• Could the increase point be started from more earlier utilization?

The graph below does not mean any exact, derived point but just shows my brief opinion.

[ethalita]

Hi @payvint
Thanks, I’m thrilled about this. Agree with @delightlabs_io on his question, appreciate if you can share a bit about the choice of parameter values.

We at Chorus One believe in Skale’s potential and appreciate this proposal addressing any concerns regarding profitability and sustainability of the Network. We’re happy to continue supporting the Network and ecosystem in this new phase.

[delightlabs_io]

@payvint Plus, the chart would be more reasonable if you could show the data below, if possible (I remember there’s any survey related on this.):

• expected gas consumption if the dApps are shipped on ETH network
• any attraction factor from no gas consumption by users
• the expecting critical point between staying on SKALE and leaving to another EVM network

[TheGreatAxios]

Hey @Edouard_Stakin

I fully agree that the right balance does need to be found here. As this is pretty new territory for everyone, I think iterating on this on a consistent basis to start and checking in with all parties who are involved makes complete sense. I will think deeper about the items that we should be checking on. At a minimum, the numbers and processes can always have changes proposed that can be finalized with a vote (same as this will be).

[TheGreatAxios]

Hey @delightlabs_io @ethalita

Thanks to both of you for questions and thoughts as well.
The questions in this comment here: Enhancing the Evolution of SKALE Chain Pricing and Moving into Network Growth Phase 2 - #10 by delightlabs_io are:

Q: How much is the utilization now?
A: The current utilization is going to be the totalNumberOfNodesInTheNetwork / 2. The reason for it being divided by two is because a SKALE Chain 1 subnode from 16 individual nodes. With each individual node supporting up to 8 subnodes, then we can just do 16/8 = 2. This means if we aggregate the number of subnodes together it takes 2 nodes worth of subnodes to run a SKALE Chain today.

According to the SKALE Network Dune dashboard, the current number of Active nodes in the network is 115 (https://dune.com/queries/2771528/4619198). I am not sure how many nodes are available in a different state (will let @payvint hop back in and confirm that), but if we use the 115 the current number. We can then take that and divide it by 2 as we did above. That gives us 57.5 or 57 SKALE Chains available if every node were to host the maximum number of SKALE Chains.

From there, we can see that the network has 20 chains running today so 20/57.5 ~= 34.78% utilization as of today with these numbers.

**Q: Is there any reason why the pricing hugely increases between 45% and 50%, about 10x?

A: With each SKALE Chain having an average throughput capacity of ~400 tps. It means a SKALE Chain can do over 10 billion transactions per year. That’s in addition to the on-chain file storage of ~60gb, built in random-number generation in Solidity, and native Oracle solution. This makes each and every SKALE Chain highly valuable from a pure compute perspective. However, something that should not be discounted is the security and setup of the network. SKALE Network operates using a pooled-security model which means the SKALE Chains share the nodes. This means instead of having to create a means of incentivizing validators that is going to be sustainable and secure in the short and long term, recruiting validators, and managing everything that comes along with bootstrapping a network; with SKALE you can have a new chain spun up in I believe just a few minutes (fact check on how long to spin up a new chain please @payvint ) that is integrated with all the other chains in the network via IMA, takes advantage of this pooled security model, etc etc.

With the ultimate goal being profitability for validator hardware; the jump in price should ensure this as chains become more and more in-demand. It’s also important to note that the goal of chain pricing is to be used in the short-term for validator operators only, but in the long-term used to create even greater sustainability for the delegators as well. The price increase will make sure that even as portions of chain payments are diverted to other areas of the network; validators are always being properly supported to ensure the successful operation of the network.

Q: Could the multiplier be lower?

Yes! It certainly is possible and these numbers are all flexible and could be changed either before a vote is made for this first proposal, or in the future through another vote. One thing I would like to clarify is that all the numbers used in this proposal took months of research, discussion, and collaboration to get to where it is today with the goal of not only working – upon a passing vote – but also with the goal of being sustainable in the long-term.

Anybody is welcome to propose alternative numbers, time-frames, etc to help aid in the community effort to bring this to fruition!

Q: Could the increase point be started from more earlier utilization?

Once again here, I believe yes it certainly could. However, the outcome of lowering the utilization % increase point to some other number that is lower than the proposed could have a negative result on the network as a whole. For example, 50% of 57 chains is ~23 chains. This means that if the 50% target was lowered to for example 30%, then upon go-live all chains in the network would be required to pay the ~$46,000 a month which could result in many chains choosing to leave. As more chains leave, the validators would actually lose out on payments for each and every chain that chooses to leave with a possible result being enough chains leave that the utilization goes below 30% and the validator operators are being paid the same starting number, but for far fewer chains meaning less for everyone.

Hope the above answers some of your questions! Please feel free to tag me with any other questions.

Thanks!

[delightlabs_io]

@TheGreatAxios @payvint
Fully agree with your opinion, and it would be good to proceed to vote for this time and calibrate the number later. I believe that the number is derived from your research but some questions above came in my brain because there was no number written in this post.

Waiting that some critical numbers would be shown in the SKALE analytics or any official dashboard

[Ruby_Pyrite]

Hi @TheGreatAxios and team,

It’s really encouraging to see this work being done and progress being made towards long-term network sustainability. Also, great work on the detailed technical implementation, @payvint.

We’ve spent some time discussing this internally and are in agreement that this balances the needs of different stakeholders in the SKALE network. The non-inflationary aspect and maintaining the SaaS model are both good to see. We’re excited about the additional functionality and flexibility for chain owners and the overall ecosystem in these updates, and of course the role that Europa will play.

As dantereminick notes, it would be good to see some mitigation for the possibility of a sudden price jump, like a transition period, or locked-in price for a time. (Pre-payment partially covers this, but an issue might arise if prices rose significantly towards the end of the payment period.)

Also, like delightlabs_io, we’re curious whether there’s a case for a smoother price curve, and what effect this might have on the rate that new nodes are added to the network.

One thing that might help is a series of Alice/Bob-style worked examples, for different circumstances, network load, and so on, just to help ground some of the figures in the “real world”.

Overall, the Ruby team likes this proposal and it looks like the best way forwards. 2024 should be an exciting year for SKALE!

[TheGreatAxios]

Hey @delightlabs_io

Which numbers do you not see in this post/thread?

Thanks!

[TheGreatAxios]

Hey @Ruby_Pyrite

Thanks to you and your team for the time reviewing and leaving some feedback.

Will continue the discussion with @payvint and other parties involved in the technical portion on a possible transitional period and what that could look like from a technical perspective and come back with any updates.

As for the smoother price curve, the impact on nodes coming to the network I don’t think would change. The number of nodes in the network and the desire to create and run more nodes from a validator ideally would be dependent on utilization increase (i.e if utilization approaches 50% and climbs it makes sense for validators to run more nodes to keep the price point in the middle). As for the smoother price curve, that is a goal as part of Phase 3:

Dynamic pricing in Phase 3 represents a significant evolution in SKALE’s economic model. This mechanism leverages advanced smart contracts and market dynamics to dynamically adjust chain prices based on supply and demand of SKALE chain rentals .

However, doing so at an earlier stage could actually have a negative impact as chain owners today would start paying more sooner as the network is still growing while it works toward achieving sustainability. As for the examples, will try and create some that may help illustrate this proposal better.

If no specific alternatives are proposed then it probably makes the most sense to proceed as is with the current proposed values knowing that if things are not working then parameters can be changed through a future proposal and successful vote.

[delightlabs_io]

I mean the live dashboard like SKALE Mainnet Stats

[payvint]

Hi @delightlabs_io

The live dashboard is moving to Dune here: https://dune.com/skale/analytics
Good suggestion!
We would update the dashboard with all of the parameters and numbers!

[TheGreatAxios]

Hey everyone!

Thanks to all for participating here on the forum, those who helped with research, those who helped with design, and in general just those who have supported with their feedback throughout the process.

At this point in time, as there have been no directly proposed changes and we have agreed to come back and continue to iterate on this on a consistent basis as a community to find the; the vote has been opened on Snapshot for delegators and validators of the SKALE Network to vote on.

This officially comes in as the first SKALE Improvement Proposal (e.g. SIP 1) and is available to vote on here: Snapshot

Thank you!

[Anonstake]

Hey SKALE team,

Kudos to @TheGreatAxios, @payvint and the whole team for detailed steps and plan laid for SKALE Chain pricing. We like the presented proposal and think it is well thought out. Phase 1 is ending with success, we are noticing increased activity, with more teams working on SKALE and ecosystem gaining traction. Therefore we encourage the idea of the dynamic pricing model introduced and hope it will work as planned in order to incentivise shareholders of chain for long-term growth.

We are looking forward to see utilization curve versus growth of dapps on network as we proceed to Phase 3. We like the idea of a sliding scale based on network utilization as it adds flexibility and responsiveness to the network. We see that a lot of effort and technical details were considered in the proposal and we appreciate the focus and consideration given to compensating validators for their cost.

We commend SKALE team commitment to decentralized governance, preparing timeline and specifications for each stage and trusting the community with the decision. We hope the team will be open to reconsiderations based on the responses of the community and network evolution once chain pricing goes live. As a validator, we look forward to seing the plan above be put in action, marking the next stage in SKALE’s evolution. Exciting times ahead for SKALE!

[MathiasExorde]

Hey everyone,

Glad to see this important side of SKL token utility moving again. At Exorde we are lucky to have seen the evolution of the SKALE project over the last few years. @TheGreatAxios @payvint

We have been attracted to SKALE due to the chain model, flexibility and control, and gas-less ness, and we continue to do so.

We do now around 350-400k transactions a day, on a very stable basis. We now proudly represent 60%-70% of the transactional load on SKALE right now. We have been collaborating at a very fundamental & technical level with SKALE for a long time and we are pleased with the service.

We’d love to give our feedback on the proposal, and the general question of the SKL/Skale Chain pricing model:

1. The model is great. The $3600/month price per month is reasonable and expected. In our experience, it is in the same order of magnitude as what would be the gas cost of our operations on another L1/L2 platform.

2. Being able to prepay long-term is crucial. Meanwhile being able to accumulate SKL to pay in the future is nice, certainty is a must for a business dealing with lots of uncertainty already. Good that it will be possible as soon as possible.

3. The payments going directly 100% to the validators make complete sense, the infrastructure is key, and I believe this should remain the case forever (for at least 90%).

4. Keep in mind that SKALE chain “users” (like us at Exorde Labs) usually reason in terms of competitiveness and gas cost (w.r.t the competition in the L1/L2 space).

• It makes sense that if networks approach saturation, the incentivization to boot new SKALE chain nodes should increase to bring more “node supply” to the network requiring new chains.
• It makes sense to have an increase of SKALE chain price, but the exponential growth rate of the price could not be the best idea. Maybe imagine an auction system when the network reaches saturation? It would probably capture demand more accurately.
• A temporary sudden $40,000 USD+/months price acts, for us, more like a deterrent. If the monthly cost, during a high utilization period (>60% for example), is high, a new SKALE network client is more incentivized to wait for the price to come down, than pay 10x+ the price of his transactions/protocol on another network, before migrating back. This is a question of balance, and maybe a smoother price curve is to be explored at least initially?

Overall we believe the pricing model to be very good and intuitive, with a note of exception on the pricing model during network saturation: we would expect the network to incentivize new nodes, without deterring new clients that much. Stability is one of the key differentiators of using SKALE and we are glad it’s being considered.

Thanks

[nguy_n_thanh_bao]

i like project SKL, GMGMGMGMGMGMG