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

SKALE is an open source, community driven project with a huge vision to bring the power of Ethereum to hundreds of millions if not billions of people. This is a big, audacious goal that relies very critically on the network’s ability to grow with sound and sustainable economics. This also means that the economic strategy must be strategic and tailored for each phase of network growth. SKALE’s core architecture lends itself to elasticity and flexibility in terms of both capacity and economics. That same powerful feature also brings about complexity which requires input and coordination from many different parties. Thankfully there are many actively involved constituents helping drive this strategy ranging from validators, dapp developers, core devs, delegators, and more. In order to bring about the next phase of economic transformation, we are pushing forward a high level proposal today and look forward to hearing your feedback, thoughts, and input with the goal of implementing chain pricing as soon as possible for the network. If this high level strategy is accepted we will then put forward a very specific proposal including smart contract language that will be voted on and if approved, pushed forward.

SKALE, like every major successful ecosystem within both the Web3 and Web2 landscapes, has prioritized growth and expansion over immediate revenue generation. This strategy is essential for maintaining competitiveness and fostering growth. Loss leader expansion over profit-centric tactics is a common practice across all tech fields and not exclusive to centralized entities. Fully decentralized networks like SKALE can leverage these methods as well, substituting centralized boards and companies with decentralized voting and governance to formulate strategies, then employing smart contracts for their implementation.

Traditional L1 blockchains operating with gas fees function similarly, where inflation subsidizes low gas fees in their network. Numerous high profile L1 networks boasting generating tiny amounts of fees owe their short-term sustainability to this inflationary offset, which allows them to adopt a growth-first/loss leader strategy. They however will eventually hit a crunch requiring them to increase fees or face the reality of running a perpetually subsidized economic model.

SKALE is uniquely positioned NOT to fall into this crunch. A key feature of SKALE Chains is that they don’t impose gas fees on end users. Instead, they are powered by Chain fees which compensate validators and stakers (delegators). Chain fees are supplemented by a descending inflation mechanism for validator rewards. To put it plainly, during the network’s first three years, a significant portion of fees designated for validator/delegator rewards were intended to come from inflation rather than fees. Each year, the inflation rate declines by approximately 10%, remaining static from year 6-12 before dropping again. To ensure the network’s success, fees need to play a crucial role in sustaining the network from years 3-6. By year 7, our aim is to have over 90% of rewards sourced from chain fees instead of inflation.

This inflation trajectory has been hard-coded into the SKL token smart contract from the network launch on October 1, 2020 and can only be modified through a decentralized vote.

Proposal and Stages:

As a reminder, the SKL token is utilized to add security to the network. The staking functionality has been in place since Oct 1, 2020 and ran for two straight months prior to the token being liquid via the Consensus Activate Proof of Use launch. In addition to staking, the SKL token can be used for both voting and chain payments. The early smart contract, design and flow of chain payment logic has been in place on Mainnet since network launch. Due to an overwhelming amount of input from the dapp and validator community there was a decision to push back the implementation with the goal of decreasing friction for dapp onboarding in the first phase of network growth. In addition SKALE decentralized governance was recently launched which now paves the way for the next evolution in SKALE Chain payments. As a part of this effort, the SKALE developer community has segmented the network economic evolution into three distinct phases which are detailed below. A governance proposal is currently being prepared by a cohort of decentralized constituents to pass Phase 2 of SKALE’s Economic Evolution.

Phase 1: Validating Network Viability and Stimulating Developer Demand

We are currently in the last days of Phase 1. In this phase, the bulk of chain fees were paid offchain and supplemented by grants, funneled directly into dapp growth programs, mirroring the AWS growth model. With the current market dynamics and competitive landscape where L1s and L2s provide “gas offset fee” grants to dapps, SKALE has adopted a similar approach in subsidizing chain fees. However, SKALE’s advantage lies in its unit economics for Chain offset fees, which are significantly more efficient than gas offset fees due to the manner in which validators are rewarded and how chain pricing operates compared to gas fee pricing.

This strategy has proven exceptionally fruitful for SKALE, with over 158 million transactions from over 1.4M unique active wallets across 20 active SKALE chains, resulting in more than 1.9B USD in saved gas fees in the last year.

With the network’s viability and value now confirmed, SKALE is poised to transition into the next phase of economic evolution and network growth.

Phase 2: Achieving Economic Viability and Sustainability

Following the commitment made by the core team and community developers not to modify any network economics without an on-chain vote, and with the recent approval of decentralized voting, SKALE is ready to advance into Phase 2.

The ultimate goal in this phase is for SKALE Chain pricing to reach a point of validator hardware profitability while setting a target load price of $1M USD equivalent in SKL tokens paid per year per chain with the network at a 70% load. The design of SKALE Chain price operates on a sliding scale where each additional chain costs more than the previous one when the number of nodes in the network is fixed. This system incentivizes validators and delegators to set up more nodes as the return increases, which will consistently keep the price per chain near the middle load price point.

Phase 2 is dedicated to establishing a financially sustainable foundation for validators, with chain pricing aimed at maintaining growth while ensuring validators can operate healthy businesses. The network utilization curve allows market dynamics to control the pricing of the chain throughout its evolution. Chain pricing will be calculated based upon the amount of chains being rented and the amount of active nodes in the network. Currently, chains will cost 8% of the Target Rate, which is ~$3,600 a month, until the network will hit 45% utilization. At the Target Rate, or 50% Network Utilization, the Network will lease chains at ~$46,000/month which will steadily climb until it hits the Growth Rate at 70% Network Utilization. At 70% Utilization, SKALE chains will cost ~$84,000 a month. As you can see in the chart, once the Network hits 70% Utilization, a steeper price curve is enacted to incentivize validators to run more nodes. This mechanic is used to maintain a healthy supply-demand balance of the chains.

Core aspects of Phase 2 chain pricing include compensating the total hardware costs of running base-level infrastructure. For instance, each SKALE Chain has 16 dedicated subnodes, estimated to cost between $250-$750 per month. Chain fees for the first six months will go entirely to validator operators, extendable with another successful vote.

The goal for SKALE Chain pricing in Phase 2 is to cover the hardware infrastructure costs for the network. Therefore, each chain will fund a smart contract paid in SKL tokens, with the quantity of SKL to be paid each month determined by an oracle input for the price of USDC at a rate of cost determined by the network utilization curve, which will fall in the range of $3,200 to $4,100 in SKL tokens per month and will be finalized by a SKALE DAO vote on Snapshot. This fee is being pushed forward as a temporary phase 2 rate which will help push forward economic sustainability while not inhibiting growth and will ultimately tee up the next phase which is about optimizing value capture with growth.

Moreover, these smart contract payments and token payouts to validators will occur on the SKALE Europa Chain, the primary liquidity hub of the SKALE Network. This will reduce gas fees for network operational costs and generate more economic activity on the Europa Hub.

Assuming the community is excited about this direction and sentiment is positive following this post, the technical OSS community supporting SKALE will publish a technical specification forum post. That will then be followed by a SnapShot proposal which will include code to be voted upon.

Phase 3: Accelerating Network Growth and Value Capture with Dynamic Pricing

Upon achieving a period of network stability and growth, and only with a successful vote, the network will transition into phase 3, focused on augmenting network revenue and value capture. The goal will be to move into this phase in the next 12-18 months.

In Phase 3, advanced dynamic pricing contracts using the network utilization curve will be extended below the 50% threshold, which will enable the network to capture additional value and further incentivize stakers and validator operators. The goal is to enhance the economic sustainability of the network and solidify SKALE’s position as a resilient, scalable and sustainable blockchain ecosystem.

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. This is where SKALE’s elasticity thrives and its limitless supply of SKALE chains, provides an infrastructure that actually allows for mass adoption within blockchain.

Dynamic pricing is not a new concept in the tech field, when you think of Uber surge pricing which incentives more drivers to drive, and gets more cars on the road for riders. However, this is novel to blockchain and is only possible through SKALE’s modular multichain model. This pricing mechanic empowers stakers and validator operators by offering enhanced rewards that align with the network’s growth and usage. As demand for SKALE chains increases, the dynamic pricing algorithm adjusts the SKALE chain price which encourages more Validators to operate nodes and more stakers to foster a healthy ecosystem of active participants. This influx of Validator nodes, allows for more SKALE chains to be rented which continues to drive flywheel until there is a market balance. This structure supports a healthy economic market and allows for developers to continue to grow. The demand will approach the Target Utilization Rate of 50%, and dynamic pricing of the SKALE chains will be enacted.

As the network continues to grow and capture additional value through dynamic pricing, it opens doors to new use cases and expands the SKALE ecosystem. The increased scalability and SKALE’s economic efficiency through pre-purchasing attracts developers and enterprises seeking a blockchain solution that can handle high transaction volumes at the lowest unit cost. This influx of dApps and businesses enriches the ecosystem, fostering innovation, collaboration, and the development of new revenue-generating models.

Throughout Phase 3, community engagement and decentralized governance remain essential pillars of the SKALE Network. The SKALE DAO governance enables stakeholders to actively participate in shaping the network’s economic policies, including the parameters and adjustments related to dynamic pricing. This democratic decision-making process ensures that the network evolves in a manner that aligns with the collective interests and values of the SKALE community.


The steps we are proposing aren’t just about growth and sustainability; they’re about strengthening our decentralized network and preparing SKALE for the long-term future that lies ahead.

The team is keenly aware that such a strategic transition requires the consensus of our community. As we’ve pledged, no changes will be implemented without the democratic decision of an on-chain vote. We genuinely encourage everyone to scrutinize this proposal, ask questions, and engage in the discussion.

In the coming weeks, further interviews with constituents, meetups, and developer/validator chats will take place with the goal of gathering final details so we can fully propose a vote through the SKALE DAO Snapshot. Please stay tuned for this important announcement.

SKALE is a community run, community owned, open source public good. We now have a cutting edge voting system in place. Let’s dig in and work together to make this transition successful and continue building a resilient, scalable, and sustainable network.

Thank you once again for being part of this exciting journey. We’re not just shaping the future of SKALE, but also influencing the future of decentralized technology at large as we push forward newer innovative decentralized business models.

SKALE OSS Dev Contributors

About the SKALE OSS Dev Contributors

We are a committed group of developers that work on numerous parts of the SKALE project. We are a community of developers, core team developers, and other network constituents. Our goal is to push forward to initiatives of the SKALE project in a decentralized and community focused manner.


Axios - Thanks for pulling this together!

I’m fully in favor of this. This plan gives the project an opportunity to get to operational profitability without inflation unlike many other chains while it pushes the next phase of monetization down the road. All major B2B tech platforms and Web2 companies grew in a similar mannner prioritizing growth first, then initiated a transition period, followed last by a focus on monetization. SKALE will do the same but in a value sharing and not valuing extracting manner with monetization being decentralized with onchain profit sharing direct to validators and delegators with a fair price point that can only be moved with governance and transparency.


This is a great proposal and I am excited to see how it positively impacts the SKALE Network. The implementation of SKALE Chain pricing will allow the network to thrive while ushering in a new age for blockchain and distributed compute functionality.

I would love to seek clarity on the potential implications of SKALE Chain price jumps at key network utilization thresholds. Under the current proposal, the jump at 50% & 70% network utilization may challenge existing chain operators. To facilitate continued SKALE chain ownership and overall SKALE network utilization, it may be worth considering a 1-3 month transition period. During this period, projects can adjust their budget, bring in more paying users onto their chain, or migrate to a SKALE hub. Current chain owners could maintain their existing rates, while new operators adopt the updated pricing.

As an ecosystem, we aim for widespread SKALE chain adoption while ensuring overall network stability. A brief price adjustment window would enable a smooth transition for existing operators and provide time for new validators to come online, further adjusting the supply and demand equilibrium. Addressing this should enhance overall ecosystem stability by mitigating the potential impact of abrupt price fluctuations on the entire network. I’m eager to see what the community thinks of this idea.


Hey hey @TheGreatAxios, it is an awesome proposal !

After long-weeks discussion with Core team and SKALE Dev Community, we come up to the detailed plan about technical implementations.


This proposal details a phased approach to rolling out SKALE Chain pricing. The goal will be to start in the fastest and most simple way possible that moves chain payments to an onchain environment. This first phase is titled Minimum Viable Onchain Payments for that reason. Phase 2 will be focused on Automation and additional features. Phase 3 will be focused on advanced features.

Stage 1 - “Minimum Viable On-Chain Payments”

The first implementation is proposed to launch on 1 Jan 2024 after a successful vote

This release would contain:

  • Onchain payment functionality for each SKALE chain
  • Claiming of rewards mechanism for each validator
  • Blacklist functionality with enforcement from a decentralized security committee
    • The decentralized security committee will be composed of 3 core developers, 3 validators, and 3 dApp/ecosystem builders. This is subject to change based on additional community input.
    • Their primary role will be to make judgements on network security and operations decisions as they relate to workflows that require a manual input in phase 1 in lieu of having a fully automated system. These decisions will primarily be related to making judgements about validators or chains that are not meeting requirements or payments.
    • Further details to be provided on how the individuals are selected and what specific authority their collective role will play.
  • Following the network changes on Ethereum functionality
  • Deployment of the set of smart contracts to Europa Hub

Stage 2 - “Automation”

The second implementation is proposed to launch on 1 Jul 2024

  • Automatically update contracts on Europa with changes from SKALE Manager on Ethereum via IMA
    • Nodes addition/removal
    • Schains addition/removal
    • Validators addition/removal
  • Automatically update SKALE Manager contracts on Ethereum with chain payment information via IMA
  • Automatically update SKALE Chain ownership if payment is delayed for more than 3 months
  • Automatically fetch $SKL price via SKALE Connect
  • Add dynamic SKALE Chain pricing that matches the network utilization curve found in the primary proposal
  • Enable anyone to create a new SKALE Chain
  • Blacklist enforcement will continue to be a manual decentralized process involving a decentralized security committee.

Stage 3 - “Advanced Features”

The third stage is proposed to launch on on 1 Jul 2025

  • This phase will include advanced features that automatically manage chain removal from the system while simultaneously protecting the users, assets, and data in chains.
  • Automated SKALE chain deletion flow of tokens releasing via IMA to holders
  • Decentralized SLA to follow the blacklist requirements
  • More features to be added



  • Due dates for all SKALE Chain payments will be the 1st of each month so as to match the other components of the network which are also linked to the first day. These include delegation, node creation (in terms of bounty distribution and delegation), node removal (in terms of bounty distribution and delegation)
  • SKALE Chain payments will occur in $SKL on the SKALE Europa Hub.
  • SKALE Chain payments are at a minimum for the next month.
  • SKALE Chains may be pre-paid in $SKL tokens for up to 12 months. This is a configurable number that may be changed through a separate governance proposal and passing vote according to the network governance specifications.
  • If a SKALE chain owner misses a payment, SKALE chain owner needs to pay for all months not paid in addition to the next month’s regular payment.
  • For the first implementation, $SKL token price can be set by a specific role or the SKALE Multisig.


  • Validators can claim payments after the 1st of each month, once a whole month has been completed. This means first validator payments cannot be claimed until month two (2) of the first implementation going live.
  • Validator payments can be claimed by validator wallets
  • Nodes can be blacklisted in the current month and the reward would be reduced proportionally to the percentage of time node was blacklisted during this month. The remaining tokens will be distributed to whitelisted nodes equally.
  • Blacklist and whitelist can be called by BLACKLIST_ROLE WHITELIST_ROLE, or SKALE Multisig.


  • Data should be initialized once by the SKALE Multisig. This initialization would include validators wallet, SKALE Chain names and amount of nodes.
  • All the changes in the network (node creation/removal, SKALE Chain creation/deletion) can be sent from SKALE Multisig and taking place at the 1 day of next month
  • Contract will be upgradeable by SKALE Multisig.
  • All the management transactions (by SKALE Multisig) will go through IMA.
  • SKALE Chains can be created by the Foundation at any time during the month
  • SKALE Chains should be paid for the next month before the 1st day of next month.

Validator Compliance Requirements

Validators are required to operate at an extremely high level of performance. The following is a list of validator compliance requirements which each validator must follow.

If a validator is not fully compliant according to the list below, the following actions will be taken:

  1. The validator will be notified directly and asked to resolve the issue.
  2. If the validator does not resolve an issue during the next 3 days, nodes which contain the issue would be marked as blacklisted until the issue is resolved.


To run the node three separate services are required:

  1. SKALE Node running independently from other services
  2. SGX wallet
  3. Reliable ETH mainnet node connection

Hardware Requirements

Node machine specification:

  • 8 physical CPU cores.
  • 32GB RAM.
  • 16GB swap.
  • Disk mounted as / - 100GB.
  • Separate disk - 2Tb.

It’s possible to check whether the machine meets the requirements by running skale node checks.

SGX machine specification:

  • 4 physical CPU cores.
  • 16GB RAM.
  • 8GB swap.
  • Disk mounted as / - 100GB.

Operating System (OS)

The only supported operating system is Ubuntu 20.04 (Focal Fossa).

Node Wallet ETH Amount

  • 1.5 ETH for each node wallet - defined and managed by SRW (Self Recharging Wallet - part of skale-manager).
  • Keep SRW balance of validator at minimum as 0.1 ETH

It’s possible to check node wallet balance by running skale wallet info.

Static IP Address

  • Each node should have a static IPv4 address. It’s possible to migrate to the new one, but as for now the procedure may require up to a month to complete.

Node Machine Firewall

  • SKALE node software handles configuration of the firewall. In case some external network configuration is applied, ports 80, 443, 3009, 311, and 10000–18192, and ICMP IPv4 should be left open.

SGX Wallet Allocation

SGX wallet should not be hosted on SKALE node machines due to potential performance degradation.

  • SGX wallet server should be connected to no more than five nodes.

SGX Wallet Machine Network Isolation

  • SGX wallet server ports (1026-1031) should be only accessible from SKALE node machines. Leaving them publicly open may have huge security related implications.

Reliable Ethereum Mainnet Node Connection

The only supported execution client is go-ethereum. For the consensus client, Prysm is recommended. Using external providers like Infura are not recommended at this time.

  • Ethereum mainnet node should be able to operate 1M requests per day at a peak load.

TLS certificates

  • Each node should have public domain available for which there should be SSL certificates issued.

Each SKALE node can be configured to use issued certificates by running skale ssl upload.

The validity of the newly generated certificates can be verified by running skale ssl check.


  • The backup procedure should be performed every day for both SGX wallet and SKALE node.

For the node copying tarball created by skale node backup is enough.

For SGX wallet you can use this guide

General security

Each node operator will consider the following security measures:

  • Node, SGX and ETH client machines cannot be accessed by any third party.
  • SSH keys are stored securely.
  • SGX wallet backup key is stored securely.
  • SGX wallet API can only be accessed from the node machines.
  • Validator key is stored securely. Preferably using ledger or SGX wallet


Each validator should have at least 99% availability on each of the points below:

  • Services on the nodes(docker containers are running properly).
  • SGX wallet connection to each node.
  • Ethereum mainnet node connection to each node.
  • SKALE chains connection on the node(http/https/ws/wss).


SKALE’s Decentralized Security Committee expects from each validator organization:

  • Follow the upgrade rules specified for each validator.

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?


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?


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


1 Like

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.


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.


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.


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.

1 Like

@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
1 Like

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).

1 Like

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.



@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 :slight_smile:

1 Like

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!

1 Like

Hey @delightlabs_io

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


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.

I mean the live dashboard like SKALE Mainnet Stats

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!