[Research] Cloud Credits for Restaking
Introduction
The intent of this article is to initiate a dialogue around the application of Cloud Credits and the BSN token within the Blockswap Cloud ecosystem. This is in response to inquiries raised by the community regarding tokenomics. It aims to spark and facilitate discussions about the facets of Cloud Credits. It is essential to include the BSN token-holding community as they will be directly affected by the implementation in Blockswap Cloud.
Here is some insight regarding the source and nature of the information provided. I am a member of Blockswap Labs and am involved in the ongoing development of Blockswap Cloud, a restaking protocol. The thoughts and ideas I offer in this article are based on my discussions with Blockswap Cloud’s engineering team, analysis of various white papers, conversations with people, and research into restaking mechanisms. However, it’s critical to understand that these are high-level ideas. These thoughts might never actualize or may transpire differently than hypothesized. It is also worth noting that while I strive to provide the most accurate and insightful information, my views should not be seen as an official position or representation of Blockswap Labs.
This post is meant for discussion purposes and to encourage community involvement.
Everything in this report is subject to change.
Blockswap Cloud
Blockswap is implementing two different restaking protocols. The first is K2, which provides economic restaking; It relies on the cryptographic guarantees provided by kETH, and is a subsect of Blockswap Cloud. The second, Blockswap Cloud, makes the Ethereum consensus layer composable and reusable to middleware. The focus here will be on the latter, Blockswap Cloud. It is a more robust product and ecosystem, accessing Cloud as a Validator, Middleware, Reporter, or DAO member should be thoroughly discussed.
This research post will not go into detail about Blockswap Cloud or K2. To learn more about them please visit the resources below.
- Two types of restaking article
- Blockswap Cloud at EthCC
- K2 at EthCC
- Blockswap Cloud technical walkthrough
The BSN Token
Blockswap has always maintained a community-led ethos; The majority of BSN tokens reside with the DAO. Up until now, BSN token distribution has been limited to contributors directly impacting Blockswap protocol adoption, through cBSN conversion, investor contributions, and community integration initiatives.
Cloud Credits
Currently, the primary utility of BSN is to enable governance over the Blockswap DAO. Although this is enough for many, it seems prudent to incorporate the BSN token into a product that utilizes so much of Blockswap’s tech stack like Blockswap Cloud. The idea is to provide a conduit for BSN tokens to be converted into Cloud Credits, which would result in accessing revenue or services. Some potential uses of Cloud Credits include:
- Middleware access to the validator marketplace.
- Cloud DAO access to fees generated by the Cloud.
- Access to a Grant Council for investing in projects building on Blockswap Cloud.
Figure A shows Cloud participants, their responsibilities, and their relation to BSN.
Valuing Cloud Credits
Blockswap is an entire ecosystem based around extending the benefits of Ethereum to ETH based middleware and into other ecosystems. Therefore, if the idea is to extend Ethereum settlement security then Ether should be considered when discussing Cloud Credits.
Cloud Credits will become the designated unit metric for Blockswap Cloud services, indexed to ETH denomination, and mintable when burning BSN tokens. The pricing mechanism for Cloud Credits is structured around a bonding curve, with a base price anchored to ETH. This price dynamically scales in accordance with the increasing demand for minting. Users are required to burn BSN tokens equivalent to the prevailing ETH rate, reconciled in ETH:BSN:USD for deriving the number of BSN tokens required for burning. This mechanism ensures a balanced, demand-responsive pricing model for Cloud Credit acquisition resulting in BSN deflation.
Figure B demonstrates the relationship between normal demand and high-demand environments for Cloud Credits.
Using Cloud Credits and BSN
Middleware
Similar to AWS, the middleware will only spend Cloud Credits based on usage. Different services and validators will have different prices and Cloud Credits will need to be utilized to access them. Additionally, Middleware will also be required to provide payment for the services they are accessing. There will likely be a ratio between the USD value of the ERC20 tokens they are paying and the Cloud Credit. In this circumstance, once a cloud credit is used, it is burned. Nobody actually receives the Cloud Credit and it is used only for access to the marketplace.
Any usage of Cloud Credits will be via predetermined Staked Lease Agreements (SLAs). Although SLAs can be customized, there will only be supported agreements that have predetermined parameters available. The cost will need to be calculated and not packaged as there are a few different factors that determine the cost of hiring the validators.
- Duration required - Longer would mean higher costs
- Number of validators - The number of validators would play a large role in pricing
- Type of SLA and what is required of the validator - Not all SLA contracts are equal as they each will have different requirements for the validator
- Amount of slashable security per validator - This is looking at the maximum penalty that can be incurred to an individual validator
- Validator Scoring - Validators will be rated based on their historical validation performance as an Ethereum validator. The better the validator performs for Ethereum the higher pay they can receive
Cloud DAO Council
Cloud Credits follow a standard cycle (initially annual epochs, and in the future monthly epochs) and retain their validity only for the remaining duration of the active cycle in which they are minted. This encourages those who are part of the DAO to find and generate demand for middleware built on Cloud DAO. The Cloud DAO will receive a portion of slashing and middleware payments proportional to their share of credits.
Cloud Credits will be liquid meaning that they can be mined early in the year and subsequently sold. This encourages early adoption. As soon as the term expires they will be rendered useless in the Cloud ecosystem. There will be a completely new market surrounding access to Blockswap Cloud.
For instance, if Cloud Credits are minted during the 11th month of an annual cycle, their validity will extend only for the remaining portion of that cycle, necessitating a top-up for continued involvement. If Bob were to purchase 1 Cloud Credit in the 11th month and use it in the Cloud DAO where there are only 3 other Cloud Credits, Bob will receive 25% of all slashing and fees for 1 month.
This method of pro rata ownership of fees will find a balance between revenue for the Cloud DAO members of risk and reward. Those who decide to join the DAO will be those who are able to bring in SLA agreements with the more revenue they are generating resulting in a higher % of fees.
There should also be a portion of the middleware slashing and fees that are paid out directly to the DAO treasury. A subsect of these fees should then be attributed to Cloud DAO.
Grant Council
The Grant Council is a catalyst to bootstrap a value-aligned ecosystem by offering incentivizes to them by middlewares. In exchange, they gain early stakeholders who shepherd the product growth and offer cloud-related expenses also promote broader adoption.n. The Grant Council will offer both Cloud Credits and kETH in exchange for a portion of the project’s native tokens. Cloud Credits can then be used by the middleware to access the validator marketplace. They can also be used to access support from the Grant Council to incubate their projects. The kETH they receive will be liquid and made available for them to spend on operations outside of Cloud.
Reporter
Reporters ensure that validators are upholding their SLA agreement. To avoid any principle agent problem it is important that they have skin in the game. The difference here is that they only have something to gain when others misbehave. Therefore, it is difficult for them to be asked to burn BSN tokens as their revenue is sporadic and dependent on the system not working as intended. There is no limit to the number of reporters who could sign up.
Figure C provides a more detailed view of the proposed BSN token flow.
Conclusion
This exploration into Cloud Credits and the utilization of BSN tokens in Cloud is intended to spark feedback from the community. The system’s potential scope is broad, encompassing aspects such as Middleware, Cloud DAO, and a Grant Council, and Reporters. As with any idea, there are many factors to consider, and a well-rounded, community-driven discussion will ensure the best possible outcomes for all stakeholders involved.