Abstract

Our client, a leading hashpower provider in the crypto mining business, sought to tokenize hashpower and offer it to over 2,000,000 customers worldwide

The client requested a comparison between classic cloud mining products and this new concept of a hashrate token. Additionally, they asked us to develop an architecture concept for said token

Market Analysis

The first step was to conduct some market research. We discovered two existing products that were relevant for our case, and we proceeded to analyze them:

• Bitcoin Standard Hashrate Token (BTCST)
• Blockchain Mining Unit (BMN)

We found that neither product was suitable for our client, due to differences in the target group they were designed for, and lack of transparency. Governance principles could also not be clearly identified. Additionally, it was unclear how the client could integrate their own business method of cloud plans into these tokens. Our findings led us to the conclusion that the best solution for our client’s needs is a tailor-made hashrate token.

Business Analysis

For the analysis of the hashrate token concept we worked closely together with the sales department of our client. In workshops we analyzed the structures of existing cloud mining products and the user experience for their entire life cycle.

Usually, a cloud mining plan is structured as follows:
The customer buys a fixed amount of hashpower at a fixed upfront price in form of a plan.

There are two options of carrying  out this  mining plan:

• The plan ends after a fixed time period; the user gets their mining output only afterwards.
• The runtime of the plan is not fixed; the end of the agreement is determined by the natural depreciation of the purchased hashrate.  As the runtime is unknown at the beginning, the maintenance fee cannot be calculated upfront, and therefore, the provider must  deduct a maintenance fee from the user’s daily payouts. Due to the hashrate depreciation, at a certain point the maintenance fee is comparatively  so high that the mining plan is unprofitable and ends automatically.

The profitability of mining, and therefore a mining plan, is determined mainly by these two factors: The price of the mined cryptocurrency and the network hashrate which is directly related Mining Difficulty.

Requirements Engineering

For this phase of the development we added software developers to our project team. We based the architecture of the hashrate token on the following functional requirements:

F1: Tradeability
F2: Ability to offer different batches of tokens
F3: A cost reduction of 25% compared to classic cloud mining plans
F4: The mapping of business logic of cloud mining contracts to smart contracts

Apart from the functional requirements, some non-functional ones were defined as well:

N1: Scalability
N2: Sustainability
N3: Deeply tested platform
N4: Low cost of issuing of the token

Infrastructure

A major challenge was the fact that smart contracts do not work on the Bitcoin blockchain, and it was not possible to create a token on the Bitcoin blockchain. However, our client required a solution where the token represented Bitcoin hashpower and the token holder would receive their rewards in Bitcoin.
Following this, we looked at blockchains that did allow smart contracts. The token itself does not produce hashrate which is used for Bitcoin mining, but in fact represents the hashpower produced by the corresponding ASIC miners. The distribution of BTC mining rewards must occur on the Bitcoin blockchain via a payout middleware. Therefore, the token (smart contract) could only represent the hashpower, which was actually mining Bitcoin.

Based on the requirements defined upfront, there were two possible ways to go. One possibility was to use the Flow Blockchain, which became very popular with the introduction of NFTs. The other choice was the classical Ethereum Blockchain, which is well-known in the crypto ecosystem. The first step in choosing the right platform was to evaluate both technologies.

The following table shows the differences between the Flow and the Ethereum Blockchain, on which the decision process for the infrastructure was based on: (PixelPlex, n.d.)

Table 1: Comparison of Ethereum and Flow

While Ethereum currently remains the standard blockchain for developing smart contracts, Flow was developed specifically for the needs of NFTs. Due to the broad number of use cases and the resulting popularity and “crowdedness”, the Ethereum system can become cumbersome and expensive.

Flow is a Proof-of-Stake (PoS) Blockchain and relies on a network of validators that can take on four different roles (Consensus Nodes, Verification Nodes, Execution Nodes, Collection Nodes). (Flow Primer, n.d.) The Flow Blockchain, compared to Ethereum, is a new system, so we cannot assume this technology will stay the way it is now.

Both systems have clear advantages which are useful for the token creation process. As the business logic of cloud mining plans is not complex (Cf. Fig. 1), it is possible to represent them in both Blockchains. In the end, the decision was made in favour of the Ethereum Blockchain. The reasons for this are the use of Solidity as a programming language, which is the de-facto standard for coding of smart contracts nowadays. The other reason is the broad acceptance of the Ethereum Blockchain within the crypto ecosystem as a standard platform for smart contracts. Additionally, the Ethereum ecosystem has a well-defined set of possible token standards, which can be used in the implementation of the hashrate token.

Token standard

Choosing the infrastructure also determined the token standard. The following table shows the different token standards that were taken into consideration:

Table 2: Comparison of Token Standards

Our team worked hand-in-hand with the client and came to the conclusion that ERC-20 was not the best standard that fit our goals. The ERC-20 token does not have a proof-of-ownership mechanism, and without that, the central purpose of a hashrate token could not be fulfilled. While ERC-721 fulfilled most of the requirements, at the end, we decided to base the architecture concepts on the ERC-1155 standard, because it allows creating multiple batches of tokens without requiring a new smart contract every time. Furthermore, the client and developers had the freedom to choose the fungibility suitable for the token. Additionally, the ERC-1155 requires less storage space in the network, which reduces the costs of issuing and transferring the hashrate token. This feature makes this product more appealing to possible customers and stakeholders.

Our client requested additional features such as a burning mechanism and a payout engine. The burning mechanism is responsible for ending a cloud mining plan. The event of a so-called “Token Burning” is monitored by a dedicated Ethereum Node which then triggers the Bitcoin payout process.

Throughout this process we worked closely with our client’s IT team and their sales department to ensure that we offer concepts based on our client’s expectations.
At the end, we were able to deliver three different concepts, and all of them met the client’s criteria and goals.

At the end of this process the following ERC-1155 based architecture was developed:

Fig. 2: Flow Diagram of the Hashrate Token

Our team worked hand-in-hand with the client and came to the conclusion that ERC-20 was not the best standard that fit our goals. The ERC-20 token does not have a proof-of-ownership mechanism, and without that, the central purpose of a hashrate token could not be fulfilled. While ERC-721 fulfilled most of the requirements, at the end, we decided to base the architecture concepts on the ERC-1155 standard, because it allows creating multiple batches of tokens without requiring a new smart contract every time. Furthermore, the client and developers had the freedom to choose the fungibility suitable for the token. Additionally, the ERC-1155 requires less storage space in the network, which reduces the costs of issuing and transferring the hashrate token. This feature makes this product more appealing to possible customers and stakeholders.

Our client requested additional features such as a burning mechanism and a payout engine. The burning mechanism is responsible for ending a cloud mining plan. The event of a so-called “Token Burning” is monitored by a dedicated Ethereum Node which then triggers the Bitcoin payout process.

Throughout this process we worked closely with our client’s IT team and their sales department to ensure that we offer concepts based on our client’s expectations.
At the end, we were able to deliver three different concepts, and all of them met the client’s criteria and goals.

At the end of this process the following ERC-1155 based architecture was developed:

Conclusion

Our evaluation provided the foundation for developing a hashrate token which was later published on the Ethereum Blockchain. This approach was built for Bitcoin, which is a Blockchain based on Proof-of-Work consensus. There is a possibility to extend the use case of a tokenwatched like this, and to also develop it for other blockchains that use different consensus mechanisms.

Authors: Christopher Becker, Raoul Anderson
Editorial: Mia Molnar, Thomas Liebberger, Anna Lauterjung

Bibliography

Entriken, W., Shirley, D., Evans, J., & Sachs, N. (2018, January). EIP-721: ERC-721 Non-Fungible Token Standard. Ethereum Improvement Proposals. Retrieved August 3rd, 2021, from https://eips.ethereum.org/EIPS/eip-721

Flow Primer. (n.d.). Multi-Node Architecture. Multi-Node Architecture. https://www.onflow.org/primer#primer-multinode

PixelPlex. (n.d.). Flow vs Ethereum. Which is Best for NFT Development? Flow vs Ethereum: the Ultimate Comparison of Blockchains and Their Programming Languages. Retrieved August 3rd, 2021, from https://pixelplex.io/blog/flow-vs-ethereum-comparison-best-platforms-for-nft/

Radomski, W., Cooke, A., Castonguay, P., Therien, J., Binet, E., & Sandfort, R. (2018, June). EIP-1155: ERC-1155 Multi Token Standard. Ethereum Improvement Proposals. Retrieved August 3rd, 2021, from https://eips.ethereum.org/EIPS/eip-1155

Srivastava, R. (2021, April 4th). Token Standards: ERC20 vs ERC721 vs ERC1155. Token Standards: ERC20 vs ERC721 vs ERC1155. Retrieved August 3rd, 2021, from https://medium.com/coinmonks/token-standards-erc20-vserc721-vs-erc1155-3106f1e3f2f3

Vogelsteller, F., & Buterin, V. (2016, November 20th). EIP-20: ERC-20 Token Standard. Ethereum Improvement Proposals. Retrieved August 3rd, 2021, from https://eips.ethereum.org/EIPS/eip-20