Skip to content

The HyperCash Constitution

HCASH is a decentralised, open source, dual chain ecosystem comprised of the HyperCash (HC) and HyperExchange (HX) networks. These have been developed in parallel to facilitate the exchange of information between blockchains and non-blockchain networks.

The HC blockchain is built on a robust framework made by Decred, with an added structure consisting of multiple important additions which have been proposed and implemented based on work done by our world-class research partners and development team.

The mission of HC is to provide a network and token accessible by anyone, which will remain secure, private, and decentralised. The following has been set out as a guide for conducting a fair and viable project, based on a set of principles, and adherent to an autonomous and democratic governance model.

The Principles of HyperCash

  • Software developed as a part of, or in conjunction with HC, shall ultimately be open source and freely available.

  • Constructive comments, opinions and ideas based on fact and reason shall not be discouraged or prohibited, and will be taken into consideration by the team.

  • No group or individual shall be excluded by the HC network if they abide by the principles and guidelines outlined by the team and any laws applied by governing bodies within relevant jurisdictions.

  • HC and the core elements within its network are based on security and privacy. These have been, and will continue to be actively developed and updated to ensure the safety and privacy of users, both presently, and in the foreseeable future.

  • The amount of HC tokens is predetermined and shall not be altered.

  • All HC tokens are fungible and can be used within the HCASH network with equal weighting and value.

HC Blockchain Governance

  • The HC blockchain is governed by a hybrid PoW (Proof of Work) + PoS (Proof of Stake) consensus mechanism. This works by PoW miners creating blocks, and PoS miners confirming the validity of these blocks.

  • For a PoS miner to be eligible to receive rewards, they must purchase at least one ticket - effectively locking the cost price of the ticket for 512 block confirmations, or approximately 21.33 hours. Ticket fees are paid to PoW miners, who will place new tickets into newly mined blocks. A ticket price adjustment is made every 288 blocks.

  • After this period, a ticket is mature and is eligible for voting. Tickets are chosen to vote on any given block, based on a Poisson distribution function, receiving a reward for their vote thereafter. The probability of being selected within 28 days is 50%, and the probability of being selected within 142 days is 99.5%. If not selected within 142 days, the ticket price will be refunded, and the ticket fee will not, as it will have been paid to a miner for verification.

  • Purchased tickets are not valid until they are included into a block by PoW miners. If tickets are not yet included into a block, they remain in the mempool. The higher the ticket fee paid by the user, the higher chance the ticket will be selected by PoW miners to be included in a block. Since there is a limit to how many tickets a new block can contain (maximum 20 tickets per block), there is competition between ticket holders.

  • It can take up to, however, normally significantly less than 71 days before tickets in the mempool are selected by PoW miners. If they are not selected within 71 days, both the ticket price and ticket fee are returned to the user’s hcGUI wallet account.

  • Each block mined on the HC main chain contains a 6.4HC reward (decreasing with time), which consists of 3.84HC (60% of the total) allocated to PoW mining, 1.92HC (30%) for PoS mining, and the remaining 10% for developers.

  • During the generation of each block, five tickets will be selected, and each of them will be rewarded 0.384HC.

Autonomy

  • Autonomy is a public proposal system, and the platform behind the governance of the HCASH ecosystem. Users can submit and track their own projects and suggestions, to be voted on and discussed by their community, with the potential to be executed and/or funded by HCASH.

  • Benefiting from the intrinsic properties of its blockchain substructure, the system cannot be censored, is robust and future-proof, ensuring its sustainability in the long term.

  • Decisions in the HCASH ecosystem are made autonomously, by allowing users to vote using HC tokens to purchase voting tickets. These tickets can then be used to vote for or against an unresolved proposal which has been created by a member of the community.

  • Proposals can be put forward for two reasons. The first is for a course of action - for example, changing a policy. The second is to propose to commit funds from the HC treasury towards an aim. These proposals must have a budget from which the proposers have access to funds as they demonstrate progress of the proposal’s aim.

  • In order to prevent spam accounts, fraudulent (paid) voting, and general spamming, registering an Autonomy account and submitting proposals will both incur a 0.1HC fee.

  • Fees may be amended in the case of the amount proving to be ineffective, or significant price changes of HC tokens due to market conditions.

  • In Autonomy, proposals and comments are checked by administrators to ensure they meet standards. If they are deemed invalid, or as spam, they will be openly censored.

  • Users who have had their proposal or comment censored will be able to demonstrate their validity to the community using a “censorship token”, which is automatically produced at the time of the submission of a proposal or comment. This token is cryptographically linked to its creator’s public and private key.

  • After a proposal is submitted, it will be reviewed by Autonomy administrators, and any proposals deemed as spam will be censored. Proposals which meet standards will become visible on Autonomy, with users being able to comment, but not vote in order to enable the proposer to edit their proposal based on user feedback.

  • When the proposer opts to begin voting, an admin will enable it, and the voting period commences. The voting period lasts for 4032 blocks, or about 7 days. A snapshot of the ticket pool of the proposal will be taken 512 blocks prior to the start of voting. Only live tickets can vote in this snapshot, and tickets submitted after the snapshot are invalid for this proposal. Decisions related to the duration for which proposals are displayed on the website and the timing of the commencement of voting is up to the discretion of Autonomy administrators.

  • The decision for the approval or rejection of a proposal is made after 4032 blocks have elapsed. 20% of tickets must vote for voting to be deemed valid. For a vote to be passed, at least 60% of votes must be “yes”.

  • If a proposal requires a budget, it can proceed when the budget, along with its progress milestones are approved, with the proposer being able to claim agreed upon parts of the budget when they can demonstrate that milestones have been met.