Overview

This article describes HyperLoop, a protocol for sending tokens across EVM and Non-EVM chains in a quick and trustless manner. The secure bridge infrastructure layer has a lot of potential use cases for scaling new chains, executing cross-chain arbitrage opportunities and contract interaction between chains. But most of the current bridge infrastructure implementations have a non-optimal architecture for such cases, security breaches, slow speed, high costs, and non-capital-efficient for liquidity providers. The HyperLoop protocol allows assets to be moved directly from chain to chain, providing cost savings, high APY for liquidity providers and enabling cross-chain composability of applications.

HyperLoop Protocol

The HyperLoop protocol provides a scalable chain-to-chain, General Token Bridge, using the next approach:

1. Create a cross-network bridge token that can be quickly and economically moved using rollups to layer-2 for its underlying asset.

2. Use Automated Market Makers to swap between each bridge token and its corresponding Canonical Tokens on each rollup in order to dynamically price liquidity and incentivize the rebalancing of liquidity across the network.

The combined approach allows users to quickly and trustlessly swap between layer-2 Canonical Tokens using the specialized bridge token as an intermediary asset.

2.1 Rollup Speedup

For L1>L2 and L2>L1 bridge transactions the HyperLoop protocol uses the rollup infrastructure as a layer to move assets cross-chain and speed up this transaction with an executors network. Rollups reduce the number of calculations in the main chain by processing transactions off-chain, offering significant improvements in processing speed. Accumulative packages gain security from the main network by publishing the results of transactions in the chain, which verify transactions in the main network with evidence of fraud, but store transaction data elsewhere. Cumulative packets perform transactions outside of Layer 1, but send transaction data to the main network as calldata files. Pooling operators combine multiple transactions offline in large batches before sending them to Layer 1. This approach allows you to distribute fixed costs for several transactions in each package, reducing the commission for end users. To use an optimistic accumulative package, users deposit accepted assets into the bridge contract of the accumulative package on Layer 1. The bridge contract will transfer the transaction to the L2 level, where an equivalent amount of assets is minted and sent to the address selected by the user with an optimistic rollup. User-generated transactions (for example, deposit L1 > L2) are usually queued until the operator resends them to the accumulative contract. Delays in completing a transaction due to potential fraud problems can stretch long enough, making it difficult to transfer assets and arbitrage liquidity between networks.

2.2 Bridge Liquidity

The protocol uses an add-on over the main rollup contract in the form of the release of intermediate synthetic assets, which also undergo the blocking procedure in Layer 1 and the release of mint in Layer 2, forming a pool of liquidity from a synthetic asset with the native asset of the bridge of Layer2. Ultimately the synthetic asset of the protocol and the asset form a pool curve in a narrow range between themselves, which allows you to provide a quick exchange between tokens.

A synthetic asset is needed in additional settings that will enable you to quickly exchange assets between networks. In addition, liquidity providers in layer 2 receive a commission from each bridge transfer, thereby gaining motivation to ensure the protocol's operability.

The commission is configurable for different types of assets from 0.05% to 0.3%.

2.3 Executor Network

To avoid waiting for the rollup event, the operator monitors the TransferRoot events in the source network and initiates the mint of a synthetic token asset in the destination network. The transaction is created taking into account the exchange of a synthetic asset for a canonical asset in the destination network. For the operator to be able to carry out the mint, he must have a sufficient amount of collateral. If the operator confirms an invalid bridge transaction either maliciously or due to an error, any network participant can challenge it.

The protocol uses economic incentives to challenge fraudulent transactions. The operator must block 110% of the total cost of the transfer as collateral (security deposit). In case of a fraudulent transaction, 10% will be sent to the person who detects the fraud. In contrast, the cost of the fraudulent transaction is covered by the operator's collateral. The Executor cannot steal any funds. The Executor can speed up transfers only by providing collateral. In the worst case, when the Executor goes offline, your transfer will take the same time as the time the asset exits rollup. The operator may demand to return its collateral using the root transfer on the Layer-2 storage package as proof.

2.4 HyperLoop

Bridge Tokens HyperLoop Bridge Tokens (e.g., ”Loop ETH”, ”Loop DAI” with symbols ”loopETH”, ”loopDAI” respectively) are specialized layer-2 tokens that can be transferred rollup-to-rollup in batches and act as intermediary assets in the HyperLoop protocol. Each HyperLoop Bridge Token represents a deposit in the layer-1 HyperLoop Bridge contract. For example, if 4 ETH are deposited into the layer-1 HyperLoop Bridge contract, 4 Loop ETH can be minted from a layer-2 Loop Bridge contract. Inversely, a HyperLoop Bridge token can be redeemed for its underlying asset on layer-1, which burns the HyperLoop Bridge Token being redeemed on layer-2. When a HyperLoop Bridge Token is transferred from rollup to rollup, it is burned on the origin rollup and minted on the destination rollup. As explained below, these immediate transfers are accomplished by allowing an ”Executor” to front liquidity on the destination in exchange for a small fee. The Bonder’s liquidity is returned when the transfer eventually propagates through layer-1 as part of a larger bundle called a ”Transfer Root”.

2.4.1 Transfer

A HyperLoop Transfer includes the following information:

• Destination chain ID - The chain ID of the rollup or layer-1 destination

• Recipient - The address receiving the Transfer at the destination

• Amount - The amount of token being transferred

The Transfer may also include additional information for convenience functionality. For example, it may specify a relayer fee to allow a transaction relayer to withdraw the Transfer at its destination on behalf of the user.

2.4.2 Transfer Root

A Transfer Root represents a bundle of Transfers with minimal data. Each Transfer Root is composed of

1. A Merkle root of the Transfers

2. An array of each unique destination is represented by its chain ID

3. An array of total amounts being sent to each unique destination

A Transfer Root can contain thousands of Transfers yet be accounted for on layer-1 as a single bundle. This alleviates the layer-1 bottleneck and allows a large number of transfers to be passed through layer-1 to their destination rollups in a scalable way. However, propagating a Transfer Root through layer-1 can be a slow process. This is primarily due to the exit time of the rollup that the Transfer Root originated on. In order to fulfill Transfers immediately, an external party can provide up-front liquidity on the destination rollup for a small fee, as described in this next section.

2.4.3 Transfer Bonds.

Bridge Speed-up The Executor can verify that the Transfer was made on its origin rollup by running a verifier node for the rollup. The Bonder can then provide up-front liquidity on the destination rollup in order to fulfill the Transfer immediately. Eventually, when the Transfer has reached its destination, the Bonder’s funds are restored. The Bonder may take a small fee in exchange for locking up liquidity while the Transfer is propagating through the system. The immediate liquidity provided by Transfer Bonds and scalability achieved with Transfer Roots enables HyperLoop Bridge Tokens to be quickly and economically moved from chain to chain.

2.5 Automated Market Makers.

Liquidity Pools Each HyperLoop Bridge Token represents a layer-1 token and can be quickly and economically moved from chain to chain. Under normal network conditions, each HyperLoop Bridge Token is worth exactly 1 of its L1 counterpart because it can be redeemed on layer-1 at any time. However, third parties on each rollup are not likely to adopt HyperLoop Bridge Tokens directly. It is more likely that the Canonical Tokens they adopt are produced by the rollup’s Native Token Bridge or an Application-Specific Token Bridge as previously discussed. To complete the bridge between the layer-1 token and its Canonical layer-2 counterpart, an Automated Market Maker (AMM) can be deployed to enable swaps between each HyperLoop Bridge Token and its corresponding Canonical Token (e.g., HyperLoop ETH - Canonical L2 ETH).

This market provides a pricing mechanism for liquidity on a given rollup and also acts as an incentivization mechanism for Arbitrageurs to rebalance liquidity in response to market movements.

2.5.1 Arbitrageurs

Arbitrageurs are an external, unsanctioned group of actors in the HyperLoop protocol. The Arbitrageur’s role is to take advantage of price differences between layer1 tokens and their Canonical layer-2 counterparts. By taking advantage of these price differences, Arbitrageurs effectively rebalance liquidity across the supported chains. Consider the following scenario with a layer-1 network and a single chain supported by a HyperLoop Bridge. A user has ETH on the rollup, and they want to move it to layer-1 immediately. They use the HyperLoop Bridge because using the Native Token Bridge would subject them to the rollup’s exit time. First, their ETH will be swapped for HyperLoop ETH (loopETH) using the ETH:loopETH AMM on the L1 chain. Then, the HyperLoop ETH can be burned on the rollup and redeemed for layer-1 ETH. Because exiting over the HyperLoop Bridge involved selling ETH into the ETH:loopETH market, it caused ETH to be priced at a small discount to Loop ETH. If this discount becomes large enough (e.g., 1.005 ETH/loopETH), the Arbitrageur moves layer-1 ETH across the HyperLoop Bridge to receive HyperLoop ETH. The HyperLoop ETH is then used to purchase the discounted layer-2 Canonical ETH. The Arbitrageur may now choose to move that layer-2 Canonical ETH back to layer-1. Because they do not want to trade back into the market they just arbitrage and lose their profits, they will exit via the Native Token Bridge and take on the liquidity lock up.

2.5.2 Liquidity Providers

Each AMM requires Liquidity Providers to contribute passive liquidity to the AMM’s liquidity pool. In return, Liquidity Providers are rewarded with a small fee from each swap (e.g., 0.3%). Typically, Liquidity Providers also risk incurring what is known as ”impermanent loss”.

Impermanent loss occurs when the assets in an AMM diverge in price. Because AMM pairs in the HyperLoop protocol are always assets of similar value, HyperLoop Liquidity Providers have a very low risk of impermanent loss under normal network conditions. Additionally, the AMM’s price curve can be optimized for assets that trade within a narrow range.

2.6 Rollup-to-Rollup Transfers

With both the HyperLoop Bridge Token and markets on each rollup to swap between the HyperLoop Bridge Token and the Canonical Token, users can quickly and easily convert from one rollup’s Canonical Token to the next. Rollup-to-rollup transfers through the HyperLoop protocol are highly scalable because individual transfers do not require any layer-1 transactions. Consider the following scenario where Alice has Rollup A Canonical ETH and wants Rollup B Canonical ETH:

1. Alice swaps her Rollup A Canonical ETH for Loop ETH using the AMM on Rollup A.

2. Alice then uses the HyperLoop Bridge to send her Loop ETH from Rollup A to Rollup B.

3. Once the Bonder provides liquidity for her Transfer, Alice receives Loop ETH on Rollup B.

4. Alice can now swap her Loop ETH for Rollup B Canonical ETH using the AMM on Rollup B. 8

Eventually, her Transfer propagates through the L1 HyperLoop Bridge, and the Executor’s liquidity is returned. For convenience, Alice can also make her cross-rollup transfer by making a single transaction. She makes a call to the HyperLoop Bridge, which performs a swap from Rollup A Canonical ETH to HyperLoop ETH for Alice using the AMM and then sends the Loop ETH to its destination. This time, the Transfer is sent with instructions to automatically swap Loop ETH for Rollup B Canonical ETH at the destination. This convenience functionality also makes it easy for other smart contracts to interact directly with the HyperLoop protocol and make cross-rollup transfers. It is important to note that Alice’s Transfer was completed with only layer-2 transactions in both cases. The layer-1 HyperLoop Bridge strictly deals with batches of Transfers rather than individual Transfers themselves. This allows thousands of rollup-to-rollup Transfers to be completed with minimal layer-1 interaction.

3 HyperLoop Bridge Fees

There is no simple answer to this question as the overall cost of your transfer will depend on various factors.

3.1 AMM swap fees (0.01-0.5%)

When you transfer e.g USDC from Optimism to Arbitrum your USDC will be converted into loopUSDC in the USDC AMM on Optimism costing a 0.05% fee.

Then this loopUSDC will be burned and an Executor will bond your transfer by locking his collateral and mint you some new loopUSDC on Arbitrum.

This loopUSDC will now be converted in the Arbitrum USDC AMM for canonical USDC costing another 0.05%.

L2 <> L2 -> 0.1% swap fees (because two swaps) L2 -> L1 -> 0.05% (because only one swap)

3.2 Slippage (0.5-2%)

Depending on the liquidity in the AMM's the rate for conversions between Loop Tokens and canonical tokens can fluctuate and eat into the cost of your transfer. With more liquidity in the HyperLoop protocol and actors arbitraging the pools this should become less and less of a problem.

3.3 Executors fee (0.06-0.25%)

The Executor takes a fee for fronting the liquidity of your transfer at the destination chain and taking on risk.

The fee varies per asset and per route based on the transaction volume and other factors due to economies of scale. If there is a lot of demand for an asset, Executors' fees can be lowered while still breaking even. 3.4 Destination chain tx fee (gas fees)

The funds need to be sent from the Executor to your wallet and users need to pay for this gas cost. This gas cost is factored into the fee the user pays on the origin chain and displayed before sending.

4 Areas for Further Research

Scaling and development of the protocol requires improved functionality and increased user convenience. $Loop Governance initially lays the grant program in the development of the ecosystem.

4.1 Network Support

Initially, the protocol supports Ethereum, Polygon, Optimism, Arbitrum, BNB Chain. We also plan to scale a protocol for non-EVM networks (Solana, Tron, Aptos). Adding a new network requires coordinated actions by Governance to set up assets, liquidity pools, and voting.

4.2 Zap Bridge

Currently, the protocol supports sending one token ticker to another network. Still, it is also possible to set up additional contracts for the aggregation of exchange and conversion of assets with different tickers and more complex DeFi products.

4.3 Gasless bridges

Gas-free deposits will help attract new users to the dapp application on L2. In this case, sending a TX in Dapp from Layer 1 to Layer 2 Dapp without a native token to pay for gas per transaction is possible.

4.4 Bridge Rollup

Combining the functionality of Rollup EVM networks with non-EVM networks will be necessary. A hybrid storage package can serve as a solution that will interact with EVM Layer 1, and Layer 2 data and help carry out batch message transmission and interaction with non-EVM networks. 4.5 WatchTower Infrastructure that provides monitoring of bridge transactions and Executors. WatchTower allows you to catch malicious transactions, fine and kick out the Executors from the network. The infrastructure is also responsible for entering the addresses of hackers on different blockchains in the blacklist of the bridge.

5 Governance token

HyperLoop uses two tokens to manage its utility and management: Loop— service token of the ERC-20 protocol gLoop— ERC-721 management token in the form of NFT (non-interchangeable token). It is used to reward liquidity providers through issuance.

gLoop is used for protocol governance. Users can deposit their Loop tokens and receive a gLoop in return (also known as veNFT). Additional tokens can be added to gLoop at any time. 5.1 Governance gLoop Depositing a Loop and receiving a gLoop voting token has a ratio, not 1:1, as in other protocols, but it depends on the blocking period, for example:

• 6 months: Get 0.125 gLoop for 1 Loop;

• 2 years: get 0.5 gLoop for 1 Loop;

• 4 years: Get 1 gLoop for 1 Loop.

gLoop holders receive the following benefits:

• Fees generated by the pools they vote for;

• A significant part of the new Loop issue;

• The right to vote on which AMM pools should be stimulated;

• The right to vote on which networks and assets to connect to the protocol;

• The right to vote on where to distribute grants.

gLoop holders decide which liquidity pools will receive an issue in a given era by voting on their preferred liquidity pool indicators. The gLoop issue will be distributed proportionally to the total number of votes received by the liquidity pool. In return, voters receive 60% of the trading fees and commissions collected through the liquidity pool they vote for.

Voting for rewards or any gLoop-related actions, in general, is allowed only once per epoch. The Voter.reset call is used to reset the NFT voting state and is usually required before merging it with another gLoop or Voter.poke used to re-vote for the current epoch to direct the issue and receive rewards is considered an action for the current epoch.

$Loop token will be a part of the multi-chain meta-governance infrastructure of $PPAY and Plasma.Finance. The treasury and fees will be managed by token holders of both tokens.