This document is in draft status, and is intended to be an easier to understand version of the Whitepaper. There are some design differences between the two papers. We believe that these are improvements. However, if you are a DAO member (DHX Holder) feel free to provide feedback to this shortpaper in the form of a pull request.
- Equation formatting is a mess --- can use some assistance cleaning it up.
- Equations are being duplicated for unknown reasons
- Unable to add stylesheets for equations as outlined in https://docusaurus.io/docs/markdown-features/math-equations
- We need to better outline advocacy and developer mining as well as signalling.
- Proposal for secure hardware to receive its own MB.
To be clear -- this document is incomplete, and requires additional work.
DataHighway is a blockchain solution with the purpose of managing and trading data for AI and scientific purposes. As such, it provides a multi-faceted opportunity for AI developers, scientific researchers, data miners, and blockchain enthusiasts. Naturally, these groups can also overlap, providing multiple opportunities for individuals to participate in the DataHighway.
Blockchain enthusiasts can participate in the DataHighway blockchain through a concept called “mining”. DataHighway block confirmation is done through Nominated Proof-of-Stake (NPoS), however there are additional ways to earn the DataHighway token (DHX). DataHighway uses Proof-of-Participation (PoP) to provide DHX rewards to participants completing specific actions to support the DataHighway. These actions include promoting the DataHighway, connecting hardware with the DataHighway, and bonding DHX or other tokens supported by the DataHighway.
Blockchain enthusiasts can further participate in the governance of the DataHighway blockchain. DataHighway is a Decentralized Autonomous Organization (DAO), making it an organization run by the community holding the DHX token. Token holders can create referendums on the network outlining steps the DAO should take, such as items that should be developed or token allocations for specific marketing activities. These referendums will be voted on by the DataHighway community using the DHX token. It is by using this method that we ensure that those invested in the DataHighway will determine the future of the blockchain.
DataHighway integrates with MXC Supernodes to provide an end-to-end network of hardware devices that collect data and share it with a digital marketplace for purchase. At the core of this network is blockchain integration, so developers can be certain that the data they are purchasing is accurate and reliable.
DataHighway makes real-world data mining easier than ever before. By integrating with the MXC Supernode network, DataHighway data miners have access to a global, low power, wireless network. DataHighway enhances this network by making it possible for data miners to connect their sensors to the network directly, without purchasing the additional hardware commonly needed to create a network for data collection. Sensors using the DataHighway solution, will be able to travel between network providers without any additional configuration.
Mining the DHX tokens can be done through a traditional mining approach by hosting a validator, becoming a nominator, or by interacting with and supporting the DataHighway. Traditional mining is done through block generation and confirmation by hosting a nominator or network validator. DataHighway adds additional mining opportunities using Proof-of-Participation (PoP).
By implementing PoP, DataHighway rewards participants for supporting the DataHighway blockchain. Each day 5000 DHX is generated and distributed among mining participants. A twenty-percent (20%) proportion of this 5000 DHX is allocated to validators and nominators. The remaining tokens are provided to the treasury to be distributed to the remaining miners through PoP. This distribution is determined by each participant’s Mining Power (mPower).
All newly minted DHX has a cooling-off period of 7 days. During this time it will not be possible to bond, restake, withdraw or sell this DHX.
Validators are the block builders of the DataHighway and are rewarded with 20 percent of all generated DHX.
Validator trust is established using a Nominated Proof-of-Stake (NPoS) model. Any person holding DHX is encouraged to act as a nominator by bonding DHX to validators they trust. Validators that are elected into the active validator set share a portion of the staking rewards. The validator owner decides what commission rate percentage they want to take as income and the remaining percentage is shared with their nominators.
Nominating a validator also holds a level of risk. If the validator behaves poorly, nominators and the validator will either have a portion of the bond slashed, or a portion of their potential rewards.
If a nominator chooses to unbond their token, there is a cooldown period of 7 days. During this period they will not receive any staking rewards from bonding with validators and they will not be able to transfer their token.
|Year||Revenue (DHX) \ Per Validator \ Per Year \ (Excluding MSB & MLB)||Max. Revenue (DHX) \ Per Validator Per Year (Including Max MSB of 60% & Max MLB of 20%||Cost (DHX)|
Per Validator Per Year (Excluding MSB & MLB)
Per Validator Per Year (Excluding MSB & MLB)
|ROI \ (Profit Factor) \ \ Per Validator Per Year|
(Including MSB & MLB)
|2020 - 2023||1752||2803.2||120||14.6||23.36|
|2028 - 2031||438||700.8||120||3.65||5.84|
###Proof of Participation
Mining DHX through Proof of Participation requires you to take an active role in DHX governance. To accomplish this, in order to mine DHX, you must first have DHX bonded to a governance council member. This bonded DHX functions as the “limiter” to your mining potential. In order to mine 1 DHX in one day, you need to have both enough mPower and 10 DHX bonded. The bonded DHX must also go through a 7 day cooling-off period. This means that to mine 1 DHX per day for a week, you would need to have 70 DHX bonded.
Equation 1: Bonding requirement to eligible to mine DHX
mPower is used to determine how mining rewards are distributed. By participating in different actions, you gain mPower. Your total resulting mPower is generally determined by combining two variables. These include:
Mining Base (MB) Mining Speed Bonus (MSB)
Your mPower is equal to:
Equation 2: mPower Equation
MB is the base mining amount and only applies to token mining (i.e. mining DHX by locking other tokens). The MB may vary depending on both the token and it’s value in relation to DHX.
Each category of mining has its own role to play on the DHX blockchain. Tokens can be voted into different categories through governance. Each category of mining has a different “category multiplier” (CM), determining how much mPower you will get based on the amount of token you have locked.
|Category 1 (DHX, MXC)||1.0||MB = sumToken * M|
|Category 2 (E.IOTA, DOT)||0.2||MB = sumToken * M * min(dhxExchangeRate, 1)|
|Category 3 (H.BTC, Filecoin, OKB)||0.1|
The DHX exchange rate will initially be determined using the API provided by CoinGecko. Following this, DHX will use a series of Oracles to individually confirm the exchange rate.
E.IOTA is a pegged Ethereum ERC-20 IOTA token. In order to participate with IOTA, a user will signal their IOTA holdings using their IOTA wallet. E.IOTA will then be assigned to the user for their use in DHX mining until the original IOTA wallet balance changes.
H.BTC is Huobi BTC, and functions much in the same way as E.IOTA.
This is a proposal to directly apply MB to SHM, in contrast to only providing a MSB
SHM is an essential part of building the DataHighway, and therefore receives its own MB. The MB per SHM device is unique to that device, and is determined through governance. Once a SHM device is accepted, the MB additional provided by this device will not change unless it no longer meets one of the following requirements:
- Receives regular security updates (defined as quarterly updates)
A MSB applies to both ICBAM* (token mining) and Non-ICBAM** (e.g. hardware, development, advocacy and governance mining).
MSB is calculated by summing the Mining Duration Bonus (MDB), and the Mining Diversity Threshold (MDT):
Equation 3: Calculating Mining Speed Boost (MSB)
The MDT functions as an incentive for miners to diversify their mining by adding a PoP Non-ICBAM mining method, such as becoming a validator or nominator.
It applies a Mining Diversity Threshold Limit (MDTL) on the MSB unless PoP ICBAM (token) miners diversify and simultaneously participate in PoP Non-ICBAM (e.g. hardware, development, advocacy, or governance) mining to at least a Mining Diversity Threshold Qualifying Extent (MDTQE) of diversification that is measured by their Non-ICBAM MSB.
For example, if the MDTL is configured as 1.1 and the MDTQE is 1.25, then the miner should be encouraged to try to achieve a Non-ICBAM MSB of at least 1.25 by perhaps participating in hardware mining, instead of just participating in ICBAM (token) mining, otherwise their ICBAM (token) mining MSB will be limited to a maximum of 1.1.
The duration of the ICBAM (token mining), which is referred to as DHX Mining in the DataDash app, also plays a role in how MSB is calculated. Longer lock durations contribute to the overall stability of the DHX token value and are therefore rewarded by the network. The original MSB is then multiplied by the MDB’s duration bonus multiplier (the associated percentage is referred to as the “boost” in the DataDash app). You can view the duration bonus multiplier for A (DHX Mining) in the table below. The boost percentage for Categories 2 and Category 3 are calculated as follows, where C is the other category number.
Equation 4: Calculating the Mining Duration Bonus (MDB) for a Token Category
|Token Category||3 months||9 months||12 months||24 months|
|Category 1||1.00 (0% boost)||1.10 (10%)||1.20 (20%)||1.40 (40%)|
|Category 2||1.00 (0% boost)||1.02 (2%)||1.04 (4%)||1.08 (8%)|
|Category 3||1.00 (0% boost)||1.01 (1%)||1.02 (2%)||1.04 (4%)|
Table 4: Calculating ICBAM Mining Duration Bonus (MDB) using Token Category and Lock Duration
Equation 5: Calculating the total Mining Duration Bonus (MDB)
The MDB is the sum of:
- A: ICBAM (token mining) MDB, which is DHX Mining, with a maximum value of 0.4 (e.g. 40%, which is shown as 1.4 in Table 4), and;
- B: Non-ICBAM MDB also with a maximum value of 0.4. This excludes hardware mining since that is covered separately by MHB.
Different hardware (HW) devices connected with the network have a MHB specific to the category of hardware connected.
If you have a MHB, then this would add a boost to your total mPower, applied to the total mPower including all other bonuses. For example, if you have a Category 1 piece of hardware, the bonus would be applied as:
Equation 6: Calculating the Mining Hardware Bonus (MHB)
Each mPower unit can be boosted only by 1 HW device, e.g. if we have 200k mPower from our Category 1 tokens and two Category 1 HW devices then the total mPower will equal 400k (since a MF of 2 is applied from Table 5), as only the 1st HW device may be boosted ***.
|Hardware Category||Mining Factor (MF)||Max amount of mPower that can apply per gateway (maxA)|
|Category 1||2||1 millionmin(dhxExchangeRate, 1)|
|Category 2||1.5||500,000min(dhxExchangeRate, 1)|
|Category 3||1.25||250,000 min(dhxExchangeRate, 1)|
Table 5: Calculating Mining Hardware Bonus (MHB) using Hardware Category
Equation formatting is wrong
This section needs work.
Token Miners that wish to only signal (rather than locking) attract 10% of the lowest boost percentage associated with a MDB duration bonus multiplier.
e.g. if a user locked Category 1 tokens for 12 months then the MDB’s duration bonus multiplier from Table 4 would be 1.2 (20% boost), however if they chose to signal them instead then only 10% of that multiplier would apply, so they would get 1.02 (2% boost) instead.
This section needs work.
Incubate runtime and decentralised App (dApp) development on DataHighway through DHX funding (e.g. dApps, bounties).
This section needs work.
DataHighway shall function autonomously as a Decentralized Autonomous Organization (DAO). Each organizational decision for the DataHighway will be made by the individuals participating in the network. In this way a business or development referendum can be made that is then voted on by the community using DHX tokens. When a referendum is approved, the proposed bounty for that action can then be claimed by the individual or organization that completes that task that is then accepted by the community. In this way, the community not only decides how DataHighway will function, it also has further opportunities to earn DHX.
Naturally to stimulate the promotion and development of the DataHighway, 30% of the total genesis DHX supply has been assigned as unlocked reserves in the DHX Treasury.
The initial economic variables shown in the table below were decided upon through optioneering and may be further configured. The DHX DAO may elect to make a protocol change these economic variables.
|Genesis Total Supply (Monetary Base)||100,000,000|
|Genesis DHX DAO Treasury Unlocked Reserves||30,000,000|
|Remaining Genesis Supply||70,000,000|
|Genesis Estimated Staking Participation Validator Size||100|
|Exchange Rate (USD per DHX) Assumption||1|
|Block Production / Mining Time (estimated block time 9 seconds)||4.32|
|Initial Block Reward||0.250000000000|
|Block Reward Validator Fees (percent of Annual Supply)||20%|
|Block Reward Treasury Fees (percent of Annual Supply)||80%|
|Halving Cycle Duration (Years)||4|
Table 5: DataHighway Economic Variables
The issuance of the DHX token is through either:
- Block Authoring / Production Rewards - DHX distributed to NPoS Validators for producing a block
- Unfreezing DAO Treasury Unlocked Reserves - DHX entitlements claimed through DAO approval in a democratic way
- Decentralised / Centralized Exchange - DHX exchanged for other assets
At genesis, the treasury will hold 30% of the genesis total supply of DHX. These tokens are to be used for the promotion and further development of the DataHighway. In order for these tokens to be distributed, a referendum must be created and accepted with stakeholder consensus through the Governance process.
The treasury is also the source of token rewards for PoP mining activities. During block development, 80% of all created DHX is then assigned to the treasury to be distributed through PoP based on participants’ mPower.
The maximum amount of DHX distributed for PoP proposals is less than 1000 per day.
The initial token issuance halving inflation strategy cycle (halving of the block production reward) shall occur every four (4) years using the "Decreasing-Supply Algorithm".
|Year||Halving Cycle||Halving Factor||Block Reward||Remaining Total Supply (DHX)|
All DHX DAO decisions shall be made through on-chain governance once the temporary Sudo and a Multisig control of the DHX DAO Treasury Unlocked Reserves are removed, and will function much in the same way as Polkadot Governance, with some exceptions.
Participation in DataHighway Governance is required in order to take advantage of PoP mining. This participation takes the form of bonding DHX to a council member, or potential council member. This bonded DHX helps to ensure that all participants in the DataHighway work together to determine who should be on the council. If a council member is not chosen, and is not shortlisted, DHX tokens belonging to the participant that they bonded will be unbonded and returned to them automatically. They must then rebond those tokens to a different council member or candidate in order to continue PoP mining.
Each MXC Supernode is viewed as a single identity on the DataHighway, thereby acting as a broker for all participants that have chosen them. When mining on an MXC Supernode, a portion of each participants’ mPower goes to a council chair, who then acts as a proxy on behalf of them when determining how an MXC Supernode will vote on a referendum. All council chairs will be required to vote on each referendum, otherwise the council chair benefit will be slashed.
Once participant votes are tallied for an MXC Supernode, its council chair will submit its vote using the DHX tokens that participants bonded using the 10:1 rule.
If there are multiple councils on an MXC Supernode, then the council with the most mPower on that MXC Supernode will be determined as its "Primary Council". The vote from that MXC Supernode will be automatically cast based on the decision of its Primary Council.