hashport: How Fungible Tokens get ported across Hedera, Ethereum, & Polygon

hashport allows users to port fungible tokens across Hedera, Ethereum, and Polygon. The platform also has an NFT-porting capability which enables the porting of non-fungible tokens. With the help of hashport, HashAxis, HashPack, and DOVU, Hedera celebrated “Hot DeFi Summer” by minting an NFT and moved it to Ethereum to be used as Twitter PFP.

Currently, the fungible tokens that can be ported across networks include $HBAR, $ETH, $MATIC, $DOV, $CLXY, $JAM, $DAI, $LINK, $USDT, $USDC, $wBTC, and $AAVE. For the purpose of this article, we will walk you through how to port $HBAR, Hedera network’s native token, to the Ethereum network.

In our Medium article about locking, minting, and burning tokens, we discussed how porting native tokens to and from their originating chain requires mainly three basic functions:

  1. Locking the native token (e.g.: HBAR) in the multisig “Bridge” account residing on the Hedera network. This achieves:
  • preventing users from double-spending the value of a coin on two different blockchains
  • keeping whole the total supply of that native coin.

2. Minting an EVM-compatible token which is a 1-to-1 representation of the native token, on the destination chain (e.g.: 1HBAR = 1HBAR[0x]). The mint is initiated using a smart contract residing on the target EVM chain.

3. Burning the representative tokens on the foreign network to remove them from circulation whilst unlocking the same amount of native tokens from the “Bridge” account to the user’s account.

The process above could be summarised in the diagram below:

In this article, we’ll break down each step to further understand how porting fungible tokens on hashport works, and we’ll use Hedera and Polygon as our native and foreign networks, respectively.

hash-porting Fungible assets:
From Hedera to Polygon
The following sequence diagram describes the porting of HBAR from Hedera to mint HBAR[0x] on Polygon.

1. Initiating the Transfer:
A user wants to transfer 1000 HBAR from Hedera to the Polygon chain. The user opens a hashport-compatible wallet and sends his assets to the “Bridge” account. The transfer memo contains the user’s corresponding address to receive HBAR[0x] on the Polygon chain.

2. Picking up the Transfer:
hashport’s validator nodes are constantly listening for new incoming transfers to the “Bridge” account. Once they pick up the latest transaction, they verify the state proof and validate that the memo contains a valid receiving address on Polygon.

3. Paying out Fees:
3.1 hashport validators each create a “scheduled” transaction, equally transferring the service fee amount, to the list of validators. This transfer happens from the “Bridge” account to the “Fee” account.

The “Fee” account is different from the “Bridge” account and is also a multisig threshold account controlled by n of the validators, where n is the number of validators in the set, currently nine. The “Fee” account is used to receive the transaction fees transferred from the “Bridge” account whenever a user locks/unlocks his native assets.

(Example: if the service fee is 0.5%, the scheduled transfer will contain a transfer list crediting 0.5% of the tokens’ value to be locked/unlocked to each of the nine validators.)

3.2 Of the nine scheduled transactions, only one will be executed while all others will fail. All validators, except the validator that successfully created the transaction, sign it, and once 2/3rds of validator signatures are collected, the transfer of fees is executed.

4. Providing Authorisation Signature:
Using their EVM-compatible private keys, each of the validators sign the following authorisation message, specifying:

a) Source chain ID
b) Target chain ID
c) Hedera transaction ID
d) The wrapped token to be minted
e) The recipient’s address
f) The amount to be minted

The authorisation is then submitted to a topic in the Hedera Consensus Service (HCS) and is immutably logged on Hedera for transparency and future audit if required.

5. Waiting for Supermajority:
The user waits for a supermajority of the signatures. He can either watch the topic messages stream or fetch the data directly from Validator nodes.

6. Submitting the EVM Transaction:
Once a supermajority is reached, the user submits the transaction to the Polygon chain, claiming his representative asset Hbar[0x]. The transaction contains the raw data signed in the message:

a) Source chain ID
b) Target chain ID
c) Hedera transaction ID
d) The representative token to be minted
e) The recipient’s address
f) The amount to be minted

7. Mint Operation:
The smart contract verifies that no “Replay attack” is being executed, and confirms the provided signatures against the raw data that was signed. If a supermajority is reached, the EVM contract mints Hbar[0x] to the user’s receiving address.

hash-porting Fungible assets:
From Polygon back to Hedera
The porting of Hbar[0x] from Polygon to unlock HBAR on Hedera is described in the following sequence diagram:

1. Initiating the Transfer:
A user connects a hashport-compatible wallet, and sends a 10 Hbar[0x] burn transaction to the EVM contract, specifying the Hedera account to receive HBAR.

2. Burn Operation:
The smart contract transfers HBAR[0x] from the user’s address and burns them. A “Burn” event is created on the Hedera network, containing the information about the burnt token, the amount and the receiver.

3. Picking up the Transfer:
Validators watch for “Burn” events, and once such events occur, they prepare and submit a “scheduled” transaction that equally transfers the service fee amount to the list of validators, from the “Bridge” account to the “Fee” account.

Again, only one transaction will be successfully executed, and all others will fail. All validators, except the validator that successfully created the transaction, sign it, and once 2/3rds of validator signatures are collected, the transfer of fees is executed.

4. Unlocking the Asset:
Each Validator performs a “scheduled” transaction that unlocks and transfers the amount of Hbar to the receiving Hedera Account. Once 2/3rds of validator signatures are collected, the asset transfer is executed.

Conclusion:
The validators on the hashport network do not communicate with each other but sign and publish authorization signatures and record those using the Hedera Consensus Service (HCS), an immutable, decentralized logging and timestamping mechanism. This tamper-proof auditing mechanism inherits the trust of the Hedera mainnet.

HCS is a powerful truth machine that prevents validators from corrupting the state.

By storing the running hash of topic messages the bridge subscribes to, and periodically collecting the state proof on the very recent messages, only “ONE HONEST VALIDATOR” is required to reveal the true valid state of the bridge.

hashport is a decentralized interoperability solution. Using HCS, the process is made transparent to all, and the validators are able to transfer assets in a trustless manner.

About hashport
hashport is the enterprise-grade public utility that facilitates the movement of digital assets between distributed networks, extending their functionality in a quick, secure, and cost-effective way. In order to remain platform-neutral, hashport functions without the use of a proprietary token. The network is built on a robust and performant architecture, secured and operated by a group of industry-leading validator partners from around the world. hashport has passed a rigorous security audit and follows industry best practices; regularly performing comprehensive network tests to ensure the integrity of the network.

Website | Twitter | Reddit | Telegram | LinkedIn | Github

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
hashport

hashport

Worlds of Possibility. ✨hashport is a public utility that enables fast and secure cross-network transfer of digital assets. $HBAR $ETH $MATIC $DOV $CLXY $JAM