Exchange Transfer

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Transfer states via an exchange.

Context

The application has a large number of states, and all of them need to be recreated on the target blockchain. The user has chosen an existing public blockchain as the target and tokens are to be converted to its native assets. The list of states to be migrated can be found from the application-level reference to the blockchain identifier mapping database.

Problem

How to load states and smart contracts to the target blockchain?

Forces

• Consistency – States such as blockchain native assets cannot be arbitrarily created because migration must preserve system invariants. It is difficult to create a complete copy of the ledger and block history, as the system is distributed, new blocks are built continuously, and finality is not immediate.
• Accountability – Initiation of new accounts and their states on the target blockchain must be recorded with proof.
• Size – A blockchain may contain a large number of accounts, states, smart contracts, and transactions. Moreover, history may consist of a large number of blocks. A large subset of these may need to be initiated on the target blockchain.
• Latency – The time to create accounts and initialize their states is proportional to the number of accounts and their states. Given the large size of the global state and history, the time to make a copy could be very long. It takes even more time to recreate and validate the global state by applying all transactions and running smart contracts.
• Cost – Each account creation and state assignment may needs to pay a transaction fee. The transaction fee could also be proportional to the size of the state.
• Consensus – To accept a state, smart contract, transaction, or block as valid, both the sender and receiver nodes must follow the same consensus rules.
• Governance – The consensus of the blockchain’s governance body is required to update any state or blockchain platform software.

Solution
As seen in the following figure, use a cryptocurrency/token exchange to transfer the states. If a user cannot use an existing private key to access the state migrated to the target blockchain, follow the first step to create a new account. Then get the user to sign a transaction with both the state and new account ID (i.e., accID) on the target blockchain as the payload. Set the address of the exchange (excAddress) as the recipient. Then submit the signed transaction to transfer the state to the exchange’s account on the source blockchain. This is similar to a sell order in financial markets. Once the exchange confirms that the state is transferred to its account, it will look for a matching buy order. Once a match is made, the exchange will transfer the state to the accID from its account on the target blockchain. Finally, update the application-level reference to the blockchain identifier mapping database (i.e., ID database) to reflect new account IDs (this step is not shown in the figure).

Some of the exchange-based data migration scenarios use a combination of token burning and state initialisation patterns. Whereas above figure captures the behaviour of an exchange matching sell and buy orders from source and target blockchains, which is more prevalent in decentralised exchanges. Chosen exchange(s) should support the state to be traded. If the format of states used by the application and exchange does not match, the state could be tokenized to a common format (e.g., ERC-20 standards in Ethereum). This could be achieved by deploying a smart contract to convert tokens on the source blockchain. Similarly, tokens could be decoded on the target blockchain.

The number of public blockchains and types of assets/tokens supported by a centralised exchange are usually limited. However, a decentralised exchange can be configured to connect with any blockchain and support any token format agreeable to both the blockchains. Even the migration tool could be extended to act as a decentralized exchange.

The first and last steps are optional when the accounts can be reused across the blockchains, it is desirable to create new accounts. As discussed in the establish genesis pattern, this can enhance anonymity and guard against exposure of private key due to weaknesses that may appear in the source blockchain. Also, user involvement is needed to create new accounts. Similar to the state initialisation pattern, signed transactions are issued by the migration tool to the source blockchain, mainly for the convince of managing the migration. Instead, users may send the signed transactions directly, as each state is exchanged using an independent transaction.

Moreover, as the centralised exchanges usually keep custody of a user’s private key, it could automatically transfer the state without user involvement. In all scenarios, a transaction fee and commission are usually charged. Time taken by all users to create new accounts and sign transactions is difficult to predict. Similarly, the time needed by the match function depends on market demand for asset/state. Hence, sufficient notice ranging from a couple of weeks to months needs to be given to the users. However, this user involvement does not slow down the entire migration process, as each state is independently transferred.

Benefits

• Consistency – One state can be transferred at a time without requiring the migration to be a single-shot operation; hence, the risk is reduced.
• Cost – The cost is proportional to the number of states and their sizes/values to transfer. Bulk/aggregated transfers and the use of centralized exchanges could reduce the size, cost, and latency.
• Consistency and Accountability – Because the state transfers to and from the exchange’s account are recorded on the blockchain, better consistency and accountability can be achieved.
• Privacy – Decentralised exchanges provide enhanced privacy compared to centralised ones due to disintermediation.
• Governance – No explicit approval of the blockchain governance body is needed to trade assets via a supported exchange.
• This pattern works with both blockchain native assets and tradable tokens on any blockchain platform.

Drawbacks

• Liquidity – The state should be tradeable on the chosen exchange(s) or should be convertible to a tradable token.
• Cost – Exchanges charge transaction fees and apply asset conversion rates reducing the value of assets during the transfer.

Related patterns

• Snapshotting, state aggregation, and token burning patterns could be used to identify, reduce, and burn the states to include in the genesis block.
• Use the blockchain anchor pattern to add a PoE entry that tracks the mapping between old and new account IDs.
• Alternatively, if the mapping between account IDs is not very large, an encrypted version can be added using the encrypting on-chain data pattern.

Known uses

• During the migration from Ethereum, Atomic, Binance, Gifto, TOMO, Tron, and VeChain requested users to migrate their assets to a selected centralized exchange.
• ChangeNOW token swap service was used by Atomic to migrate from Ethereum to Binance.
• KyberSwap also offers a similar service for ERC-20 tokens.
• EOS and Interledger provide protocols to transfer tokens via decentralized exchanges.