Orbiter
Search…
⌃K

Overview

Introduction

Orbiter Finance is designed as a decentralized cross-rollup bridge for transferring Ethereum-native assets. The system has two roles: Sender and Maker. The 'Maker' is required to deposit excess margin to Orbiter's contract before they can qualify to be a cross-rollup service provider to the 'Sender'. In the usual process, the 'Sender' sends assets to the 'Maker' on the 'Source Network', and the 'Maker' sends back to the 'Sender' on the 'Destination Network'. There are 3 types of smart contracts in Orbiter's security model.
  • MDC: 'Maker' Deposit Contract, keep Maker’s Margin, handle the arbitration for 'Sender'.
  • EBC: Event Binding Contract, store the margin rules and Makers’ charging standards.
  • SPV: Simple Payment Verification. This proves the existence of the transaction in Orbiter. Orbiter's technology creates SPV for every domain supported. MDC, EBC, and all the SPVs are deployed on one domain that supports smart contracts in the Ethereum ecosystem. Learn more details by reading Technology.

Worldview

ORBITER's worldview and the named way We found several roles that could improve the system and create related projects in the development process. This system has become a little complicated to facilitate internal communications and external understanding, so the following naming specifications are provided.

Worldview

Orbiter was created because of the maturity of Ethereum Layer2 Rollup technology. In addition to Ethereum mainnet, we also see products like ZK-Rollup projects(zkSync, Scroll, etc.), Arbitrum, Optimism, Loopring, StarkNet, and dYdX, Deversfi(rebranded as Rhino) on StarkNet. Just like interstellar exploration, humans will move to other planets to live. However, the spaceways are not yet open, it is precisely because humans cannot move their supplies quickly and safely between the stars. In addition to these Rollup-based L2 planets, there are BSC, Matic, xDai sidechain planets. There are migrants on these planets, many of whom wanted to travel between them but were discouraged by the high cost of interplanetary travel while moving supplies. To this end, Orbiter is working to build an organization like Dune's SpacingGuild in the multi-chain universe, making the cheapest and safest route through the complex space environment and fulfilling all the needs of interstellar journey.

Naming and Explanation

Orbiter created a SpacingGuild, built the Orbiter Project, which allowed the Wormhole creators to make the shortest route by building fuel supply stations along the way. The Sender's supplies are loaded at the planet's Wharf, and the Navigators take them through the Wormhole to the destination.
Planet: Also known as environments, L1s, sidechains, who can support smart contracts or not.
SpacingGuild: The rule-maker of a cross-environment interoperating system will be a DAO in the future.
Orbiter Project: A series of open-source tools and smart contracts for cross-environmental interoperability requirements, detailed in the project name section.
Wormhole: Develop customized protocols on the interoperating system, such as cross-environment transfer of the same tokens, NFT, different tokens, and more possibilities we haven't thought of yet.
WormholeCreator: They are developers who develop customized protocols in the interoperating systems.
SupplyStation: A smart contract built on each environment serves as a liquidity pool for Navigator to balance the liquidity balance by accepting LP deposits.
Sender: User who uses the cross-environment interoperability systems.
Wharf: Shows ORBITER's products for 'Senders', such as wallet, exchange, or any channel.
Navigator: A server that escrows Sender's funds in the Source network and immediately sends the funds to the Destination Networks according to the rules.

Project

Orbiter-Project (OB)
  1. 1.
    OrbitalModule
    Open sourced: https://github.com/OrbiterCross/OrbitalModule
    A Docker project is written in js, deployed in the EC2 server, and has no external exposed port. It is always online and responds to the Sender's needs via RPC data. It is a tool provided to Navigator.
  2. 2.
    Dashboard
    Open sourced: https://github.com/OrbiterCross/OrbitalModule
    A docker project is written in js, deployed on an EC2 server, or run locally. Establish a database through RPC data and display the operation status of Maker's addresses in statistical tables. Navigator can adjust the strategy in time by combining this tool with Metamask.
  3. 3.
    ReturnCabin
    Open sourced: https://github.com/OrbiterCross/V2-contracts
    A series of smart contracts developed by Solidity, be deployed in Rinkeby during the test stage. They will be deployed in the ETH mainnet or a stable Rollup during the official phase. Anyone can become a Navigator by depositing a margin in ReturnCabin and making promises. ReturnCabin ensures that in the worst case, such as OrbitalModule failure or Navigator is bad behavior, and Sender can still get the margin from ReturnCabin.
  4. 4.
    SPV (Developing)
    It is a hybrid project, the supporting facilities of ReturnCabin. Each ORBITER supported environment will have a corresponding SPV-Contract.sol and SPV-ProofCreater.js. The deployment environment of SPV-Contract.sol is the same as ReturnCabin, and SPV-ProofCreater.js will be deployed In Sender Server, open-source at the same time. SPV has no permission to control, and anyone can use it. It is some of OBITER's contributions to the community. We are currently developing some SPV environments, such as ETH-MainNet (need to support EIP-1559), zkSync, Arbitrum, Optimism, Loopring, StarkWare.
  5. 5.
    SenderFrontend
    Open sourced: https://github.com/OrbiterCross/OrbiterFE-V2
    It is based on Vue + web3.js and is a front-end tool that makes it easy for the Sender to use the ORBITER service. Deployed in the EC2 server and deployed to ipfs in the future, Users can also run the project locally. ORBITER is an entirely on-chain-driven protocol so that the Sender can use our protocol even without SenderFrontend.
  6. 6.
    SenderServer (Developing)
    It is based on Node.js, on the Dashboard project, and deployed in ORBITER's EC2 server. It is an auxiliary project, and the purpose is to improve the responding speed of SenderFrontend, which does not involve any transfer-related operations.
SpacingGuild (SG)
  1. 1.
    Agreement-Contract
    A series of smart contracts written based on Solidity, the deployment environment is the same as ReturnCabin, keeps SpacingGuild funds, and computes revenue distributions for all contributors in the SpacingGuild.
  2. 2.
    SupplyStation-Contract
    A series of smart contracts written based on Solidity are deployed in each EVM-enabled planet. Accept LP deposits and provide services for Navigator to balance the liquidity balance.
  3. 3.
    Navigator-Guide
    Access document for Navigator
  4. 4.
    WormholeCreator-DevGuide
    A developer's guide to WormholeCreator
  5. 5.
    Wharf-Protocol
    Cooperation model with Wharf
Naming rules:
Project using: prefix-project name
Eg:
Orbiter-Project OrbitalModule is OB-OrbitalModule.
Orbiter-Project SPV is OB-SPV.
Orbiter-Project Sender Frontend is OB-SenderFrontend.
SpacingGuild Agreement-Contract is SG-AgreementContract.

Milestone

Video

This video demonstrates how to transfer in Orbiter.