STEM : Secure Token Exchange Mechanisms
Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
CE & IT Department, Veermata Jijabai Technological Institute,
Mumbai - 400019, India
mdarisi b15@it.vjti.ac.in,jnsavla b15@it.vjti.ac.in,
mrshirole@it.vjti.ac.in, sgbhirud@ce.vjti.ac.in
Abstract. With the flooding of a large variety of isolated blockchain
solutions into the technological world, one major challenge is to enable
efficient interoperable interchain and intrachain exchanges. The dearth
of inter-operating among these eclectic tokens is hindering the profits
that can be earned by potential investors. The myriads of tokens that
are flooding into the blockchain ecosystem need to interoperate amongst
each other. This paper proposes a mechanism to provide better atomic in-
trachain token swaps. Our blockchain solution can assist the exchange of
these eclectic heterogeneous tokens securely, using digital signatures and
hashed time lock contracts, which reduces the problem of interoperabil-
ity. This paper presents a solution which is token standard agnostic and
provides effective intrinsic smart contracts facilitating token exchange
and thus reducing the counterparty risk.
Keywords: Blockchain · interoperability · atomic swaps · token exchange.
1 Introduction
Blockchain is a sequential chain of immutable data structures called blocks that
encompass a set of valid transactions, which are transparent to the participants
of the blockchain. Blockchains have entities known as miners who perform suit-
able consensus algorithms to append blocks onto the chain. With the emergence
of blockchain ecosystems, the means of completing a trustless transaction be-
tween two parties has become very lucid. Blockchain is yet in its embryonic
stage of development and requires amelioration on several inchoate use-cases
on which amelioration is required. In the present blockchain world, there ex-
ists no blockchain solution which addresses all these problems, thus hindering
blockchains adaptability. Blockchain 3.0 aims to achieve improvements in the
regions of scalability, interoperability and governance. Presently most of the
blockchains and tokens are independent of each other and do not transact among
each other easily. Therefore the future of the distributed internet thrives on the
ability of blockchains to interoperate with each other.
Interoperability is the ability of several blockchains to exchange their data
seamlessly among each other. Interoperability in blockchains is required at both:
interchain and intrachain levels. In the present interchain solutions, the exchange
II Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
occurs between two independent blockchains. If both the chains that are interact-
ing are of the same type, then they are known as homogenous interchains, and if
two disparate chains are interacting, then they are known as heterogeneous inter-
chains. Granularity of interoperability is defined as the level at which blockchains
can interoperate. We have two levels of Interoperability: a)Blockchain Interop-
erability b)Token Interoperability. The interoperability among chains can take
place either through the base currencies or through the exchange of tokens. Pop-
ular homogenous and heterogenous interchain frameworks are PeaceRelay [1],
Polkadot [2] and Cosmos [3]. Xclaim and WBTC [4] are innovative projects
which facilitate interoperability among Bitcoin [5] and Ethereum [6] blockchains.
Xclaim facilitates the interoperability among the two chains through their base
currencies ETH and BTC whereas WBTC facilitates the interoperability among
the chains with support of WBTC tokens.
With the proliferation of blockchains, the tokenisation of traditional assets
into crypto-based assets has gained immense popularity. The myriad tokens
which are present in the crypto world can be broadly classified into either fungi-
ble or non-fungible tokens. Fungible tokens are tokens which have currency like
properties and are interchangeable, uniform across platforms and are divisible
into units. Non-fungible tokens are uniquely identifiable during interaction and
circulation, and these tokens are non-interchangeable, unique in nature and non-
divisible. These tokens are used to represent potpourri assets, research projects
and business processes. If we notice in the present blockchain systems, there is
an acute shortage of interoperability at the intrachain level. At the intrachain
level, there are no efficient methods to provide proper interoperability among
the different tokens.
This paper’s main contribution is providing solutions to the currently hin-
dering intrachain interoperability problem. This paper offers two approaches to
solve these intrachain problems: a)Central Contract Based Technique b) Atomic
Swap Based Technique.
Rest of the paper is organised as follows: Section 2 discusses related work
in the field of blockchain interoperability, Section 3 gives an overview of the
basic concepts which will be used in this paper, Section 4 describes the proposed
solution. Finally, Section 5 concludes the paper.
2 Related Work
The development of blockchain solutions began with the inception of rudimen-
tary systems like Interchain [7], which employed three handshaking method to
facilitate asset transfers between isolated blockchains. However, they did not
provide efficient consensus algorithms to settle cross chain transfers. As time
progressed the blockchain community witnessed the emergence of new consen-
sus algorithms like Byzantine Fault Tolerance [8] and Proof of Stake [9] which
STEM : Secure Token Exchange Mechanisms III
aimed to replace the current consensus algorithms to enhance the scalability and
interoperability of blockchain systems.
These new consensus algorithms paved the way to several solutions like two
pegged Sidechains [10] and Strong Federations [11]. Sidechains pioneered the
concepts of interoperability to the blockchain world, which was the critical step
to abate the inability of isolated blockchains to communicate with each other.
Sidechains enabled cryptocurrencies such as Bitcoins and Altcoins to be trans-
ferred between myriad blockchains using a two-way peg. Tokens from one chain
(e.g. Bitcoin) held on behalf of a side-chain are secured only by the side-chains
ability to incentivise miners to canonicalise valid transitions. It did not provide a
protocol to validate the sidechain transactions. With the inception of sidechains
with mining, fees have caused a grave resource pressure on miners, thus creating
centralisation risks on the blockchain systems. Strong federations proposed a
Byzantine-robust interoperable blockchain solution which facilitated the move-
ment of assets between diverse markets, using federated-peg mechanism for two-
way transfer of assets between the Mainchain and Sidechain. Strong Federations
proposed multi-signature addresses, where assets are locked in and could be un-
locked if only enough key holders would agree onto the fact that the payment is
valid. The authors claimed that the participants in a Strong Federations would
be naturally incentivised to take greater care of access to the federated signers
under their control. However, none of this could be proved rigorously and is po-
tentially not even real. Both Strong Federations and Sidechains could come up
with exciting concepts to facilitate cross chain transfers, but none could provide
effective governance for the consensus mechanisms used in their systems, which
was a significant drawback in their proposals.
The shortcomings were a learning trajectory for many heterogeneous inter-
chain interoperability projects like Polkadot [2] and Cosmos [3]. Both the projects
starkly addressed the scalability and interoperability problems in the existing
blockchain solutions and worked to provide robust frameworks to tackle these
issues using interesting methodologies. Polkadot’s architecture revolves around
two major components; one is the relay chain, which is responsible for facili-
tating interoperability among different chains, and the second is the parachains
which improve the present torpid blockchain transaction rate. Cosmos proposes
an interesting star topology which connects heterogenous blockchains using a
central hub and is backed up by the high-performance Tendermint [12] cores,
efficient consensus algorithms like DPoS [13] to address the scalability hindering
the current blockchain systems. However, both Polkadot and Cosmos, do not
envision to support the deployment of customised blockchain smart contracts.
With substantial growth in the popularity of tokens, several protocols like
0x [14] and LoopRing [15] came into the blockchain world providing promis-
ing open exchange protocols for the exchange of these multifarious tokens. 0x
and LoopRing are open protocol standards for facilitating intrachain symmetric
and asymmetric decentralised transactions of eclectic tokens on the ethereum
blockchain. 0x aims to delineate a learning trajectory for programmers to de-
velop an interoperable token exchange solution by providing a robust baseline
IV Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
framework. 0x offers dual benefits of not only enabling transfer between fungible
tokens but also between fungible and non-fungible tokens.
On the other hand, LoopRing excels in building standards and contracts
which facilitate low gas cost, trustless, anonymous intrachain transfers by us-
ing off chain set of actors for agglomeration. LoopRing is a blockchain agnostic
protocol which only requires the blockchain to support the deployment of smart
contracts. Other decentralised exchange protocols are starkly juxtaposed with 0x
and LoopRing. 0x and LoopRing protocols have addressed the intrachain inter-
operability but have not still shed light on the interchain token interoperability.
XClaim [16] and Wrapped Bitcoins [4] are practical implementation papers
demonstrating the exchanges between the two popular blockchains, Ethereum
and Bitcoin. XClaim and Wrapped Bitcoins provide protocols for minting, burn-
ing, transferring and swapping tokens securely on the existing blockchain. Both
XClaim and Wrapped Bitcoins use two different methodologies to achieve these
cross chain transfers. Xclaim uses low-cost atomic cross chain swaps to transfer
cryptocurrency backed assets among the two blockchains whereas Wrapped Bit-
coins uses a central authority to mitigate these transfers between the blockchains.
Xclaim presently doesn’t facilitate the exchange of fungible and non-fungible to-
kens.
Aion network [17] is an innovative project, which incorporates efficient design
patterns in its tiered architecture to enable disparate systems to communicate
by employing a Connecting Network, a Participating Network and a Bridge
protocol that paves the path for the transparent communication between the
two networks using its own set of validators. It maintains accountability across
networks using a light-weighted BFT-based agreement algorithm that approves
transactions when 2/3rd of the validators vote. Stakeholders of the connecting
networks assign people who act as bridge validators.
3 Basic Concepts
Interoperability solutions require some basic concepts understanding such as,
Hashed TimeLock Mechanism and Atomic Swap Mechanism. Consider two par-
ties A having token of type t1 and B having token of type t2 . The ability to
exchange among t1 and t2 is known as token interoperabiity.
3.1 Hash Time Lock Contracts
Hash Time Lock Contracts (HTLC) are special contracts that are used to lock
the assets of the participants. The locked assets can be redeemed by a mutually
decided secret and are accompanied with expiration time. To deploy an HTLC,
the transmitter of the token will first create a secret s, LockPeriod L and then
calculates the hash H of this secret:
H = sha256(s) (1)
STEM : Secure Token Exchange Mechanisms V
As any person with the secret s can claim the assets, we sign the assets with the
public key(PuR ) of the receiver so that only the intended receiver can unlock the
resources using his private key(PrR ). However, if the secret is not revealed in
the intended expiration time, then these assets are refunded to their respective
owners.
There are two types of timelocks: a) Absolute Timelock Contracts: In these
time lock contracts, the tokens will be locked for a fixed amount of time. b)
Relative Timelock Contracts: In these time lock contracts, the tokens will be
locked after the time when the transaction has been confirmed.
H 1 = Encrypt(PuR (H)) (2)
The exchange occurs if the receiver has the secret s, H1 and decrypts it using
his private key (PrR ).
f (H 1 , S) = Equal(decrypt(PrR (H1 )), sha256 (s))AN D(LocktimeP eriod < block.timestamp)
(3)
(
1, Exchange occurs
f (H 1 , S) =
0, Exchange does not occur and respective assets are refunded
Timelock contracts are used to lock the resources (assets) for the Lock-
TimePeriod(L) specified by the Transmitter until the transfer of ownership of
the assets takes place.
3.2 Atomic Swaps
The interactions between the two parties involved in the transaction of tokens
must be atomic. Partial execution of transfers should be reverted. Hash time
lock contracts is the method used to achieve atomic exchange of tokens t1 of
party A with tokens t2 of party B on the same chain as shown in Figure 1.
Suppose we have two parties, A and B (Refer Fig. 1), who hold tokens on different
accounts. The atomic swap algorithm facilitates A to exchange its tokens for B ’s
tokens as follows:
1. First, party A generates a random secret s and then computes the hash H
of the secret, H = hash(s). After that, A shares H with B.
2. A first locks its tokens t1 by moving them to a temporary output Q1 for N
seconds.
3. Similarly, party B locks its tokens t2 by moving them to a temporary output
Q2 for 2N seconds after seeing that A has locked his tokens and has sent
secret H.
VI Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
Fig. 1. Atomic Swap of tokens between parties A and B
4. A passes this transaction to B for it to be signed. B then claims tokens t1
using its signature and secret s.
5. A claims tokens t2 using B ’s signature and its own signature.
6. A then creates another transaction which returns tokens t1 from Q1 to A
with a lock-time of N seconds stating that if secret s for H is revealed within
N seconds by B, then ownership of the token will be transferred to B ; oth-
erwise, the asset will be unlocked after N seconds.
7. Similarly, B creates another transaction which returns tokens t2 from Q2 to
B, with a lock time of 2N seconds stating that if secret s for H is revealed
within 2N seconds by A, then ownership of the asset will be transferred to
A; otherwise, the token will be unlocked after 2N seconds.
4 Proposed System
4.1 Definitions
Below we provide the definitions for blockchain interoperability, token, and token
interoperability.
Blockchain Each blockchain is defined as “tuple (G, B) where G is a genesis
state and B = [β 1 , β 2 , β 3 ...] is an ordered list of blocks. A blockchain is valid if
every β ∈ B is valid, and so G + β 0 + β 1 + ... = σ f is a valid state. A block
β is a package containing a list of transactions T, a reference to a parent block
and auxiliary verification data” [18].
STEM : Secure Token Exchange Mechanisms VII
Blockchain interoperability Blockchain interoperability can be defined as a
two-tuple (S, D) where S is the source blockchain and D is the destination chain
with which it wants to interoperate.
For a cross chain transfer with the transaction ti ∈ TS , TD to occur, we need to
ensure that the states of both the blockchains interoperating change as
– CS (σ(S) + ti ) = σ i+1 (S) in the context of σ of source chain using consensus
algorithm CS
– CD (σ(D) + ti ) = σ i+1 (D) in the context of σ of destination chain using
consensus algorithm CD
Where σ is used to denote the current state of the blockchain and σ i+1 is used
to denote the next state of the blockchain. CD and CS are used to verify and
validate the Transaction T on their respective chains.
If (S, D) are of the same chains then they are known as homogenous chains. If
(S, D) are of different chain then they are known as heterogeneous chains.
Token A token T is defined by a five tuple <S, N, T, I, P> where S is the token
symbol, N is the token name, T is the token type, I is the initial supply of the
token and P is precision of the token supply.
Properties
– Both S and N must be unique in a blockchain.
– Token type can be either fungible (F) or non-fungible (NF).
– Precision of the token is a positive number. For example a number ranging
between [0-18].
Token Interoperability For a given blockchain B which consists of a list of
Tokens T=[t1 , t2 , t3 ... tn ], exchange among any two token TS and TD is defined
using a four tuple <TS , NS , TD , E>, where TS is defined as the source token,
NS is the number of the source tokens to be exchanged, TD is defined as the
destination token and E as the Exchange Rate.
4.2 Exchange Scenario
The actors of the proposed solution are:
1. Token Trader: Token traders are user accounts who trade and buy tokens
from user accounts.
2. Token Owner: Token Owners are user accounts which deploy token contracts
with an initial supply. These are the account holders which can mint the new
supply of tokens.
Consider several ICOs that have been launched since 2010. Tokenization has be-
come a vital source of funding for research projects. With these many tokens into
the crypto world, we have an urgent need to interoperate among them. Consider
two ICOs IA and IB who are the token contract owners who have deployed a
VIII Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
Fig. 2. Exchange of tokens between parties A and B using intermediate Exchange
Contract
token contract with an initial supply of N tokens each to get funds for their
project. Each of the ICOs has sold Ns to token traders who are investors that
invest in potential projects to gain profits. These investors aspire to maximize
their profit. So these token traders keep exchanging tokens among themselves
based on the growth of the ICOs. The problem that is hindering these token
traders from maximizing their profit is the inability of these token traders to
exchange between the two different tokens.
This paper presents two solutions to resolve the above problem. For each of the
solutions mentioned below, the contract interface and the implementation de-
tails have been provided.
Consider A and B as potential token traders who want to exchange tokens
among themselves to maximize their profit. So the exchange of these eclectic
tokens can be enabled using Central Contract exchange mechanism and Atomic
Swap exchange mechanism.
4.3 Using Central Contract exchange
In this approach, we maintain a single intermediate Exchange Contract which
will interact with the users A and B (Refer Fig 2). This solution mainly consists
of three phases:
STEM : Secure Token Exchange Mechanisms IX
1. Registration phase: All intrachain transfers can occur only after the tokens
have been registered to the Exchange Contract. Each token trader provides
a three tuple (A, S, R) to the Exchange Contract during the registration
phase where A denotes the address of the token contract that is deployed,
S denotes the token symbol name and R the rate at which he would like to
trade in the base blockchain currency.
2. Exchange Phase: Once both the parties(i.e A and B ) have registered to
the exchange contract, one of the two parties initiates the intrachain token
transfer. The source party sends Ns tokens of his to obtain Nd tokens from
the destination party. The Exchange Contract facilitates this exchange by
calculating the exchange rate E for the exchange of the two tokens as E =
Rs /Rd where Rs and Rd are the exchange rates of the source and destination
parties. Once the exchange rate E is calculated, Nd = Ns *E tokens are sent
from the destination party to the exchange contract. The Exchange Contract
then forwards Nd tokens to the source party and Ns tokens to the destination
party.
3. Unregistration Phase: Once the exchange is complete both the parties
can unregister themselves from the Exchange Contract or remain registered
for further transactions.
Contract Interface :
interface CentralTokenContract {
function deRegister(string memory symbol) public returns (bool
success)
function Register(address address, uint256 saleValue, string
memory symbol) public returns (bool success)
function getOwner(string memory symbol) public view returns
(address TokenOwner)
function NativeToken(string memory SrcSym,string memory DestSym,
uint256 Qty) public returns (uint256 success)
function getTokenValues() public view returns(ValueDisplay[]
memory Table)
}
– deRegister: Given the Token Symbol, the Token Contract is unregistered
from the Exchange Contract. This function returns a boolean value which
states whether the de-registration was successful or not.
– Register: Given the address of the token contract, the value at which the
token must be sold and the Token Symbol, a boolean value is returned which
states whether the registration was successful or not.
– getOwner: Given the Token Symbol, the address of the Token Owner is
returned.
– NativeToken: Given the Source Token Symbol, Destination Token Symbol
and Quantity of Native tokens to be exchanged, Returns a boolean value
which shows if the exchange was successful or not.
X Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
Fig. 3. Atomic Swap of tokens between parties A and B
– getTokenValues: Displays a two-tuple Table indicating the Sale Value and
the Token Symbol of all the tokens which are registered to the Exchange
Contract. Returns an array of type ValueDisplay.
4.4 Using Atomic Swap Exchange
Atomic Swap is a common mechanism used in interoperability solutions. The
exchanges in these solutions take place without the involvement of intermediate
entities. The atomicity of the intrachain transactions must be maintained, i.e.,
the partial execution of the atomic swap transactions should result in the rever-
sion of the transactions. Atomic swap exchanges primarily use HTLC Contracts
to lock their assets. These assets can be claimed by revealing the secret within
the expiration time. Most of the atomic swap solutions involve 1:1 backing up
of tokens and do not involve oracles to aid them during execution. The process
is as follows (Refer Fig. 3):
STEP 1. Wallet A deploys Token Contract A with a predefined initial supply,
name and symbol of the token. Similarly, Wallet B deploys a Token contract B
with a predefined initial supply, name and symbol of the token. The balances of
user accounts and token contracts is maintained using a hash-map data structure.
STEM : Secure Token Exchange Mechanisms XI
STEP 2. Token Contract A and Token Contract B then register to the Ex-
change Contract and specify the rate at which they want to sell their corre-
sponding tokens.
STEP 3. Token Contract A subscribes to an oracle [19] and generates a random
number s which is hashed (H = hash(s)) and is shared with Token Contract B.
STEP 4. Now Token Contract A locks NA tokens of its wallet with a time
stamp of N seconds, signs it with the public key of B (PKB ) and transfers it to
Atomic Token A Contract for the intrachain exchange.
STEP 5. Similarly, Token Contract B calculates the exchange rate E by in-
teracting with the Exchange Contract. E is calculated as Ra / Rb where Ra and
Rb represent the exchange rates of tokens Aand B respectively.
STEP 6. Token Contract B then locks NB tokens where NB = NA * E with
a timestamp of 2N seconds, signs it with the public key of A (Pka) and transfers
it to the Atomic Token B Contract.
STEP 7. Atomic Token B Contract first claims NA tokens it by decrypting
using its private key PrB and secret s. If the contract fails to claim A’s tokens
within the designated timestamp (N seconds), the transaction is reverted.
STEP 8. Similarly, Atomic Token A Contract can claim NB tokens by unlocking
them using its private key PrA and secret s. If the contract fails to redeem B’s
tokens within the required timestamp (2N seconds), the transaction is reverted.
Contract Interface :
interface AtomicSwap {
function lock(address to, bytes32 hash, uint lockExpiryMinutes,
uint amount) public view returns (boolean success)
function unlock(bytes32 hash) public returns (boolean success)
function claim(bytes32 secret) public returns (boolean success)
}
interface ExchangeContract{
function deRegister(string memory symbol) public returns (bool
success)
function Register(address address,uint256 saleValue,string memory
symbol) public returns (bool success)
function getExchangeRate(address TokenAddress) public returns (uint
rate)
}
XII Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
5 Implementation
We have implemented both the approaches of the token exchange mechanisms
in Solidity. The detailed data structures are given in the following subsections:
5.1 Central Exchange Contract
For the implementation of the Central Exchange Contract, we have used the
following data structures.
struct registerParam{
address TokenContractAddress;
uint256 valueInEther;
String TokenSymbol;
}
struct ValueDisplay{
string TokenSymbol;
uint256 saleValue;
}
mapping(string=>registerParam) tokenLookup;
This is a global mapping of all the tokens that are registered to the Exchange
Contract where TokenSymbol is the key of the mapping.
This implementation uses ERC 777 [20] tokens to reduce the gas cost and these
tokens are backward compatible with ERC20 [21] tokens. It allows symmetric
(where one token of A is exchanged with one token of B ) and asymmetric trans-
fers (where X tokens of A are exchanged with Y tokens of B ) to take place easily.
This process is token standard agnostic and easy to extend. However, since the
deployment of the contract is by a third party, he can include functions like
destroy() in the implementation of the Exchange Contract. Thus, there can be a
loss of tokens because we have to depend on a third party to keep the exchange
running when a transaction is taking place.
5.2 Atomic Swap
For the implementation of the Atomic Swap Contract we have used the following
data structures.
Struct AtomicTransactions{
from address;
to address;
amount uint64;
lockPeriod uint64;
}
mapping (bytes32 => AtomicTransactions) transactions;
STEM : Secure Token Exchange Mechanisms XIII
mapping (address => uint256) public balanceOf;
mapping (address tokenOwner, uint256 rate) public exchangeRate;
This implementation uses ERC 777 [20] tokens to reduce the gas cost and these
tokens are backward compatible with ERC20 [21] tokens. It enables efficient low
cost intrachain transfers. Atomic swaps eliminate the need of intermediate par-
ties, thus enabling trustless, anonymous, decentralized fee-less, less attack prone
exchanges among the parties.This mechanism is currency, token and platform
standard agnostic.
5.3 Contracts execution
The above contracts were implemented using solidity programming language.
The contracts were intially deployed on remix and subsquently deployed on
rinkeby using metamask. We have observed that atomic swap is more efficient
than central contract exchange. Excluding contract deployment time and cost
we contract execution details in Table 1.
Table 1. Cost comparision of central contract and atomic swap mechanism
Central contract Atomic Swap contract
Transactions 6 6
Execution cost(ETH) 0.000613948 0.00043875
Although both the contracts require equal number of transactions internally,
atomic swap is 25% cost efficient than central contract exchange. Morever atomic
swap contracts are more scalable than central contract contracts.
6 Conclusion
Blockchain is now being viewed as a potential technology of the future, replac-
ing the current centralised architectures. Some of the key industries which have
dire need of interoperability among their businesses are healthcare and supply
chain. This paper can be viewed as a baseline mechanism for many blockchain
use cases of these industries where interoperability is the key issue. This paper
explores secure token exchange methodologies which decrease the intrachain in-
teroperability problem among heterogeneous tokens. The mechanisms proposed
are generic and thus provide the flexibility to the user to change the token stan-
dards without affecting the procedures of these mechanisms.
References
1. Loi Luu. Peacerelay: Connecting the many ethereum blockchains, 2017.
2. G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework,, 2017.
XIV Maneesh Darisi, Janhavi Savla, Mahesh Shirole, and Sunil Bhirud
3. J. Kwon E. Buchman. A Network of Distributed Ledgers,, 2018.
4. Wrapped Bitcoin ( WBTC ) an ERC20 token backed 1:1 with Bitcoin.
5. N. Satoshi. Bitcoin: A Peer-to-Peer Electronic cash system. Bitcoin, 2008.
6. V. Buterin. Ethereum White Paper: A Next Generation Smart Contract & Decen-
tralized Application Platform,, 2013.
7. Ding Donghui. InterChain : A Framework to Support Blockchain Interoperability.
2018.
8. Giuliana Santos Veronese, Miguel Correia, Alysson Neves Bessani, Lau Cheuk
Lung, and Paulo Verissimo. Efficient byzantine fault-tolerance. IEEE Transac-
tions on Computers, 62(1):16–30, 2013.
9. V. Buterin. Proof of Stake: How I Learned to Love Weak Subjectivity,, 2014.
10. Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gre-
gory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and
Pieter Wuille. Enabling blockchain innovations with pegged sidechains.
http://cs.umd.edu/projects/coinscope/ coinscope.pdf, 2014.
11. Johnny Dilley, Andrew Poelstra, Jonathan Wilkins, Marta Piekarska, Ben Gorlick,
and Mark Friedenbach. Strong Federations: An Interoperable Blockchain Solution
to Centralized Third Party Risks. 12 2016.
12. J. Kwon. TenderMint : Consensus without Mining,, 2014.
13. Daniel Larimer. Delegated proof-of-stake (dpos). Bitshare whitepaper, 2014.
14. Will Warren and Amir Bandeali. 0x: An open protocol for decentralized exchange
on the Ethereum blockchain. Technical report, 2017.
15. Daniel Wang, Jay Zhou, Alex Wang, and Matthew Finestone. Loopring: A Decen-
tralized Token Exchange Protocol. Technical report, 2018.
16. Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Ger-
vais, and William Knottenbelt. Xclaim: Trustless, interoperable, cryptocurrency-
backed assets. 03 2019.
17. M. Spoke and Nuco Engineering Team, “Aion: The thirdgeneration blockchain
network,”.
18. Vitalik Buterin. Notes on Scalable Blockchain Protocols, 2015.
19. Antonopoulosan Andreas and Gavin Wood. Mastering Ethereum : Building Smart
Contracts and DApps. Orielly, 2018.
20. ERC777. https://eips.ethereum.org/eips/eip-777.
21. ERC20. https://github.com/ethereum/eips/issues/20, 2015.
