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.
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.
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.
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 dock, 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.
Sender: User who uses the cross-environment interoperability systems.
Maker: Provider who provide the cross-rollup service.
Dock: 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.
- 1.OrbiterModuleOpen sourced: https://github.com/Orbiter-Finance/OrbiterModuleA 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. Orbiter Module consists of a Maker Service and a Dashboard Service. The Maker Service relies on the chaincore library. When the chaincore service detects a transaction taking place at the maker's on-chain address, it will notify chaincore subscribers. The dashboard service primarily offers a Maker administration page for examining transaction history, real-time balances, and matching status, among other things.
- 2.DashboardOpen sourced: https://github.com/Orbiter-Finance/OrbiterModuleA 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. MakerTransactionData may retrieve data on chain and handle transaction data. It is primarily used to synchronise all on-chain maker-related transactions with the local database and push transactions to other services.
- 4.Orbiter X ContractOpen sourced: https://github.com/Orbiter-Finance/xvmOrbiter X Contract is a contract that supports cross-address, cross-currency and bulk payback. It can be invoked to third parties and will greatly improve access efficiency. Testnet contract address:0x6838e53488B9F75894a9fDF9feB509eE22c281dd Goerli0x6838e53488B9F75894a9fDF9feB509eE22c281dd Arbitrum Görli0x6838e53488B9F75894a9fDF9feB509eE22c281dd Optimism goerli0x6838e53488B9F75894a9fDF9feB509eE22c281dd Polygon Testnet0x6838e53488B9F75894a9fDF9feB509eE22c281dd BSC_Testnet
- 5.OB_ReturnCabinOpen sourced: https://github.com/Orbiter-Finance/OB_ReturnCabinA 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. OB_ReturnCabin is an implementation of the Orbiter cross-rollup bridge. In order to function as an infrastructure, a generic business model must be abstracted from the actual requirements, including the need for cross-chain transactions with the same or different currencies and NFT transactions. Two roles in Orbiter: the Sender initiating events in the source network and the Maker in the destination network responding to the events.
Three contracts and modules in Orbiter system:
- MDC (Maker Deposit Contract)Main functions: holds the Maker's deposit, resolves disputes, handles refunds and compensation.
- EBC (Event Binding Contract)Validate the corresponding target Tx based on the source Tx.
- SPV Light ClientSPV comes with ReturnCabin, a Solidity-based Proventh.sol and a go-based SPV-Client, all of which are open source. They are deployed in Goerli during the testing phase and will be deployed in the main ETH network upon launch; therefore, there is no rollup deployment. There is no permission limit for SPV, with the exception of data validation for SPV-Client. The SPV environments that we've created are as follows: ETH-Mainnet, Optimism, Arbitrum, Zksync.
- 6.OrbiterFE-V2Open sourced: https://github.com/Orbiter-Finance/OrbiterFE-V2OrbiterEF-V2 is the front-end of Orbiter bridge and entrance of cross-rollup, where users can access to https://www.orbiter.finance/.
- 7.MakerClientOpen sourced: https://github.com/Orbiter-Finance/maker-clientMaker-Client is a client server on Orbiter bridge where makers issue the send back.
- 9.Orbiter-OpenApiOpen sourced: https://github.com/Orbiter-Finance/orbiter-openapiOpenApi is an open interface for cross-chain service. Third-party can access applications/DApps chains and cross-chain routes Orbiter supports.
- 10.Orbiter-OpenApi ExampleOpen sourced: https://github.com/Orbiter-Finance/openapi-exampleOpenApi-Example is a case implementation of orbiter-openapi. Refer to this when accessing.
- 11.SubgraphOpen sourced: https://github.com/Orbiter-Finance/subgraphSubgraph is a dynamic tracking of any Maker created by Orbiter, transaction pairs, Maker operation logs and other on-chain data. It tracks the state of Orbiter contracts and contains historical data and derived statistics such as Maker pledges. These subgraphs are hosted on The Graph and can be used to query Orbiter bridge data.