Wormhole: A Smart contract implementation based on Bitcoin Cash

Author: Chia Chi, Jiang Heping, Wen Long

Abstract

Born at the block height of 478,558, Bitcoin Cash (BCH) has been dedicated to bringing a reliable
electronic cash to the world and fulfilling satoshi’s original vision as a "peer-to-peer electronic cash."
It enjoys global seamless circulation, permissionless innovation and other features. How to issue
token on the Bitcoin Cash blockchain? Many developers have brought up with ideas such as
Coloured-Coins. And Andrew Stone proposed to increase OP_GROUP to implement the token
scheme as he mentioned in Enable representative tokens via OP_GROUP on Bitcoin Cash. The
OP_GROUP solution can only be realized by altering consensus rules of Bitcoin Cash. More
specifically, it enables functions similar to that of ERC20 token protocol on the Ethereum network.

Any proposals enabling token issuance that requires certain consensus upgrades will inevitably cause
problems, including technical risks, harsh conflicts and huge controversy among community
developers. The concerns of the opponents in the dispute are likely to be true. Regardless right and
wrong side in this controversy, this could help prevent “radical” initiatives being implemented to
ensure the stability and security of the network protocol. However, it makes it harder to promote
innovation. The controversy that led to the expansion of the independent block of the Bitcoin Cash
community, the prolonged and unconstrained generation, is an even more unavoidable evidence of
social psychology.

Innovation requires a PERMISSIONLESS community. We have also been exploring ways to

implement smart contracts on Bitcoin Cash blockchain without changing the consensus rules. After
tremendous research effort, we have paid attention to the OmniLayer protocol, a scheme to realize
token issuance through the OP_RETURN opcode. It is the technical basis for daily distribution and
circulation of USDT. The Omni Layer runs on top of Bitcoin blockchain. Since the Omni Layer
protocol uses the MIT license (open source), we forked the Omni Layer protocol and implemented
the tech feature on Bitcoin Cash blockchain to achieve token issuance. We named this technical
solution Wormhole protocol, and the original token in the protocol is named Wormhole Cash.

Term

• OP_RETURN: One of the opcodes in Bitcoin Cash. Any transaction outputs containing it is
Un-spendable, and nodes can safely move it out of the UTXO collection without affecting the total
volume of the UTXO collection. After the protocol upgrade in May 2018, BCH increased its default
data-carrier-size to 220 bytes.
• Wormhole protocol: It is based on the Omni Layer protocol that make protocol specs for smart
contracts on the Bitcoin Cash blockchain possible.
• Wormhole Cash: The base currency used in the Wormhole protocol, or "WHC" in short.

Theory

Wormhole Cash is based on the Bitcoin Cash blockchain and is attached to the Bitcoin Cash block,
transferring and burning into the BCH blockchain without changing the current BCH consensus rules.
The metadata information of the transaction is written on OP_RETURN. Based on the Wormhole
protocol, its issuance, transferring and burning are all done through the Bitcoin Cash transaction, and
through recognizing(reading) data stored in OP_RETURN.
Wormhole protocol multiplexes Bitcoin Cash's transaction transfer system to read transactions,
addresses, and OP_RETURN data on Bitcoin Cash blockchain.

Wormhole protocol is a superset of the Bitcoin Cash network consensus. The metadata it identifies is
only the OP_RETURN data in the consensus protocol of the Bitcoin Cash blockchain, and consensus
rules of Bitcoin Cash do not need to understand data in OP_RETURN.

Implementation

Wormhole protocol is implemented by integrating into Bitcoind. But the consensus rules of Bitcoin
Cash themselves do not need to be changed. Bitcoind clients that integrates the Wormhole protocol
are called Wormhole clients. Nodes running the Wormhole client will be able to recognize the
OP_RETURN Wormhole protocol.

Security and consensus rules

Wormhole Cash represents a two-layer security approach.

The first layer is Bitcoin Cash's transaction security. Bitcoin Cash adopts POW algorithm as a
decentralized timestamp server. The algorithm has been working stably for nearly 10 years. Here are
some of the benefits of the UTXO model:

• UTXO requires no balance maintenance

• UTXO serves as an independent data logger that can speed up transaction verification.
• UTXO model only “cares” locking scripts and unlocking scripts.
• UTXO has high performance when processing transactions.

Wormhole protocol multiplexes the entire UTXO security model of BCH and its decentralized
timestamp server model.

The second layer of security is that nodes running the Wormhole protocol will not analyze data that
does not conform to the Wormhole protocol. Each node has the ability to reanalyze transaction data
and calculate the most “recent legal final state” of Wormhole Cash.

Wormhole Cash（WHC）

Wormhole Cash (WHC) is the base currency in the Wormhole agreement. The reason why WHC was
introduced is for:
When the smart contract is implemented in Wormhole protocol, Wormhole protocol layer cannot
control Bitcoin Cash, so transactions can't be implemented in the Wormhole protocol layer. And
when implementing smart contracts Gas needs to be introduced as a protective measure against
network abuse, and there is also a need for the Wormhole protocol to have a raw base currency.

The generation of WHC

WHC is generated by the mechanism of Proof-of-Burn, and users who hold BCH can use
the Bitcoincash:qqqqqqqqqqqqqqqqqqqqqqqqqqqqu08dsyxz98whc address to send 1 BCH to
generate the 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.

In order to prevent the theoretical extreme situation

- In the future, 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. Of course, this is not in the concerned
part of this article and me.
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? This question has made countless engineers study
the two-way anchoring since the sidechain theory was proposed. 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. Wormhole protocol implements a smart contract, with a
programming different language with Bitcoin Cash, is very similar to the one-way ticket for Star
Trek. 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 abuse of the network, or the use of the network exceeds current
technology and the blockchain infrastructure that allows. 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.
The situations that 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, sending token to all addresses that have a certain token, you
need to pay WHC transaction fee
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 will 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 burning

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

Wormhole Road Map

The development of the Wormhole protocol is divided into four phases: Earth, Tropos, Ionize,
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
• Estimated completion time 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 implementation
• Wormhole's iOS wallet reference implementation
• Wormhole of the PC wallet reference implementation
• Estimated completion time 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 analysing Wormhole.
• Wormhole Cash's cold wallet solution
• Estimated completion time 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. We may be able to implement it after further
research. 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. There
have been some better ideas in recent years. 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.
Estimated completion time 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 is a complete protocol that 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.

https://bitcoin.org/bitcoin.pdf,Oct 2008.
[2] OP_RETURN https://en.bitcoin.it/wiki/OP_RETURN
[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/ColoredCoins-Protocol-
Specification/wiki
[6] Andrew Stone : Enable representative tokens via OP_GROUP on Bitcoin Cash
https://github.com/BitcoinUnlimited/BUIP/blob/master/077.mediawiki
[7] ERC-721 http://erc721.org/