Part One:

Part Two

Generation of WHC

WHC is generated by the Proof-of-Burn mechanism . BCH users can send 1 BCH or more to bitcoincash:qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc to generate WHC when the Wormhole protocol is officially launched. If less than one BCH is sent to the address, then no WHC will be generated. This “ burn to generate ” process is subject to risks of rollback of the BCH blockchain. Therefore, WHC can only be generated when 1,000 confirmations are finished. 1 BCH can get 100 WHC.

Based on known cryptography theory and engineering practice and research, nobody owns the private keys of the address bitcoincash:qqqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc. And no one used this address in the history of Bitcoin Cash blockchain before we started working on the development of Wormhole protocol.

If any methods be used to create the private key of this address - the BCH protocol might prohibit coins in this address from being transferred.

If there are market demands around WHC and liquidity is high, users who need WHC can purchase WHC from the market.

Why not implement two-way anchoring with BCH? Unfortunately, there is no feasible two-way anchoring method that are safe, decentralized, and can effectively deal with the inevitable rollback risk of blockchain. When discussing about Star Trek, Elon Musk said that he is not coming back after immigrating to Mars.

It works the same way with Wormhole protocol. Each satoshi (BCH) burned will not be back. This type of "burning to issuing" is like a one-way ticket to Mars.

The process of burning to generate WHC has no deadline.

WHC use cases

Fees are often used to prevent network abuse. The implementation of smart contracts in the Wormhole protocol requires BCH transactions. The Bitcoin Cash transaction itself will cause fees can effectively cope with DoS attacks. Therefore, in the early implemented Wormhole protocol, no WHC fees are demanded for transfer.

When do you need to pay WHC transaction fee:

1. newly created token is set pay 1 WHC. Transaction fees will be burned directly and thus the total supply of WHC will be reduced. Creating a Token requires the consumption of computing resources. WHC fees are designed to prevent malicious attacks to Wormhole nodes.

2. one-to-many transfers. For example, to send token to all addresses that have a certain token.

3. Smart Contract's Gas

4. Other transactional operations, or activities might fall into DoS risks.

Token issuance

Anybody is free to create a token on the system after paying the normal BCH transaction fee and the WHC creation fee. Currently, the WHC protocol supports three types of Token creation:

1. Fixed Token

• After creation, the creator automatically owns all tokens immediately

• Cannot be increased, cannot be burned

• Cannot start a crowdfunding

2. Token can be crowdfunded

• Automatically trigger Crowdfunding after creation

• After creation, the creator does not own all tokens

• After closing the crowdfund, Token left automatically goes to the creator's address

• Cannot be increased, cannot be burned

3. Manageable Token

• When created, total number of the tokens is 0

• Cannot be used for crowdfunding

• Can be increased, can be burned

Token transfer

Both tokens issued on Wormhole protocol and Wormhole Cash itself can be transferred. 1-to-1 transfer wil only cost BCH transaction fee, no additional fees needed. TX Fees will be decided by BCH protocol.

In addition to BCH fees, one-to-many transfer also requires certain WHC fees, which is denominated and charged by the WHC. The one-to-many transfer is mainly used for Token airdrops. The WHC fees charged will be burned directly.

Token's burning

Manually managed token supports direct burning, and the total number of the token (after burning) will be shown on the Wormhole protocol.

Wormhole Roadmap

The development of Wormhole protocol is divided into four phases: Earth, Tropos, Ionize, and Exophere

Earth (beginning)

Forked from the Omni Layer protocol, Wormhole protocol aims to implement smart contracts on BCH and will first focus on decentralized token issuance management.

To ensure the security and to implement it ASAP, we do not support decentralized trading on the Omni Layer protocol.

Tasks to be completed:

• Wormhole Core implementation: Adding token issuance onto Bitcoin ABC (version 0.17.2), which will be updated accordingly with the upgrade of Bitcoin ABC.

• Release the Wormhole protocol white paper

TTC: August 2018.

Tropos

Tasks to be completed:

• Wormhole protocol-based decentralized exchange protocols will be re-implemented after enormous testing

• Wormhole's Android wallet reference mplementation

• Wormhole's iOS wallet reference implementation

• Wormhole of the PC wallet reference implementation

TTC：November, 2018

Ionize

Tasks to be completed:

• Implement ERC721 in the Wormhole protocol

• Develop the multi-language SDK. In order to make it easier for developers to develop at Wormhole, we will provide a multi-language SDK for analyzing Wormhole.

• Wormhole Cash's cold wallet solution

TTC：January, 2019.

Exophere

Tasks lists:

• permissionless smart contract.

The Omni Layer itself is not a mechanism for permissionless innovation. Any new type of contracts must be integrated into the code to be recognized. We will implement an unlicensed smart contract platform in the Exophere phase. In other words, any developers can deploy a smart contract into the network when complying with necessary rules for maintaining protocol security.

• Implement the Plasma protocol for further scaling.

After huge internal research, we may have discovered an effective approach to realize Plasma. Meanwhile, Vitalik also announced on Twitter that they have discovered a way to implement Plasma. We can also implement Vitalik's upcoming approach.

• A new generation of smart contract virtual machines.

Solidity, as a programming language that turns the concept of smart contracts into reality, has been extensively reviewed by computer experts. We will probably work to develop some virtual machines using some new programming languages ​​to make the most efficient and developers-friendly computer languages ​​available for building DApps.

TTC: June, 2019

Summary

First of all, I want to give credit to Omni Layer. Its extensive use on USDT gives us confidence that more things can be done based on Bitcoin Cash. The Omni protocol takes full advantage of the features of the UTXO model and enables token management without changing the consensus rules and the protocol. The Omni team helped us a lot in developing Wormhole. Meanwhile, Omni Layer sticks to the spirit of open source and uses the MIT license, which makes permissionless innovation possible.

The UTXO model-based public chains have been struggling to realize smart contracts. The Wormhole protocol will enbale smart contracts on BCH and open new possibilities to Bitcoin Cash.

Document History

1.Version 0.1 Wormhole Cash Completion of Phase 1 （May 23, 2018）

2.Version 0.2 Wormhole Cash Roadmap （June 20, 2018）

3.Version 0.3 Wormhole Cash alpha version （July 15, 2018）

References

[1] Satoshi Nakamoto. Bitcoin: A Peer-to-peer Electronic Cash System.

[3] OmniLayer https: //github.com/OmniLayer/spec

[4] ERC20 Token Standard https://theethereum.wiki/w/index.php/ERC20_Token_Standard

[5] The Colored Coins Protocol https://github.com/Colored-Coins/Colored -Coins-Protocol-Specification/wiki

[6] Andrew Stone : Enable representative tokens via OP_GROUP on Bitcoin Cash https://github.com/BitcoinUnlimited/BUIP/blob/master/077.mediawiki