Orbiter Finance: Decentralized Cross-rollup Bridge
Orbiter Finance is designed as a decentralized cross-rollup bridge for transferring the 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 or 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.
Features of Orbiter Finance
1.Safe：
Orbiter has no risk like other cross-L1 bridges based on the safety rollup technique.
2.Cheap & Instant：
The transfer is between the ‘Sender’ and the ‘Maker’s’ EOA address on both ‘Source’ and ‘Destination’ networks. ‘Senders’ don't interact with the contract address.
3.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.
Operating Mechanism
Orbiter's specific mechanism:
The remarkable difference between Orbiter and other bridge protocols is that the funds are transferred to the Maker's EOA address, and not to a contract address.
‘Makers’ can develop and run a client to provide the service automatically or use the Orbiter team's open-sourced client: https://github.com/Orbiter-Finance/OrbitalModule/tree/eth_pro_new.
After the ‘Sender’ sends the funds to the ‘Maker’ on the Source Network, the ‘maker’ is now required to send it back to the ‘Sender’ on the Destination Network. The ‘Maker’ needs to know the token type, amount to send to the ‘Sender’, and which chain (Destination Network) it is on.
The ‘Maker’ gets these three parameters from:
1.Token types and send-back amount:
‘Makers’ need to set the withholding fee (a fixed fee), the trading fee, and supported token types when depositing the margin in Orbiter's MDC contract. These set parameters will be kept in Orbiter's EBC contract and synced updates with Makers' clients. ‘Makers’ know the send-back token type and calculate the send-back amount after receiving Senders' funds in this way.
2.Destination network:
Orbiter uses "Identification Code" to record the Destination Network. The correspondence between Security Code and Destination Network is also kept in the MDC contract. ‘Senders’ need to add a Security Code at the end of the decimal point of the transfer amount. Then, the ‘Maker’ will know which the Destination Network is.
‘Makers’ are motivated to send back to ‘Senders’ instantly and correctly.
In Orbiter's mechanism, ‘Makers’ can get considerable income (with no impermanent loss risk) from every service.
Contract System Design
There are three types of smart contracts in Orbiter's system:
1.MDC contract (Maker Deposit Contract):
MDC contract has two functions - keep Makers' margin and handing the send-back and compensation for ‘Senders’.
2.EBC contract (Event Binding Contract):
EBC contract is used to make the validity proof of Source Tx and Destination Tx. EBC also keeps the rules of Orbiter: ① The rule for the ‘Maker’ to deposit margin on different rollups. ② The rule of the correspondence between the Source Tx and Destination Tx.
3.SPV contract (Simple Payment Verification):
SPV is used to make the existence proof of Source Tx on the Source Network.
The Mechanism of MDC, EBC, and SPV cooperate to resolve a dispute for the ‘Sender’:
Once the ‘Maker’ didn't send back to the ‘Sender’ correctly, the following steps will be happened in sequence to help the ‘Sender’ get the tokens:
-
The ‘Sender’ needs to provide the relevant Source Tx to SPV.
-
The ‘Sender’ initiates the arbitration through Orbiter's MDC contract.
-
MDC gets the existence proof of Source Tx from SPV and knows the Source Tx has happened on the Source Network.
-
MDC gets the validity proof of Source Tx from EBC. MDC will know that the Source Tx is legally based on Orbiter's rules; the Source Tx was sent from a ‘Sender’ to one of Orbiter's Makers with a legal Security Code.
-
Then, MDC will set this arbitration as a pending case and wait for the ‘Maker’ to provide the Destination Tx for 0.5-3 hours (This function can be aggregated in the Maker's client, so the ‘Maker’ will not miss it). If the ‘Maker’ can provide a correct Destination Tx, MDC will get the validity proof from EBC and know the Destination Tx matches the Source Tx. MDC will close this arbitration and show the Destination Tx to the Sender. But, if the ‘Maker’ cannot provide the relevant Destination Tx after 0.5-3 hours, the ‘Sender’ can apply the withdrawal and then go to the next step.
-
MDC starts to compensate the ‘Sender’.
-
MDC will send the tokens and compensation (~$15) back to the ‘Sender’ on the domain where the MDC deployed. The send-back tokens and compensation come from the Maker's margin.
Networks currently supported by Orbiter:
Ethereum Mainnet、zkSync、StarkNet、Polygon、Arbitrum、Optimism、Immutable X、Loopring、ZKSpace、dYdX、Metis
Orbiter's fee consists of Trading Fee and Withholding Fee.
Trading Fee: Fees paid to the platform and Maker that is charged as a percentage of the transfer amount.
Withholding Fee: The fee prepaid to Maker to pay the gas fee for the destination network transfer.
Maker System
Currently the liquidity is provided by the Orbiter team, the ‘Maker’ will be allowed to provide liquidity decentralized in the future. Then, ‘Makers’ can decide the withholding fee, trading fee, amount limit and token type by themselves. In a fully competitive environment, ‘Senders’ will enjoy reasonable transfer costs and ‘Makers’ will earn enough to be activated to add sufficient liquidity.The ‘Maker’ system is in development and will be launched soon.
Website: https://orbiter.finance/
Twitter: https://twitter.com/Orbiter_Finance
Reddit: https://www.reddit.com/r/OrbiterFinance
YouTube: https://bit.ly/3mED0rz
