Skip to main content

Core Concepts

Terminology​

Some important technical terminology is used below. Please reference this section for clarification.

General​

  • Porting Execution - An action of projecting a native token (e.g. HBAR) onto a foreign network (e.g. Ethereum), to be validated and processed by the validator swarm as requested by a User.

Networks​

  • Foreign Network - The destination ("to") network that a native token is projected onto via a Porting Execution. For example, Polygon is the Foreign Network when a User submits a Porting Execution from Hedera to Polygon in order to receive HBAR[0x].
  • Domestic Network - The "from" network which the underlying assets that are being locked or burned via a Porting Execution to received the projected assets. For example, Polygon is the Domestic Network when a User submits a Porting Execution by sending HBAR[0x] from the Polygon network to Hedera.

Assets​

  • Foreign Token - The projected representation of a Native Token onto a Foreign Network via hashport (also referred to as "projected token/asset" or "minted token/asset").
NameToken ID
WETH[hbar]0.0.541564
DOV[hbar]0.0.624505
USDC[hbar]0.0.1055459
WBTC[hbar]0.0.1055483
USDT[hbar]0.0.1055472
AAVE[hbar]0.0.1055498
DAI[hbar]0.0.1055477
LINK[hbar]0.0.1055495
OM[hbar]0.0.1080694
WBNB[hbar]0.0.1157005
WAVAX[hbar]0.0.1157020
  • Native Token - The token that already exists on the Domestic Network. Generally, this would be a token that already has a minted supply, token holders outside of the hashport ecosystem, and other indicators that identify that the token is already in use.
NameToken ID
Supported Foreign Network(s)
JAM0.0.127877Ethereum, Polygon
CLXY0.0.859814Ethereum, Polygon
HBARHBAREthereum, Polygon, Avalanche, BNB Chain
HST0.0.968069Ethereum, Polygon
info

Is your project looking for an interoperability solution? Contact us.

Actors​

  • Users - end-users who want to transfer HBAR or HTS tokens from Hedera to an EVM-based chain or their native or projected assets from an EVM-based chain to Hedera.
  • Validators - entities that are running the hashport validator node. They provide authorization for the minting and burning of projected tokens on the EVM-based chain, as well as transferring projected tokens back to Hedera.
  • Validator Swarm - A governing body responsible for approving porting executions, as well as operating and keeping hashport secure. The validator swarm is composed of validator nodes, wherein each node has entered into an agreement with hashport to participate in the swarm.
  • hashport Portal - the user-interface (UI) in which Users can interact with to move their assets from one supported network to another. Each user accessing the Portal will have their own instance.

Accounts​

  • Portal Account - A Hedera threshold account where funds are transferred through the Portal (Hedera -> EVM) are sent to the Portal Account. The funds are transferred back to Hedera (EVM -> Hedera) are sent from the Portal Account to the recipient's account.
  • Fee Account - A Hedera threshold account where the service fee is proportionally distributed to each validator node after n/m signatures are collected.
  • Hedera Account ID - A Hedera account that is represented by an account ID. More details can be found here.
  • EVM Address - A EVM-compatible wallet address.
  • User Account(s) - One or more accounts that a user has control over, represented by either an EVM Address or a Hedera Account ID.
  • n - threshold value (number of keyholders in consensus)
  • m - number of validators in the validator set

Governance​

The Portal Account and Fee Account are Hedera threshold accounts (n/m), where each validator has a Hedera compatible private key - 1 out of m that has 1/m control over the accounts.

Gnosis MultiSig is used with the same n/m configuration to set up the multi-signature accounts on the EVM chain. Each validator has an EVM compatible private key - 1 out of m that has 1/m control over the multi-signature accounts.

The Gnosis MultiSig is configured as owner of:

  • Wrapped assets deployed on the EVM chain
  • The Router smart contract

Adding / Removing Members​

Validators can add or remove members from the validator set by executing two transactions in the following order:

  1. On Hedera, a Crypto Update transaction that modifies the n/m threshold accounts
  2. On the EVM chain, an updateMember transaction that modifies the list of members in the Router contract

Validators should have an off-chain communication channel to discuss the current setup and vote on adding or removing validator nodes.

Fees​

Validators receive a service fee paid by the user. The fee is a percentage of the transferred amount, paid on the native asset. This percentage is configurable in config/bridge.yml as fee_percentage and determined by the validator set.

The service fee is distributed to the list of validators equally, simply service fee divided by m.