Orbiter Finance’s Bridge Protocol
Roles in Cross-rollup Transaction
Sender: The user who engages with cross-environment interoperability systems to initiate transactions.
Maker: The provider responsible for furnishing cross-rollup services, ensuring seamless connectivity between different networks.
Dealer: Receives incentives for providing decentralised frontends. (Will be further explained in Chapter ‘Roadmap to Ultimate Trustless’.)
Submitter: Responsible for submitting the root of the revenue tree generated by Dealers. (Will be further explained in Chapter ‘Roadmap to Ultimate Trustless’.)
Workflow
Orbiter Finance's main goal is the creation of a secure and decentralised cross-rollup bridge within the Ethereum ecosystem. It has been developed with the aim of improving the interoperability of mainnet-rollup. To achieve this goal, Orbiter Finance originally designed the cross-rollup transactions based on an optimistic principle, assuming all transactions are valid and configure an Arbitration Mechanism where users can issue an arbitration case and challenge the result of a cross-rollup transaction.
Upon examining the transaction log through a block explorer, a distinct feature can be found: Senders will directly initiate the transaction to a Maker's externally owned address (EOA), rather than a contract address. This distinction sets Orbiter Finance apart from other bridge protocols. Makers have the option to develop and operate a client that automates the service, or they can utilise the open-source client provided by the Orbiter Finance team.
Following the initiation of transaction from Sender to Maker on the source network, Maker assumes the responsibility of transferring the assets to the Sender on the destination network. Maker will confirm the three crucial parameters listed below to complete the transaction.
Token Standards: The protocol accommodates ETH and ERC-20 Tokens. When Makers deposit margin in the MDC (Maker Deposit Contract), it is required to specify the withholding fee (a predetermined fee), the trading fee (a certain percentage of the transaction amount), and the endorsed token. These defined parameters will be retained within the EBC (Event Binding Contract) and consistently synchronised with the Maker Client end. (Note: Owing to the fluctuating nature of gas fees, Orbiter Finance will periodically adapt its fees based on the Gwei rate of the destination network. This is done to maintain Orbiter Finance’s charging fees at a level below the prevailing average. It's important to note that these adjustments will not occur frequently. Senders can refer to the Orbiter website to view the current fee rates. Some maths for you to better understand the charging guideline.
e.g., When you transfer 1ETH from Mainnet to zkSync, the Trading Fee is 0.03% of the transfer amount and the Withholding Fee is 0.0014ETH, the cost of the transfer is: 0.03%*1ETH+0.0014=0.0017ETH e.g., When you transfer 100 USDC from Mainnet to zkSync, the Trading Fee is 0.3% of the transfer amount and the Withholding Fee is 1.5USDC, the cost of the transfer is: 0.3%*100 USDC+1.5USDC=1.8USDC)
Amount Sender Receive: Upon confirming the designated token type that the Sender should receive, Maker will perform the calculation as per the formula in EBC for the precise amount the Sender is entitled to receive. (Contracts functionalities and formulations will be explained later on.)
Destination Network: Orbiter Finance employs an "Identification Code" to distinguish between various Destination Networks. This "Identification Code" is appended to the final four digits of the transfer amount, allowing the Maker to determine the right Destination Network for executing the transaction. Meanwhile, please be noted that any modification made by the Sender to this transaction will result in the transaction failing.
See the sheet below to find the Identification Code for different networks, please be noted that the Code for networks on Mainnet remain TBC if it is only live on testnet.
| Networks | Identification Code | Identification Code |
|---|---|---|
Mainnet | Testnet | |
Ethereum | 9001 | 9005 |
Arbitrum | 9002 | 9022 |
zkSync Lite | 9003 | 9033 |
Starknet | 9004 | 9044 |
Polygon | 9006 | 9066 |
Optimism | 9007 | 9077 |
Immutable X | 9008 | 9088 |
Loopring | 9009 | 9099 |
Metis | 9010 | 9510 |
dydx | 9011 | 9511 |
ZKSpace | 9012 | 9512 |
Boba | 9013 | 9513 |
zkSync Era | 9014 | 9514 |
BNB Chain | 9015 | 9515 |
Arbitrum Nova | 9016 | 9516 |
Polygon zkEVM | 9017 | 9517 |
Base | 9021 | 9521 |
Linea | 9023 | 9523 |
Mantle | 9024 | 9524 |
opBNB | 9025 | 9525 |
Zora | 9030 | 9530 |
Scroll Alpha | 9019 | 9519 |
Taiko | - | 9520 |
Scroll Sepolia | - | 9528 |
Combo | - | 9529 |
Kroma | 9036 | 9536 |
Manta | 9031 | 9531 |
ZKFair | 9038 | 9538 |
Blast | 9040 | - |
Zeta | 9041 | - |
Mode | 9047 | - |
Solana | 9051 | - |
Proof of Play Apex | 9053 | - |
Merlin | 9054 | - |
BEVM | 9055 | - |
X Layer | 9027 | - |
Core Network | 9058 | - |
B² Network | 9046 | - |
BOB | 9057 | - |
Stylus Sepolia | - | 9534 |
Arbitrum Sepolia | - | 9535 |
Xai Görli | - | 9537 |
zkSyc Era Sepolia | - | 9539 |
Identification Code can be found when confirming a transaction.
How to Guarantee Security
Cross-rollup Security Model
The objective of the protocol is to address challenges within cross-rollup scenarios, rather than focusing on cross-chain transactions. Cross-chain projects primarily strive to secure transactions between distinct chains and prevent 51% attacks. In contrast, cross-rollup initiatives leverage the shared Ethereum data layer for each rollup, inherently mitigating the risk of a 51% attack. Building upon this premise, the cross-rollup mechanism designed by Orbiter Finance inherits the security features of Ethereum Layer 2.
Security Mechanism in Transaction: Arbitration
When either the Sender or the Maker initiates a transaction that contravenes the protocol and conducts malicious behaviour, the individual triggering this conduct becomes the Challenger, while the other party takes on the role of the Challenged. Both parties are entitled to prove the validity of the transaction in a cost-efficient way by applying zero-knowledge proof and smart contracts deployed within the system.
To prevent such malicious behaviour, we have devised an Arbitration mechanism – an innovative system that empowers senders to track and address issues with their transactions if they do not receive their assets within a reasonable timeframe.
Senders are eligible to initiate the arbitration process if their assets are not received on the destination network within a reasonable duration. They are required to provide transaction proof to prove the validity of a transaction. Makers have the option to submit evidence demonstrating that the transfer has taken place or is in progress on the destination network. If Makers present the necessary transaction evidence to the sender, they will not incur any loss. In cases where such proof is not provided, the sender will receive a complete refund along with a share of the excess margin from the Maker associated with that transaction.
Three contacts are deployed in the network to validate the transaction in arbitration.
MDC Contract (Maker Deposit Contract): Holds excess margin makers deposits and handles the compensation for Senders.
EBC Contract (Event Binding Contract): to verify the correspondence between the source and the target transactions.
ZK-SPV (Zero-Knowledge Simple Payment Verification): Utilise zero-knowledge proof technology to demonstrate the existence and validity of the cross-rollup transactions. Existence refers to both the source and target transactions that can be verified on Layer1 and they indeed took place on the respective L2s. Validity involves confirming the user's intent behind source transaction and ensuring that the outcome of the maker's payment in destination transaction adheres to predetermined regulations.
MDC, EBC, and the ZK-SPVs are implemented on a domain that accommodates smart contracts within the Ethereum ecosystem. The chart below illustrates how these three smart contracts work in the Arbitration flow.
How steps look like for Arbitration:
Last updated
