> For the complete documentation index, see [llms.txt](https://docs.orbiter.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.orbiter.finance/welcome/other-projects.md). # Other Projects **Orbiter Module** Open sourced: 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 theSender's needs via RPC data. It is a tool provided to Navigator. **Dashboard** Open sourced: A docker project is written in js, deployed on an EC2 server, or runlocally. 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 withMetamask. **ReturnCabin** Open sourced: A series of smart contracts developed by Solidity, will 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 Navigatoris bad behaviour, and Sender can still get the margin from ReturnCabin. **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 InSender Server, open-source at the same time. SPV has no permission to control, and anyone can use it. These are some of OBITER's contributions to the community. We are currently developing someSPV environments, such as ETH-MainNet (need to support EIP-1559), zkSync, Arbitrum, Optimism, Loopring, StarkWare. **SenderFrontend** Open sourced: 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 (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)** 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** **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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.orbiter.finance/welcome/other-projects.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.