Orbiter Finance — Blockchain Roadmap
Ethereum L2 scaling solutions introduce the bridging problem. Orbiter Finance is a decentralized optimistic bridge application that enables assets to be moved between Rollups. Orbiter Finance works with a system that includes Maker and Sender actors, and the security of the process is ensured by a series of smart contracts.
Ethereum is trying to overcome the scaling problem with Sharding and various L2 solutions. In the process of solving this problem, multiple L2 solutions such as Plasma and State Channels were developed, and finally, Rollups, which are thought to be the most ideal L2 solution, emerged.
Although Rollups are dominant among L2 solutions, regardless of the type of L2 solution used, they all have to be connected to the Ethereum mainnet by a bridge. This situation brings many problems such as liquidity fragmentation and bridging problem. The bridging problem may be an important error in the bridge contract, or it may also be that the shots in Plasma and Optimistic Rollups have a waiting time of 7 days.
Vitalik Buterin talked about multi-chain and cross-chain blockchains, the bridging problem and the impact of 51% attacks on them at the Ethereum Research Team AMA 7 event. There is a remarkable point in Vitalik’s comments. Unlike cross-chain bridge implementations, cross-rollup implementations in 51% of attacks rely solely on the security assumptions of the Ethereum mainnet. That is, when the chain is reversed in a possible 51% attack on Ethereum, the Rollup chains are also reversed. However, cross-Rollup applications that keep the state of the Rollups are guaranteed to remain consistent even if Ethereum is attacked by 51%. This provides room for opportunity and flexibility to develop cross-rollup applications such as Orbiter Finance.
Orbiter Finance is a decentralized optimistic bridge application between Rollups. Orbiter offers users lower transaction fees and higher speed than traditional and native bridges. Orbiter Finance is an optimistic bridge not because it uses fraud-proof. The entire system does not consist of smart contracts and gives the highest efficiency in high-frequency inter-Rollup transactions.
Users can move ETH, USDC, USDT and DAI assets between 13 supported networks. These networks include Optimistic and L1 networks such as zkRollups, Ethereum mainnet, Validium networks, and BSC. Each network is marked with a predetermined identification code. One of the biggest advantages of Orbiter Finance is that it appears as an alternative that shortens this time in networks where the shooting time is long, such as Optimistic Rollups.
In addition to the Bridge application, Orbiter Finance offers an early-stage free L2 data analytics service. By using this service, users can find out the total number of transactions that took place in L2 and L1. It also includes statistics about applications on L2 networks.
Orbiter Finance works with a system that includes Maker, Sender and a series of smart contracts. These smart contracts reside separately on the target chains. Makers provide the necessary liquidity to execute transactions on each supported chain. Senders, on the other hand, are users who want to perform an asset transfer request.
In traditional bridge applications, when it is desired to move assets to a different network, assets are sent to a smart contract. Orbiter Finance, assets are sent to an Externally Owned Account (EOA) instead of a smart contract. This is the most important difference that distinguishes Orbiter Finance from traditional bridge applications. An EOA is an account with a public and private key pair that holds one’s funds. Frequently used Ethereum wallets are also EOA.
When the user wants to move A number of assets from X chain to the Y chain, the process is as follows;
Using the Orbiter Finance interface, the user sends a number of assets and transaction fees in X chain to Maker’s wallet address.
This shipping also includes a fixed transaction fee and a variable transaction fee ranging from 0.04% to 0.3%. At the same time, the last four digits of the number of assets sent are marked with the identification code of the destination chain.
The program run by Maker automatically sends a number of assets from Maker’s wallet to the user’s address in the Y chain using the information obtained.
How can it be sure that Maker will send entity A in chain Y? A number of smart contracts and clients are used to speed up the process and ensure its security. The program used may be open-source software developed by the Orbiter team, or it may be a special software developed by Maker itself. Smart contracts in Orbiter Finance;
Maker Deposit Contract(MDC): The MDC contract has two tasks. It is to keep Maker’s deposit and to return the user’s existence and pay compensation for transactions that do not occur or are not correct.
Event Binding Contract(EBC): The task of the EBC contract is to set the deposit rules in Maker’s different Rollups and to provide communication between the sourcing process and the target process.
Simple Payment Verification(SPV): The task of the SPV contract is to prove the existence of the originating transaction in the originating network.
The user provides proof of SPV contract Source Transaction 1.
The user initiates the arbitration through the MDC contract.
The MDC contract receives proof of the existence of Source Transaction 1 from the SPV contract.
The MDC contract receives proof of the validity of Source Transaction 1 from the EBC contract. Thus, the MDC contract can check that Source Transaction 1 occurs according to the Orbiter’s format and rules.
MDC provides Maker with a waiting period of 30–180 minutes to provide proof of Target Action 1.
If the Maker provides proof of Target Transaction 1 to the MDC contract, the MDC contract takes the proof of the validity of Target Transaction 1 from the EBC contract and verifies that Target Transaction 1 matches Source Transaction 1. The MDC contract closes arbitration and shows the user Target Transaction 1.
If Maker does not provide proof of Target Transaction 1 to the MDC contract by the end of the waiting period, the user applies for withdrawal of assets.
The MDC contract sends the amount corresponding to the user’s assets and some compensation (approximately 15 USD) from the Maker’s deposit to the user. The transmission takes place on the network where the MDC contract is located.
Makers provide liquidity for transactions and earn returns by charging fixed and variable transaction fees without any risk of temporary loss. Makers tend to be honest because they have to pay compensation when they are dishonest. However, Maker may tend to be dishonest when the size of a transaction amount sent to Maker is greater than Maker’s deposit amount. For this reason, Orbiter Finance has an upper limit on transactions. Additionally, the Makers deposit amount is determined by Orbiter Finance through a set of rules;
In EVM chains, blocks are divided into 5–10 equal parts. The amount that Maker must deposit into the MDC contract is found by the formula [(number of pieces) x (transaction upper limit)]. Currently, in EVM chains, this formula becomes [(5–10) x (10 ETH)] = 50–100 ETH.
In non-EVM chains, blocks are split into 100–200 equal parts. The amount that the Maker must deposit in the MDC contract is currently calculated with the formula [(100–200) x5 ETH] = 500–1000 ETH.
The liquidity currently in Orbiter Finance is provided by the Orbiter team. The Maker in the protocol is actually the team itself. The team states that the necessary improvements to decentralize and permissionless the Maker system are 80% complete.
In addition to ERC-20 support, Orbiter Finance has ERC-721 support on its roadmap for the future. That is, when the developments are completed, NFTs will be able to be moved to different networks via Orbiter Finance.
When we look at the number of transactions performed in Orbiter Finance, it is seen that the number of transactions has increased. This can be explained by the increase in the number of chains supported by the application or by the existence of networks such as StarkNet where it takes a long time to use local bridges.
Looking at the types of assets transferred from the Ethereum network to other chains using Orbiter Finance, ETH is 42.4%, and the most bridged assets after ETH are USDC, USDT and DAI, respectively.
Networks Supported by Orbiter Finance; Ethereum, zkSync, Polygon, Arbitrum, Arbitrum Nova, Loopring, Optimism, ZKSpace, Immutable X, Metis, Boba, StarkNet, BNB Chain
Orbiter Finance is still a very new and early-stage application. It is an ideal solution for shortening long shooting times in rollup networks. However, there are some points that are not clear in the application’s documentation and system;
Orbiter Finance claims to be resistant to 51% of attacks. This is true for Rollups, but what would be the result of this attack vector considering chains like Metis or BNB Chain?
Orbiter’s SPV contract is not open source. When the documents are examined, it is seen that the SPV contract is still under development. If Maker does not send users’ assets on the target chain, no application for refunds and compensation can be made if there is no working SPV contract. There is also no interface where users can initiate refund and compensation transactions.
Another important point is the program and wallet used by Makers. Since the program is run off-chain, additional security assumptions may be needed, even if it is open-source software. A critical vulnerability may exist in the program and it is not possible to be sure whether Maker has updated its program. The environment in which the software is run may be subject to its own security assumptions, or Maker’s wallet may be compromised.
Orbiter Finance smart contracts are not audited. The Orbiter Finance team explained this as the implementation is still at an early stage.
Orbiter Finance can be used for compelling reasons or uncontrollable hacker attacks, communication line outages, etc. It has stated in its documents that it has no responsibility as the manufacturer of the application for service interruptions or other malfunctions that cause users to not be able to use it normally. In the system where there is no SPV contract and therefore no reimbursement and compensation processes are in effect, the only response will be the Maker, namely Orbiter Finance in the current situation. Orbiter Finance may choose not to accept responsibility in the event of a possible event.
Considering Ethereum’s Rollup-oriented roadmap and the emergence of different Rollup solutions every day, Orbiter Finance gains importance. However, in line with the listed and unlisted risks, the information on the Orbiter interface is insufficient, users should understand these risks well before using the application and accept that the risk belongs to them.
See you in next article…
New to trading? Try crypto trading bots or copy trading
