[SIP-2]: Chain Pricing Addendum

SIP-2: SKALE Chain Pricing Addendum

Background

SKALE is an open source, community driven project with the goal of bringing the power of Ethereum to hundreds of millions, if not billions of people. This is a lofty goal that relies on the network’s ability to grow with sustainable economics. Over the last four (4) years, the SKALE Network has gone through a Mainnet launch, multiple mainnet upgrades with significant performance improvements and feature enhancements, and most importantly has become a home for hundreds of projects deployed and actively building on SKALE. In addition, SKALE Chain pricing which went into effect on January 1st of last year [2024]. SIP-1, the initiation of SKALE Chain Pricing, has been an overwhelming success bringing greater stability to the validators and greater sustainability to the long term network trajectory.

The Hub Model

As the network continues to grow with more going live every month, and more businesses choosing to build daily it’s important to recognize that part of this surge in growth is thanks to the SKALE Hub model. The Hub model enables any SKALE Chain to be used by more than just a single dApp. Hubs may be owned and operated by a single entity or DAO who then manages the other businesses and projects building OR it can be shared ownership by many companies or DAOs working together. A critical benefit of the hub model is that the price per dApp can be drastically reduced since the dApps on the chain can either split the compute equally or hubs can choose unique pricing models to fit their usage. The only requirement for hubs is that they adhere to the SKALE Network Pricing Model set by the SKALE DAO.

The idea of hub chains was born thanks to a combination of:

  • The current default SKAKLE Chain offers far more compute than individual projects need AND is far more powerful than the average Layer 1 or Layer 2 blockchain
  • Appchains do not cultivate community, hubs do! Hubs are also key for community growth and broader network interoperability
  • SKALE V2 [which went live in June of 2022] – enabled SKALE Chain to SKALE Chain communication allowing for bridging and connectivity between hub chains and app chains.

The SKALE Hubs – Calypso, Europa, Nebula, and Titan – now account for over 90% of the applications live on SKALE and ~62% of the compute (calculated by transactions over the last 30 days).

The community believes that the hubs will continue to grow in use and due to the want to work with the operators and the validators to continue to move closer to what is believed to be the true value of the decentralized block space and security available from these powerful SKALE Chains.

Proposal

As a reminder from prior forum posts and governance votes regarding SKALE Chain pricing, we are in the midst of transitioning from a loss leader model where chains are priced intentionally low in order to gain market share, to a net/neutral profitability model where the network pays for itself and becomes revenue positive (where we are now), to revenue value capture stage where revenue is optimized to increase value capture of the token economics. This value capture stage will optimize both for revenue in, but also network growth, which means pricing will still be fair and cost-effective to developers while also creating positive economics to token holders. Web3 models are not meant to be value extractive like Web2 models, but still need to produce economic value capture.

This proposal aims to take one more interim step forward in the process and raise the price of the current default SKALE Chain – which is called a Medium SKALE Chain and consumes ⅛ the resources of a SKALE Validator Supernode – from $3,600 per month in SKL to $7,200 per month, paid in SKL tokens.

This raise is still significantly lower than the 50% utilization rate of $46,000 per month in SKL, however is large enough to ensure that validators see their revenue double while also ensuring the value of a SKALE Chain is competitively priced with the recent and upcoming performance improvements being shared by the SKALE Network developers.

Technical Notes

  • All changes proposed above would occur on the SKALE Europa Hub
  • The changes would occur as a transaction within the existing Paymaster contracts
  • The changes would raise the cost of rent – unpaid and future SKALE Chain fees – to the cost of $7,200 in SKL per month
  • Existing chain owners will have the ability to pay in at the $3,600 price up to 24 months from the current month with the change in price date being April 1, 2025
  • Existing chains who have pre-paid at the current price are not required to pay in additional rent

Timeline

  • After sufficient community discussion targeted at ~7 days, the proposal will be put up for vote on the SKALE DAO
  • Upon approval, the proposed timeline would be to have this applied to the Mainnet Pricing system on April 1, 2025, marking March 31, 2025 as the last month to pay in at the $3,600 rate.
  • Starting April 1, 2025 all payments therein would be at the amount agreed upon by the community before the final vote; which is targeted at $7,200.

Summary

The changes being proposed are to ensure that the network continues to move toward a more sustainable future that works to ensure all existing constituents are in a position to succeed.

As per the governance rules of the SKALE Network, no changes will be implemented without the democratic decision of a SKALE DAO vote. We encourage everyone to scrutinize this proposal, ask questions, and engage in the discussion.

SKALE is a community run, community owned, open source public good. 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.

Sincerely,
TheGreatAxios

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.

4 Likes

For my point of view it’s fair. Validators win and devs still get value. Hubs keep it affordable. Voting yes its an option but for me is the only option.

1 Like

Fantastic feedback – thank you!
After talking with the developers and validators this seemed to be a happy-medium step in the right direction for everyone.

1 Like

This proposal seems like a positive step for validators, offering improved revenue stability. It’s still progressive for Appchains too, as the hub model keeps costs reasonable within the utilization rate. Looking forward to seeing how it plays out.

1 Like

Exciting to see the evolution towards increased network value and sustainable economics. As a validator, we’re happy to support these changes and will vote yes on the proposal.

2 Likes

Great work on putting this together!

I have two questions in regards to these changes:

  1. Impact on smaller chain owners: Doubling the price could disproportionately affect smaller chain owners who can’t spread costs across many dApps like the large Hubs can. This might push more centralization toward only a few major Hubs.
  2. Need for more granular options: Since “the current default SKALE Chain offers far more compute than individual projects need,” could we introduce smaller chain sizes with lower costs? This would give chain owners more flexibility to pay for what they actually need.

Both changes would help maintain ecosystem diversity while still improving validator economics.*

  • I’m not great at business or economics
1 Like

Thanks for your feedback @Edouard_Stakin ! Fully agree here – when in discussion with the active developer community we’ve been keeping an eye on utilization as a key metric to track!

1 Like

Appreciate the support @Anonstake !

Hey @nftpixels

Appreciate you taking the time to read through and ask some great questions! The following are my opinions and I would recommend both hub operators, appchain owners, and individual developers to leave theirs as well!

  1. Impact on smaller chain owners: You are absolutely correct on this. Those who cannot afford to “pay rent” would need to migrate to a shared chain. This should not be seen as negative but a step toward the full potential of the pricing model where the revenue per chain is closer to ~$500,000 per year which falls inline with the compute availability of these chains.

Additionally, if a project cannot afford this small I along with the SKALE team can work with them to help with the migration process. We have already had a couple of AppChains begin the migration to hubs (e.g Razor → Europa) and I imagine we will see more in the coming months.

  1. Need for more granular options: I fully agree on this and the answer is yes. Even more exciting, it’s actually built into the design of SKALE Manager (i.e the brain of SKALE). I would recommend checking out this forum thread which explores some of these ideas.

A current downside of smaller SKALE Chain sizes is that it costs the same amount of gas to do network operations regardless of the chain size, however, I am actively exploring ways to mitigate this.

Please let me know if any further questions!

Thanks

The proposal appears fair and reflects an incremental increase based on the provided metrics. We also firmly believe that a network must be self-sustaining to ensure economic feasibility and long-term viability.

One idea, not directly tied to the proposal but still relevant to economic feasibility, is the introduction of a burning mechanism. This could enhance the network’s intrinsic value and offset inflation, at least a portion of it.

Hey @ChainodeTech

Thanks so much for your feedback!

I think a burning mechanism is a really interesting piece that could potentially be put into play regarding the economics of any network. I think in this case, I would not recommend it be added to SIP-2 and should instead be exploring in a subsequent improvement proposal and discussion thread to narrow down with the broader community the why, how, impact, and sentiment of such a change. Additionally, this will allow the community to move forward with a vote in the next 24-48 hours on SIP-2 and hopefully have this live on April 1 as proposed.

Some initial thoughts just so they are recorded for everyone and can be carried over into a further discussion and SIP:

  1. A burning mechanism directly related to chain pricing would probably be the simplest way to implement this into the economics since a portion of all payments could be separated out.
  2. There are potential alternative uses that could be done instead of burning. For example, a portion of tokens paid into chain pricing could be put into a separate bucket to help pay for operations (e.g node rotations).
  3. I think it’s worth a discussion of whether the network is attempting to become deflationary or just reduce inflation a bit [which happens by design from the inflation curve].
  4. It’s worth noting that at some point in the future, SKALE Chain Payments will also need to be split off into the bounty pool to help incentivize delegators. With SKALE being Delegated Proof of Stake, ensuring that both delegators and validators are receiving sufficient value for providing security in the form of stake is critical. With inflation continuing to decrease, both validators and delegators will continue to receive fewer tokens per month [which is not a bad thing].

A note on point 1, this would require additional custom work/manual interaction at this time since the payments occur on SKALE Europa and a token [like SKL] which is bridged in from Ethereum that is burned on a SKALE Chain is still technically liquid on the Ethereum side

Overall, I definitely think this is worth a deeper discussion. I would love to collaborate further with your team and the broader community of validators, dApps, and SKL token holders!

Thanks to everyone for your amazing feedback and support.
SIP-2 has officially been put up for vote in the SKALE DAO: https://snapshot.box/#/s:skale.eth/proposal/0x8284faff270c62ee0300f75ef73d6ead72b64deefa743069644a612628f72259

1 Like