crypto influencer and enthusiasist
crypto influencer and enthusiasist
Subscribe to Yogesh
Subscribe to Yogesh
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Orbiter Finance is a decentralized cross-rollup bridge for transferring the Ethereum native assets, which is the infrastructure of Layer 2, it offers low cost and almost instant transfers.
*Collect this entry for future benefits*
Safe Orbiter has no risk like other cross-L1 bridges based on the safety rollup technique.
Cheap & Instant The transfer is between the 'Sender 'and the 'Maker’s' EOA (externally owned address) on both 'Source' and 'Destination' networks. 'Senders' don’t interact with the contract address.
For the Ethereum-native assets There is no need to mint assets, so the liquidity can be totally supported in a decentralized way. Liquidity is totally supported in a decentralized way and minting assets is no longer required.
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.
Orbiter-Project (OB)
1.OrbiterModuleOpen sourced: https://github.com/Orbiter-Finance/OrbiterModule
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. 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/OrbiterModule
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. 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.
3.ChainCoreOpen sourced:
chaincore is an open source javascript public library on npm, which is used to encapsulate certain access to various public chain blocks/transactions and other data, transaction queries, balance queries, logs and other operations
4.Orbiter X ContractOpen sourced: https://github.com/Orbiter-Finance/xvm
Orbiter 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:
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 Client
SPV 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-V2
OrbiterEF-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-client
Maker-Client is a client server on Orbiter bridge where makers issue the send back.
8.orbiter-sdkOpen sourced: https://github.com/Orbiter-Finance/orbiter-sdk
Orbiter-Sdk is a Layer2 cross-platform javascript transport that secures and accelerates the Orbiter bridge.
9.Orbiter-OpenApiOpen sourced: https://github.com/Orbiter-Finance/orbiter-openapi
OpenApi 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-example
OpenApi-Example is a case implementation of orbiter-openapi. Refer to this when accessing.
When will the token be released?
The Orbiter team is currently focusing on product development and improving user experience. You can find any announcements from Orbiter on Twitter or Discord.(Link will be available at orbiter.finance
Orbiter Finance is a decentralized cross-rollup bridge for transferring the Ethereum native assets, which is the infrastructure of Layer 2, it offers low cost and almost instant transfers.
*Collect this entry for future benefits*
Safe Orbiter has no risk like other cross-L1 bridges based on the safety rollup technique.
Cheap & Instant The transfer is between the 'Sender 'and the 'Maker’s' EOA (externally owned address) on both 'Source' and 'Destination' networks. 'Senders' don’t interact with the contract address.
For the Ethereum-native assets There is no need to mint assets, so the liquidity can be totally supported in a decentralized way. Liquidity is totally supported in a decentralized way and minting assets is no longer required.
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.
Orbiter-Project (OB)
1.OrbiterModuleOpen sourced: https://github.com/Orbiter-Finance/OrbiterModule
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. 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/OrbiterModule
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. 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.
3.ChainCoreOpen sourced:
chaincore is an open source javascript public library on npm, which is used to encapsulate certain access to various public chain blocks/transactions and other data, transaction queries, balance queries, logs and other operations
4.Orbiter X ContractOpen sourced: https://github.com/Orbiter-Finance/xvm
Orbiter 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:
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 Client
SPV 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-V2
OrbiterEF-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-client
Maker-Client is a client server on Orbiter bridge where makers issue the send back.
8.orbiter-sdkOpen sourced: https://github.com/Orbiter-Finance/orbiter-sdk
Orbiter-Sdk is a Layer2 cross-platform javascript transport that secures and accelerates the Orbiter bridge.
9.Orbiter-OpenApiOpen sourced: https://github.com/Orbiter-Finance/orbiter-openapi
OpenApi 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-example
OpenApi-Example is a case implementation of orbiter-openapi. Refer to this when accessing.
When will the token be released?
The Orbiter team is currently focusing on product development and improving user experience. You can find any announcements from Orbiter on Twitter or Discord.(Link will be available at orbiter.finance
0x6838e53488B9F75894a9fDF9feB509eE22c281dd Arbitrum Görli
0x6838e53488B9F75894a9fDF9feB509eE22c281dd Optimism goerli
0x6838e53488B9F75894a9fDF9feB509eE22c281dd Polygon Testnet
0x6838e53488B9F75894a9fDF9feB509eE22c281dd BSC_Testnet
5.OB_ReturnCabinOpen sourced: https://github.com/Orbiter-Finance/OB_ReturnCabin
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. 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.
Subgraph 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.
0x6838e53488B9F75894a9fDF9feB509eE22c281dd Arbitrum Görli
0x6838e53488B9F75894a9fDF9feB509eE22c281dd Optimism goerli
0x6838e53488B9F75894a9fDF9feB509eE22c281dd Polygon Testnet
0x6838e53488B9F75894a9fDF9feB509eE22c281dd BSC_Testnet
5.OB_ReturnCabinOpen sourced: https://github.com/Orbiter-Finance/OB_ReturnCabin
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. 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.
Subgraph 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.
No activity yet