ORBITER’s world view and the way it’s named
ORBITER is a cross-environment base protocol. We found several roles that could improve the system and created related projects in the development process. This system has become a little complicated to facilitate internal communication and external understanding, so the following naming specifications are provided.
ORBITER was able to appear due to the maturity of Rollup technology. In addition to ETH mainnet. We also see products like ZK-Rollup, Arbitrum, Optimism, Loopring, StarkNet, and dYdX, Deversfi that cooperate with Starkware. Just like interstellar exploration, humans will move to other planets to live. However, the spaceways are not open yet, 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 immigration.
ORBITER created a SpacingGuild, built the ORBITER Project, which allowed the WormholeCreators 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 called environment, L1, sidechain, can support smart contract 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 on 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 needs to use cross-environment interoperability.
Wharf: Show ORBITER’s products for Sender, such as wallet, exchange, or any channel.
Navigator: A server that receives Sender’s funds in the A environment and immediately returns the funds in the B environment according to the rules.
Orbiter-Project (OB)
OrbitalModule: OrbitalModule has been deployed and will be open-source soon. 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.
Dashboard: Dashboard will be open-source soon. 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.
ReturnCabin: 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.
SPV: SPV client is in development. 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.
SenderFrontend: SenderFrontend is open-source. 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.
SenderServer: SenderServer is in development. 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)
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.
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.
Navigator-Guide: Access document for Navigator.
WormholeCreator-DevGuide: A developer’s guide to WormholeCreator.
Protocal: Cooperation model with Wharf.
Naming rules:
Project using: prefix-project name
E.g.:
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.
