# Welcome!

[Orbiter Finance](http://orbiter.finance/) is a ZK-tech Based Ethereum Acceleration Engine that boosts L2s' performance and decreases gas consumption.

We are committed to revolutionising the Ethereum ecosystem through the utilisation of ZK technology, streamlining all transactions on Layer 2 in a manner that is both cost-effective and time-efficient.

**Website:** <https://orbiter.finance>

## Want to jump right in?

Feeling like an eager beaver? Jump in to the quick start docs and get making your first request:

{% content-ref url="/pages/BvU552BVclIDSizKrYX7" %}
[Broken mention](broken://pages/BvU552BVclIDSizKrYX7)
{% endcontent-ref %}

## Want to deep dive?

Dive a little deeper and start exploring our API reference to get an idea of everything that's possible with the API:

{% content-ref url="/pages/dRG9KVxUSFlypdJgHY4U" %}
[Broken mention](broken://pages/dRG9KVxUSFlypdJgHY4U)
{% endcontent-ref %}


# Overview

### Ultimatum of Cross-rollup Transactions <a href="#ultimatum-of-cross-rollup-transactions" id="ultimatum-of-cross-rollup-transactions"></a>

Orbiter Finance enables cross-rollup transactions of Ethereum/Bitcoin native assets in a trustless and seamless manner. We support various networks, including Ethereum, zkSync Era, zkSync Lite, Linea, Mantle, Base, StarkNet, opBNB, Scroll, Arbitrum, Arbitrum Nova, Loopring, Optimism, Polygon, Polygon zkevm, BNB Chain, Zora, ImmutableX, BOB, BEVM, Bitlayer, BSquared, etc..

### Major Features <a href="#major-features" id="major-features"></a>

#### A suite of features that enhance Orbiter Finance’s appeal to users: <a href="#a-suite-of-features-that-enhance-orbiter-finances-appeal-to-users" id="a-suite-of-features-that-enhance-orbiter-finances-appeal-to-users"></a>

* **Secure:**

  Orbiter Finance benefits from the security of rollups, resulting in a minimal risk associated with data synchronisation between networks. This is because rollups synchronise their data with the main network thus ensuring the security of the transfer process.
* **Compatible:**

  Supporting non-EVM L2 and L3, as well as EVM rollups, validium, and Dapp-specific rollups, this versatility enables a wide range of use cases, making Orbiter Finance an attractive choice for users seeking flexibility in transactions.
* **Fast:**

  Orbiter Finance’s timeliness is exceptional, making it the quickest solution available. Transactions between two EOAs can be completed within 10 to 20 seconds.
* **Cost efficient:**

  Orbiter Finance also offers the lowest basic network costs, which is the sum of the gas costs for transactions between two EOAs on both source and destination networks. Rarely no other solutions can be found cheaper than us.
* **Openness:**

  We support the decentralised addition of various ERC20 token liquidity. It enables developers to the environment by deploying SPV and allows them to customise cross-rollup transactions and message events. This openness provides users with greater flexibility and control over their transactions.
* **Trustless:**

  Orbiter Finance has developed a decentralised incentive front-end that enables third-party DApps to establish frontend interfaces compatible with the cross-rollup bridge protocol. This marks a significant achievement in Orbiter Finance's pursuit of ultimate decentralisation and trustlessness.


# Bridge Protocol

## Roles in Cross-rollup Transaction <a href="#roles-in-cross-rollup-transaction" id="roles-in-cross-rollup-transaction"></a>

**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 <a href="#workflow" id="workflow"></a>

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%\*(1-0.00014)ETH+0.0014ETH=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-1.5) 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.

Identification Code can be found when confirming a transaction.

{% content-ref url="/pages/hBCt5GAarMQTEXORpSwm" %}
[Supported Chains](/supported-chains)
{% endcontent-ref %}

<figure><img src="https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-1b4004572bd4cb3ed9cec11ca139e98c7642ac44%252Fconfirm%2520page.png%3Falt%3Dmedia&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=da6e89d3eefd7b183dd688cd09c2d0719c9d1d032c896e05a24df8159b1fccd0" alt="" width="563"><figcaption></figcaption></figure>

## How to Guarantee Security <a href="#how-to-guarantee-security" id="how-to-guarantee-security"></a>

**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.

<figure><img src="https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-02e0182d8d88fc743ad0ae26c1ec38a4c7f9f6f3%252FOrbiter%2520Bridge%2520Protocol.png%3Falt%3Dmedia&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=587861ea5e4f3514c101e09abb574171f6c1f79cda04bfdb4d4b41f3b0a8acf9" alt="" width="563"><figcaption></figcaption></figure>

How steps look like for Arbitration:

![](https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-a66929423a981f1a4ce0e6b8e4eac24b7d3fbfa4%252FArbitration1.png%3Falt%3Dmedia\&width=768\&dpr=4\&quality=100\&sign=7a32094d1f0328d634e2155c52b2cc151ea0675ec11425405b3942f259cf5616)![](https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-ae36355a9cebc6f32d4fd7e12695c8977113977a%252FArbitration2.png%3Falt%3Dmedia\&width=768\&dpr=4\&quality=100\&sign=c94a055007a6e9761075c8746f4bea4807569b09c6a8e9b57c900d1ff258b8e9)![](https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-316acdbf7d20d44364fb45f680234d0dbdaa1f26%252FArbitration3.png%3Falt%3Dmedia\&width=768\&dpr=4\&quality=100\&sign=67e83a045cf9add2beae8832bc4ef9ef351712700e6ce2218f070f90caa64d4b)![](https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-413d016d3642dc6fbf82461efd688ce5950f1521%252FArbitration4.png%3Falt%3Dmedia\&width=768\&dpr=4\&quality=100\&sign=37f6b6df695831949cbbe2a53239cb7c559a8e5ecb847633c5f99c5c81615b4f)![](https://docs.orbiter.finance/~gitbook/image?url=https%3A%2F%2F1544475235-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MY5Qy9GjDHXTy9ppyql%252Fuploads%252Fgit-blob-0fa85d16bdd83586a5bc8ab63b99be8e4a751311%252FArbitration5.png%3Falt%3Dmedia\&width=768\&dpr=4\&quality=100\&sign=180378a4b5a4c63f463dba1f565900acb5ddc73e2ad418a61dcfb8c532d2002c)


# Maker System

### What Is Maker <a href="#what-is-maker" id="what-is-maker"></a>

Makers assist senders with the interoperability and adaptability of their asset transactions in an efficient manner. Continuously providing liquidity in all market conditions, they optimise Ethereum Layer 2 transactions for stability.

### What Is the Maker System <a href="#what-is-the-maker-system" id="what-is-the-maker-system"></a>

Maker System is a multifunctional decentralised mechanism, empowering both Makers and Senders to flexibilize their digital assets safely and efficiently. We enable makers to earn competitive profits by setting up Maker Nodes, while safeguarding sender’s assets via the Arbitration mechanism.

### What Is Maker Node <a href="#what-is-maker-node" id="what-is-maker-node"></a>

Makers can set up a maker node by themselves and provide liquidity.

### How to Set Up A Maker Node <a href="#how-to-set-up-a-maker-node" id="how-to-set-up-a-maker-node"></a>

Anyone can create a maker node via the maker dashboard.

**Route**

* Step 1: Go to the MakerNode page in Orbiter Dashboard.
* Step 2: Maker needs to select the layer 2 network in which they wish to provide liquidity. Please note that a maker can choose multiple destination networks for transaction validation and liquidity provision.
* Step 3: Set the transaction limit, withholding fee and trading fee per transaction according to the maker's preferences.

**Limit**: Refers to the maximum amount allowed for a transaction. Please note that the minimum transaction value is 0.005 ETH. Withholding Fee: A one-time charge to cover the cost of gas for transfers to the destination network. Fees may vary according to the destination network. Trading Fee: Makers can choose a percentage of the trading value they wish to get from the per-transaction amount.

We recommend that makers keep 110-180 ETH in their EOA as liquidity in order to respond to transaction needs. In addition to the liquidity that makers provide in their EOA, makers also need to deposit excess margin in the MDC contract. Makers are able to adjust the excess margin amount by modifying the limit of every transaction pair. Makers will receive the total amount of excess margin deposited when the node is removed.

### How to Respond to Arbitration Case <a href="#how-to-respond-to-arbitration-case" id="how-to-respond-to-arbitration-case"></a>

Makers will be able to access the ongoing arbitration cases and history via Maker Arbitration on Maker Client homepage.

<figure><img src="/files/psq6nPW8Loh4a5XD8G1a" alt=""><figcaption></figcaption></figure>

### How to Become Makers <a href="#how-to-become-makers" id="how-to-become-makers"></a>

Although our Maker Client is now running on the testnet and only available to members of our Whitelist, we will expand our reach and finally meet everyone very soon!


# Insights and Infrastructure Path Ahead

### **Orbiter Finance’s Evolutionary Voyage** <a href="#orbiter-finances-evolutionary-voyage" id="orbiter-finances-evolutionary-voyage"></a>

Standing on the shoulders of giants, it becomes apparent to us that Ethereum's evolutionary path has been shaped by three crucial technical advancements: privacy enhancements, Layer 2 scaling solutions, and smart contract wallets. These transformations have played a pivotal role in transitioning Ethereum from its initial experimental stage to a mature technological ecosystem, enabling users to enjoy a genuinely open, global, and permissionless experience. Vitalik has illustrated these interdependent elements in a triangular graph in his post titled 'The Three Transitions,' highlighting their simultaneous and indispensable nature.

<figure><img src="/files/P26jH5H2sUUfOkJ9OvP5" alt=""><figcaption></figcaption></figure>

We won't delve into exhaustive discussions of the significance of these three Ethereum transformations individually. They are not ‘good to have’ enhancements for protocols, rather, we firmly believe they represent fundamental building blocks for interactions within the Ethereum ecosystem.

Scalability serves as the lifeblood of Ethereum, and Layer 2 scaling solutions have played a pivotal role in mitigating Ethereum's scalability challenges. These solutions, including rollups, have facilitated faster and more cost-effective transactions while upholding the security of the Ethereum mainnet. The advent of Layer 2 scaling has ushered in new opportunities for DApps, enhancing their accessibility to a global user base. Having been landing in the Layer 2 ecosystem, Orbiter Finance recognised that as Layer 2 adoption becomes more widespread, users will hold assets across various Layer 2 networks. Among these Layer 2 users, the majority rely on EOAs, whose addresses essentially consist of a hash of the public key used for signature verification. This means that the user experience remains consistent between Layer 1 and Layer 2. However, for users employing smart contract wallets, maintaining a single, unchanging address poses complexity. The keys required to access different accounts may change over time, rendering old keys obsolete. This situation necessitates a solution that enables users to efficiently manage their keys across diverse networks.

To tackle the challenge of changing access keys, Vitalik once proposed "asset/keystore separation architecture" as an emerging solution. Inspired by this architecture, we found out that each user possesses a keystore contract located in a single location, which could be either on the mainnet or a specific Layer 2 network. Users maintain addresses on various Layer 2 networks, with the verification logic for each of these addresses pointing to the keystore contract. To spend from these addresses, a proof is required to be submitted to the keystore contract, demonstrating the current or very recent spending public key. The graphic below presents how this works.

<figure><img src="/files/YWZNF0bnYjnwiUZadA2h" alt=""><figcaption></figcaption></figure>

We shall refrain from delving into detailed intricacies concerning the diverse architectural implementations under consideration. One particular approach aligns with Orbiter Finance's overarching principles, accentuating the virtues of minimised systemic complexity and the judicious economisation of keystore updates. Within this paradigm, each transaction necessitates the presentation of a cross-chain proof, elucidating the current status of the keystore key. While this method offers certain merits, it necessitates a formidable engineering undertaking to render cross-chain proofs economically tenable. This approach, as previously asserted, is characterised by its cost-intensive nature per transaction and its relative incompatibility with the current ERC-4337 standard, which regrettably lacks support for the cross-contract inspection of mutable objects during the validation process. Orbiter Finance's technical geeks have identified that this proof could potentially be implemented using ZK-SNARKs. This would reduce data costs by employing a ZK-SNARK of a Merkle branch instead of the entire branch. Furthermore, off-chain aggregation techniques (e.g., built on top of EIP-4337) could be used to have a single ZK-SNARK verify all cross-chain state proofs within one block. Aggregation here refers to combining all proofs submitted by users within each block into a large meta-proof that encompasses all of them. This approach becomes worthwhile as the scheme gains a substantial user base, making it a realistic choice for the previously mentioned approach. It's here that Orbiter Finance realised that by adopting ZK-SNARKs, we could aggregate users' AA transactions to save gas, potentially reducing ERC-20 transaction gas consumption by up to 20% to 30%. This, in turn, constitutes a pivotal facet of the overarching infrastructure.

Another postulation, as previously articulated by Vitalik, posits that if Layer 2 serves as the scaling for Layer 1, there may well exist yet another layer above Layer 2 poised to further enhance scalability and TPS metrics. As in the realm of Layer 2 solutions, we embark upon an inquiry to ascertain whether there exists another scaling solution capable of augmenting Ethereum's overall performance. Nonetheless, current scaling solutions such as rollups, represent a fusion of diverse approaches aimed at mitigating the bottlenecks scalability: computation and data. The inherent nature of data renders it resistant to repeated compression, while distinct rollup implementations exhibit unique characteristics, each entailing specific trade-offs in terms of security, speed, and cost. Consequently, the conception of another layer for scalability is not always a feasible or stackable proposition. This contemplation also leads us to ponder whether the endeavour to construct an infrastructure encompassing all Layer 2 solutions remains prudent, given the possibility that a rollup atop another rollup or the introduction of a Layer 3 may introduce complexities beyond the initial assumption. In such a scenario, we have explored alternative avenues.

Orbiter Finance has consistently pursued the goal of enhancing interoperability among Ethereum rollups, recognising that seamless communication between these rollups requires a robust infrastructure. Achieving smooth interoperability is a significant challenge for Ethereum's scalability. We are currently exploring the idea of a super Dapp, similar to AA, which could leverage the unique characteristics of various rollups to address specific use cases. To complete a final transaction, it is essential to depend on transactions from numerous previous rollups. However, implementing this requirement in the current rollup architecture would result in high gas costs and delays, rendering it impractical for real-world usage across all rollups. Rollups could opt to wait until there is a batch of L2 transactions worth 10 million gas to submit, but this would lead to extended verification times. In our proposed approach, ZK rollups would accept a message from a batch verifier contract, confirming the verification of a batch of statements, each following a similar pattern as the previous ones. This batch proof could be constructed using a recursive SNARK scheme. Building upon our research, we have developed an open protocol known as the Aggregated zkProver, which allows all ZK rollups to participate. This protocol aggregates proofs from any compatible ZK rollup and they are entitled to receive turnovers coming from transaction fees. The batch handler contract would verify the proof once and then send a message to each rollup, containing a triple in the same format as that rollup's requirements. The fact that the triple originated from the batch handler contract would serve as evidence of the validity of the transition.

This scheme's cost structure offers significant savings for each rollup and effectively serves as an infrastructure for balancing the trade-offs among all ZK rollups. Notably, Vitalik mentioned a similar concept of the Aggregated zkProver in his post about “Layer 3”. He highlighted the advantages of a simplified and highly specialised middle layer, which is more likely to be secure, built without the need for additional specialised tokens, and resistant to frequent governance changes.

Please refer to the chapter below to learn more about how Aggregation and ZK technology is applied in Orbiter Finane’s infrastructure construction.


# ZKP Applications

At the forefront of Ethereum’s infrastructure, Orbiter Finance has harnessed the power of ZKP to achieve scalability and trustless. Recursive zero-knowledge proofs as emerging cryptographic primitives

#### Use Case 1: ZK-SPV <a href="#use-case-1-zk-spv" id="use-case-1-zk-spv"></a>

As elucidated within the Security Mechanism section above, the transaction procedure within Orbiter Finance, ZK-SPV based on the specific rollup mechanism serves to authenticate the validity of designated transaction execution timing, transaction amount, and adherence to the Maker-defined service conditions. This extends to the identification of cross-rollup transactions, with ZK-SPV maintaining stringent constraints to proactively curtail any potential malicious actions initiated by the Maker. The operational process of ZK-SPV in a transaction procedure can be better understood by consulting the diagram provided in the Security Mechanism section.

#### Use Case 2: ZkProver <a href="#use-case-2-zkprover" id="use-case-2-zkprover"></a>

Our transactional prowess revolves around the seamless facilitation of transfers between two externally owned account (EOA) addresses, thereby ensuring exceptional efficiency and cost-effectiveness in cross-rollup transactions.

Nonetheless, it is prudent to recognise that when juxtaposed with EOA transactions, Account Abstraction (AA) technology brings forth plenty of advantages. AA offers users a versatile array of features including flexible signature verification, gas abstraction, session keys, social recovery, and multi-factor authentication. Moreover, EIP-4337 account abstraction on the Ethereum mainnet foreshadows AA's burgeoning significance as a pivotal activity carrier within the Ethereum ecosystem in the near future. As AA is integrated into the network through smart contracts, users can relish enhanced operational flexibility.

While the advent of AA bestows convenience upon users, it concurrently entails heightened usage costs primarily attributed to the relatively higher gas fees incurred by the increased logic of AA smart contracts.

To expedite the mass adoption of AA, zkProver is devised with the ultimate objective of mitigating usage expenses and optimising gas consumption. With the application of Zero Knowledge (ZK) technology, this initiative is dedicated to user-friendly deployment on the Ethereum ecosystem, aiming to achieve ease of use, fairness, decentralisation, and safeguarding user privacy. With zkProver, our unwavering pursuit is to forge a path towards a future where the benefits of Account Abstraction are harnessed seamlessly and efficiently. Furthermore, despite the strides made by EIP-4337 towards cross-L2 compatibility, it has not yet achieved complete cross-L2 friendliness. There's still a need to enhance instantaneous communication and interoperability among all L2 solutions. However, this challenge can be overcome with the implementation of zkProver. Through zkProver, users will eventually gain the capability to effortlessly traverse various L2 environments within the Ethereum ecosystem. This will enable rapid and seamless transfers of both assets and operational accounts, granting users the convenience of engaging with diverse computations across different Layer 2 networks simultaneously. This holistic approach not only guarantees limitless scalability but also provides users with a smooth experience, exemplifying Ethereum's ultimate scaling potential.

**Architecture of zkProver**

Gas Analysis in Comparative Setting

Within the realm of the EIP-4337 account abstraction contract, an aggregation of transaction signature verification, nonce value updates, and gas fee calculations culminates in a heightened gas consumption compared to average transaction execution.

In the context of an ERC20 token transfer instigated by an EOA address, the signature and nonce verification are validated by the RPC node before being submitted to the chain protocol for final inclusion. Gas primarily comprises the foundational gas amount of 21,000 alongside the gas expended for the smart contract transactions — approximately 34,330 gas when utilising the OpenZeppelin ERC20 template.

Conversely, when a transfer originates from an AA account, signature validation, nonce update verification, and gas fee settlement transpire on-chain, resulting in a gas tally of 57,135.

Should we deviate from Ethereum's ecdsa signature and adopt a non-EVM built-in algorithm like BLS, the gas consumption skyrockets to 148,123.

We then devised a bundler service with functions listed below rooted in the zk environment architecture to address high gas consumption challenges.

1. Verification of user Tx signature accuracy.
2. Maintenance of the nonce value and Gas balance of the AA account through a Merkle world state tree.

By updating the Merkle Root within the Ethereum mainnet's EntryPoint contract and aggregating multiple transactions and equitably distributing zkp verification gas, these approaches lower the threshold for AA usage while preserving their flexibility in L1 transactions. Remarkably, a standard ERC20 transfer can ultimately economise 30% of gas. The average gas expenditure after aggregating 128 transactions stands at 23,843.

Workflow

Drawing inspiration from the architecture of EIP-4337, we have devised a framework akin to zkProver. Illustrated in the flowchart below, the work flows are as follows:

* The process begins with the Bundler collecting verified signatures from transactions.
* The Bundler then aggregates these transactions, creating a consolidated batch.
* The aggregated batch of transactions is then passed to the EntryPoint contract.
* The EntryPoint contract validates the signatures and updates the nonces of the AA accounts.

However, within the construct of our zkProver architecture, the Bundler's role is redefined. It now gathers the already-verified signatures of these aggregated transactions before subsequently submitting them to the EntryPoint contract.

<figure><img src="/files/ejVG9mM0SorDbBnQnfH6" alt=""><figcaption></figcaption></figure>

With two distinct architectural approaches, Account Abstraction presents significant enhancements in the operational flexibility of user accounts; however, this convenience comes at the cost of increased gas consumption. Recognizing this trade-off, we thus conducted a thorough analysis of gas-intensive processes and consequently devised zkProver, centred around zero-knowledge proofs (zkp), to effectively address this challenge.

Meanwhile, the architectural framework of zkProver aligns well with the insights shared by Vitalik Buterin in his article, available at <https://vitalik.ca/general/2022/09/17/layer\\_3.html>. In this article, the substantial benefits of aggregated proofs are expounded, showcasing their capacity to curtail the verification costs associated with zero-knowledge proofs (zkp). Moreover, the article underscores how the aggregated proofs contribute to the simplification of user interactions, thereby reducing the complexities inherent in interchain interoperability. The synergies between the principles outlined in the article and the concepts of zkProver underscore the shared commitment to enhancing efficiency, reducing costs, and fostering enhanced user experiences within the realm of Ethereum.

This convergence of ideas further solidifies our conviction that zkProver is not only a strategic pursuit but a genuinely transformative endeavour, poised to establish itself as a foundational infrastructure capable of facilitating real-time communication and inter-chain scalability within the Ethereum ecosystem.

Anticipating its unveiling, zkProver is set to make its debut in Q4 of this year, and we are eagerly looking forward to sharing its advancements with the community.

Vitalik stated that "everyone will transition to rollups," indicating that there is a strong trend towards a scaling roadmap centred around rollups for Ethereum. We are now heading to the final stages of this journey, where we have proposed a protocol for interchain messaging and developed an aggregated middle layer for zk rollups. Our goal is to enable cross-rollup transactions, thereby enhancing the inter-chain interoperability of Ethereum and ensuring that rollups remain synchronised with the main network in real-time. Our Future for Ethereum Layer 2 Infrastructure Awaits.


# Inscription Cross-Rollup Protocol

### Inscription Culture <a href="#inscription-culture" id="inscription-culture"></a>

Inscription, representing the spirits of fairness and democratization, has become an undeniable community force, garnering our attention and respect. As a leading Ethereum cross-rollup communication protocol, we are embarking on an experiment to make the Inscription cross-rollup feasible. We have pioneered a definition of an Inscription format, enabling developers to invoke our protocol for scenarios involving minting and cross-rollup functionalities, potentially unlocking more Inscription potential.

### Inscription Ecosystem Support Plan <a href="#inscription-ecosystem-support-plan" id="inscription-ecosystem-support-plan"></a>

Developers utilizing the Orbiter Protocol for Mint initialization issuance and cross-rollup circulation can do so with a nominal protocol fee of only 0.00023 ETH, covering cross-rollup costs. But that's not all! Following the Mint issuance, for cross-rollup circulation costs incurred, Orbiter Finance will refund 80% to ecosystem developers. Ecosystem developers can autonomously decide the usage of these funds, fostering longer-term project development. For users engaging with interactive ecosystem dApps, Orbiter Finance will distribute "Ecosystem Points". All transactions generated through this protocol will be included in the O-Points reward system, with specific reward criteria based on O-Points.

### Inscription - Just the Beginning <a href="#inscription-just-the-beginning" id="inscription-just-the-beginning"></a>

Orbiter Finance, as an Ethereum acceleration engine based on ZK technology, continuously explores cross-rollup scenarios, whether for tokens, NFTs, or Inscription cross-rollup We welcome communities and developer partners to construct innovative Omni applications based on our protocol.

If you plan to build, stay tuned for our GitHub code updates, and let's collectively shape the omni-chain development of Orbiter Protocol!

### Inscriptions Cross-Rollup Protocol

Building upon the existing cross-rollup communication, we've extended functionalities to encompass inscriptions minting and crossing.

The fundamental principle involves users submitting transactions containing basic inscriptions information and the identification code for the target network to the Maker Protocol. These transactions are processed by the Orbiter Bridge Protocol. On the target network, the Maker Protocol utilizes mint and cross functions to send inscriptions to the user's address, completing the entire inscriptions cross-rollup process.

Currently, this protocol early supports networks including Arbitrum One, Optimism, zkSync Era, Base, Linea, Scroll, and Polygon zkEVM. The Orbiter Bridge Protocol collects a certain fee on the source network as the Inscriptions Cross-rollup Protocol fee.

### Inscriptions Minting

**Deploy**

**The inscription contract can be deployed on any network. The `to` address of the recipient of the deployed contract transaction is the owner of the contract. With ownership of the contract, you can help anyone deploy the contract and set the owner to his address.**

**Note: The protocol + tick will form a unique identifier in the entire network. If the contract protocol and tick you are not familiar with already exist, your deployment will be invalid.**

```
{"p": "xxx-20", "op": "deploy", "lim": "10000", "max": "xxxxx", "tick": "Name"}
```

| Field | Required | Remark                                          |
| ----- | -------- | ----------------------------------------------- |
| p     | YES      | Ex:xxx-20 Supported Protocol                    |
| op    | YES      | deploy                                          |
| lim   | YES      | Maximum casting amount for a single transaction |
| max   | YES      | Maximum circulation                             |
| tick  | YES      | EX:xxx-20 Inscriptions' Name                    |

**Claim**

You can choose any network to select the target network, use the inscription contract protocol information to initiate a claim transaction, and cast the inscription contract you want on the target network simply and conveniently. The main method is to send fixed inscription contract through the following inscription protocol JSON data + The handling fee amount + security code are used as transaction data and are executed on the target network. This process does not require you to operate on the target network, and there is no handling fee.

{% hint style="info" %}
**Note: When the Claim transaction is initiated, the `to` field of the on-chain transaction receiving address is the owner when the inscription contract is deployed. For the inscription protocol and tick you want to mint, the maximum minting amount for a single transaction must be within the parameters set by the deployment contract, otherwise your creation will not take effect.**
{% endhint %}

* Basic data

```
{"p": "xxx-20", "op": "claim", "amt": "1000", "tick": "Name"}
```

| Field | Required | Remark                                  |
| ----- | -------- | --------------------------------------- |
| p     | YES      | Ex:xxx-20 Supported Protocol            |
| op    | YES      | claim Initiate Cross-Rollup Mint Action |
| tick  | YES      | EX:xxx-20 Inscriptions' Name            |
| amt   | YES      | Ex:1000 Mint Amount                     |

* Casting fee and Identification Code
  * The casting fee is a fixed value, currently 0.00023ETH (or equivalent amount)
  * The identification code is determined internally by the protocol, and each network has a unique identification code identifier. The identification code identifier is consistent with the Orbiter cross-rollup protocol. For details, see: <https://docs.orbiter.finance/orbiterfinancesbridgeprotocol>
* Then the casting fee is 0.00023 + the identification code is 9001, then the value amount of the sent transaction should be set to: 0.0002300000000009001. As long as the casting fee is higher than the protocol casting fee and the last 4 digits of the protocol identification code are guaranteed, then the casting will go smoothly at the target network execution.

**Mint**

**This process does not require user participation. After the source network initiates a claim, the protocol node will automatically execute casting on the target network after the transaction is confirmed.**

```
{"p": "xxx-20", "fc": 9521, "op": "mint", "amt": "1000", "tick": "Name"}
```

| Field | Required | Remark                                 |
| ----- | -------- | -------------------------------------- |
| p     | YES      | Ex:xxx-20 Supported Protocol           |
| op    | YES      | mint Complete Cross-Rollup Mint Action |
| tick  | YES      | EX:xxx-20 Inscriptions' Name           |
| amt   | YES      | Ex:1000 Mint Amount                    |
| fc    | YES      | Ex:1 InternalID of the Source Network  |

### Inscriptions Crossing

**Cross**

```
{"p": "xxx-20", "op": "cross", "amt": "1000", "tick": "Name"}
```

| Field | Required | Remark                       |
| ----- | -------- | ---------------------------- |
| p     | YES      | Ex:xxx-20 Supported Protocol |
| op    | YES      | cross Initiate Cross Action  |
| tick  | YES      | EX:xxx-20 Inscriptions' Name |
| amt   | YES      | Ex:1000 Cross Amount         |

**Crossover**

```
{"p": "xxx-20", "fc": 9521, "op": "crossover", "amt": "1000", "tick": "Name"}
```

| Field | Required | Remark                                |
| ----- | -------- | ------------------------------------- |
| p     | YES      | Ex:xxx-20 Supported Protocol          |
| op    | YES      | crossover Complete Cross Action       |
| tick  | YES      | EX:xxx-20 Inscriptions' Name          |
| amt   | YES      | Ex:1000 Cross Amount                  |
| fc    | YES      | Ex:1 InternalID of the Source Network |


# Liquidity Pool

### What is a Liquidity Pool (LP)?

A liquidity pool is a smart contract that facilitates decentralized trading and liquidity management. By depositing assets into the liquidity pool, you can receive Liquidity Provider (LP) tokens and participate in the platform’s profit-sharing mechanism.

***

### Feature Guide

<figure><img src="/files/pkVoQ95xm5saksTGxaog" alt=""><figcaption><p>My Pool</p></figcaption></figure>

<figure><img src="/files/LvmQxXl1qDiIfbhMmiVe" alt=""><figcaption><p>Top Pools</p></figcaption></figure>

#### 1. Adding Liquidity

Users can deposit assets into the liquidity pool to receive LP tokens corresponding to the current net asset value.

#### Steps to Use:

1. Ensure your wallet has sufficient assets (e.g., ETH or ERC20 tokens).
2. Visit <https://www.orbiter.finance/pool> and locate the pool corresponding to your asset’s network.
3. Enter the amount of liquidity you wish to add, or click "Max" to add all available assets.
4. Upon success, you will receive the corresponding amount of LP tokens.
   1\.

   ```
   <figure><img src="/files/MGJ1HGFYh4nQFzRlcxK6" alt="" width="375"><figcaption><p>Input quantity</p></figcaption></figure>
   ```

   2\.

   ```
   <figure><img src="/files/bcooMJgw4Xgm7bM7kfhj" alt="" width="375"><figcaption><p>Success</p></figcaption></figure>
   ```

{% hint style="info" %}

#### Notes:

* For ERC20 tokens, you may need to approve the contract to access your tokens. Please confirm the approval request.
* The transaction will fail if the total liquidity exceeds the pool's cap.
  {% endhint %}

***

#### 2. Removing Liquidity

Users can burn LP tokens to withdraw assets from the liquidity pool, along with a share of the profit based on the net value.

#### Steps to Use:

1. Ensure you have sufficient LP tokens.
2. Go to the **My Pool** page, select the pool from which you want to withdraw, and access the removal interface.
3. Enter the number of LP tokens you wish to burn, or click "Max" to withdraw all available liquidity.
4. Upon success, your LP tokens will be burned, and you will receive your principal and profits based on the current net value.
   1\.

   ```
   <figure><img src="/files/3eWBkrkcKRErbDSkugpN" alt="" width="375"><figcaption><p>Input quantity</p></figcaption></figure>
   ```

   2\.

   ```
   <figure><img src="/files/rxGfweNCbhP0hlfcZ7pa" alt="" width="375"><figcaption><p> Success</p></figcaption></figure>
   ```

{% hint style="info" %}

#### Notes:

* For ERC20 tokens, you may need to approve the contract to access your tokens. Please confirm the approval request.
* The total liquidity removed cannot exceed the available liquidity in the pool.
  {% endhint %}

***

#### 3. Cross-Chain Withdrawals (Coming Soon)

Users will be able to withdraw liquidity from other supported chains.

***

### Earnings Formula Based on LP Share

$$
\text{Earnings} = \frac{\text{Your LP Token Balance}}{\text{Total LP Token Supply in the Pool}} \times \text{Total Trading Fees Collected}
$$

#### Formula Explanation

1. **Your LP Token Balance**: The total amount of LP tokens you hold, representing your share in the liquidity pool.
2. **Total LP Token Supply in the Pool**: The sum of all LP tokens held by all users in the pool, indicating the pool's total size.
3. **Total Trading Fees Collected**: The total fees collected by the pool over a specific period through trading activities.

#### Earnings Settlement Method:

* Earnings will automatically accumulate in the pool and be reflected through the LP tokens you hold.
* When you remove liquidity, you can withdraw both your principal and the corresponding earnings.

### Annual Percentage Rate (APR)

**APR** (Annual Percentage Rate) is a common metric to measure the return on investment in liquidity pools, indicating the total return over the course of one year.

<details>

<summary>APR Calculation Formula</summary>

In our model, **APR** is calculated using the following formula:

$$\text{APR} = \text{minAPR} + (\text{maxAPR} - \text{minAPR}) \times \text{Utilization Rate}$$

#### Formula Explanation

* **minAPR**: The minimum APR of the liquidity pool.
* **maxAPR**: The maximum APR of the liquidity pool.
* **Utilization Rate**: The ratio of the funds actively used in the liquidity pool to the total funds in the pool.

####

</details>

<details>

<summary>Linear Relationship</summary>

The relationship between **APR** and **Utilization Rate** is linear. That is, as the **Utilization Rate** increases from 0 to 1, **APR** increases linearly from **minAPR** to **maxAPR**.

* When **Utilization Rate = 0**, **APR = minAPR**.
* When **Utilization Rate = 1**, **APR = maxAPR**.

Example**APR** will vary linearly between **minAPR** and **maxAPR** depending on the **Utilization Rate**.

</details>

### Annual Percentage Yield (APY)

**APY** (Annual Percentage Yield) is similar to **APR**, but it considers the compounding effect, meaning the earnings grow due to periodic distribution and reinvestment.

<details>

<summary>APY Calculation Formula</summary>

The **APY** is calculated from the **APR** using the following formula:

$$\text{APY} = \left(1 + \frac{\text{APR}}{\text{periodsPerYear}}\right)^{\text{periodsPerYear}} - 1$$

#### Formula Explanation

* **APR**: The annual percentage rate (known).
* **periodsPerYear**: The number of periods in a year, typically daily, hourly, or set based on actual conditions.

</details>

### Utilization Rate

Utilization Rate is a key factor in calculating the annual percentage rate (APR), indicating the ratio of funds actively used in the liquidity pool compared to the total funds in the pool.

$$
\text{Utilization Rate} = \frac{\text{Maker Lends Amount}}{\text{Total Liquidity Amount} + \text{Idle Amount}}
$$

#### Formula Explanation

* **Maker Lends Amount**: The amount of liquidity lent by the maker, representing the total funds borrowed out of the liquidity pool.
* **Total Liquidity Amount**: The total liquidity in the pool, which is the sum of all funds.
* **Idle Amount**: The idle funds, typically calculated as the difference between the total inflows and outflows of funds.

{% hint style="info" %}
***Important*** ***Notes***

* **Risk Disclaimer**: Providing liquidity may involve price and net value fluctuations. Frequent operations may lead to losses.
* **Security**: Ensure you are operating in a secure environment and do not disclose your wallet private keys.
  {% endhint %}

### Frequently Asked Questions (FAQ)

#### 1. Why did my transaction fail?

* Verify that the pool's liquidity cap has not been exceeded.
* Ensure you have granted the necessary token approvals.
* Confirm that your signature is valid.
* Make sure you have enough network fees to pay for gas

#### 2. How can I check my LP token balance?

You can check your LP token balance via your wallet or a blockchain explorer.

#### 3. What should I do if the liquidity pool is paused?

If the pool is paused, you will temporarily be unable to perform operations. Please wait until the pool resumes.

***

For additional inquiries, please contact the Orbiter Finance official support team.


# Channel Partners

### Orbiter Finance Referral Program - Earn Commissions with Ease

> Orbiter Finance has launched a new referral program that allows anyone to earn commissions by promoting cross-chain transaction links. By becoming our agent, you can share your unique referral link to guide others in using our cross-chain bridge for transactions. Each transaction completed through your link will earn you a commission, calculated based on the transaction profit and your promotion volume. Commissions are settled monthly, and you can view your accumulated earnings in the backend, with the option to request withdrawals after admin approval.

### **1. Referral Registration & Promotion**

* Enter the page：<https://www.orbiter.finance/referral>
* Log in to generate a unique referral link (contains your wallet address).
  * Promotion URL format:  **<https://orbiter.finance/?channel=your> wallet address**
  * **Your wallet address is very important. All the proceeds from the promotion will be bound to the wallet, so you need to protect the corresponding wallet security.**
* Share your link to refer users. Transactions made through your link will be tracked via Orbiter’s dedicated Router Contract to ensure proper commission attribution.

### **2. Transaction Attribution**

* Users must complete cross-chain transactions **via your referral link** for commissions to apply.
* Referral data is recorded on-chain through the Router Contract, ensuring transparency and immutability.

### **3. Commission Rules**

* Commissions are calculated based on transaction profit, with rates determined by the number of bridging transactions:

| **Bridging Transactions** | **Commission Rate** |
| ------------------------- | ------------------- |
| ≤ 50                      | 12%                 |
| 50 < TX ≤ 500             | 14%                 |
| 500 < TX ≤ 2000           | 16%                 |
| 2000 < TX ≤ 5000          | 18%                 |
| > 5000                    | 20%                 |

### **4. Commission Settlement**

* Commissions are calculated monthly and updated in your account by the first week of each month.
* Connect your wallet to the dashboard to view earnings (signature required).

### **5. Withdrawal Process**

* Submit a withdrawal request from your dashboard.
* Requests are processed after manual approval by the admin team.
* Approved funds will be sent to your wallet; check your balance for confirmation.

### **Key Notes**

* Commissions are non-retroactive; only transactions via your referral link qualify.
* Fraudulent activity or manipulation will result in forfeited earnings.
* Rules and rates may evolve; check updates regularly.

**Join the Orbiter Finance Referral Program, leverage your social circle or community to promote our cross-chain bridge, and easily earn commissions while helping more people experience the convenience and efficiency of cross-chain transactions!**


# Quest


# task verification specification

Orbiter Quest supports any third party to provide a mission verification interface. As long as you follow the interface specifications, your mission can be verified in our Quest.

### Custom task interface verification interface specification

### API Overview

* **API Endpoint**: `/verify/xxxx`
* **HTTP Method**: `GET`
* **Functionality**: Verifies whether a user has completed a task.
* **Use Case**: Third-party projects can use this API to validate user task completion and return the results to the Orbiter platform.

***

### Authentication

* **Is Authentication Required?**: Optional.
* **Authentication Method**: If authentication is required, provide an API key in the request header in the following format:

  ```
  Authorization: Bearer <API_KEY>
  ```

***

### Request Headers

| Header        | Required | Description                                                        |
| ------------- | -------- | ------------------------------------------------------------------ |
| Content-Type  | Yes      | The content type of the request body, fixed as `application/json`. |
| Authorization | No       | API key in the format `Bearer <API_KEY>`.                          |

***

### Request Query

<table><thead><tr><th width="112.93359375">Field Name</th><th width="84.6484375">Type</th><th width="98.4609375">Required</th><th>Description</th></tr></thead><tbody><tr><td>tweetId</td><td>string</td><td>No</td><td><code>tweetId</code></td></tr><tr><td>address</td><td>string</td><td>Yes</td><td>The user's wallet or account address.</td></tr></tbody></table>

#### Example Request

```http
GET /v1/verify?address="0x1234abcd..."

Authorization: Bearer sk_test_abcdef123456
```

***

### Response Body

<table><thead><tr><th width="113.43359375">Field Name</th><th width="139.02734375">Type</th><th>Description</th></tr></thead><tbody><tr><td>isValid</td><td>boolean</td><td>Indicates whether the verification passed (<code>true</code>) or failed (<code>false</code>).</td></tr><tr><td>message</td><td>string</td><td>A human-readable result or error message.</td></tr><tr><td>result</td><td>object</td><td>Optional, strategy-specific return data, e.g., <code>{ "count": 1 }</code>.</td></tr></tbody></table>

#### Example Response

```json
{
  "isValid": true,
  "message": "Verification succeeded",
  "result":null
}
```

***

### Error Response

When a request fails, the API will return an error response with the following fields:

<table><thead><tr><th width="134.57421875">Field Name</th><th width="125.91015625">Type</th><th>Description</th></tr></thead><tbody><tr><td>isValid</td><td>boolean</td><td>Should be <code>false</code>, indicating the verification failed.</td></tr><tr><td>message</td><td>string</td><td>Detailed error description.</td></tr><tr><td>result</td><td>object</td><td>Optional.</td></tr></tbody></table>

#### Example Error Response

```json
{
  "isValid": false,
  "message": "The provided txHash is invalid."
}
```

***

### Notes

1. **Optional Authentication**: If the `Authorization` header is not provided, the API will determine access based on its configuration.
2. **Request Body Validation**:
   * The `input` field must contain valid external data (e.g., `txHash` or `tweetId`).
   * The `address` field must be a valid wallet address.
3. **Response Time**: The API's response time may vary depending on the complexity of the external data validation.

***

### FAQs

#### 1. What happens if the `Authorization` header is not provided?

* If authentication is required, the API will return a `401 Unauthorized` error.
* If authentication is optional, the API will process the request based on default permissions.

#### 2. How should verification failures be handled?

* If `isValid` is `false`, use the information in the `message` field to guide users in correcting their input data.

***

### Contact Us

If you encounter any issues while using the API, please contact us via the following channels:

* **Email**: <techsupport@orbiter.finance>
* **Website**: <https://orbiter.finance>


# L2 Data

Orbiter L2 Data is an on-chain data aggregation and data analysis platform specifically for the Ethereum layer 2 ecosystem(Rollup Ecosystem).

The current volume on L2 chains should not be underestimated as the ecosystem is growing fast and more users are being onboarded. The Orbiter team always believes that the future of Ethereum is bound to be coexistence of both Ethereum and L2s. We are committed to providing more comprehensive, scientific, and effective on-chain data services about rollups ecology for individual investors, institutions, and developers. Together we will witness the development of Ethereum L2.

To this end, we have designed data products including "Rollups Data", "Dapp data", and "New Contract". We have also refined the data metrics and analytics dimensions to provide our data users with more reference value. Based on this, users can further conduct in-depth research on the L2 ecosystem, track L2 hotspots and trends, and explore value targets. We only support Dapp data on arbitrum, optimisim and zksync at present. More dapp data in the rollup ecosystem will be available in the future.

#### Data Resources <a href="#data-resources" id="data-resources"></a>

Our database contains transaction data only (without event/internal transactions). The data is updated **ONCE** a day at UTC 00:00, however, the latest results are not published immediately. The RPC endpoints are the source of most of our data. If that still doesn't meet our needs, we use external APIs from the official rollup explorer.

#### Our Metrics <a href="#our-metrics" id="our-metrics"></a>

Below is a list of currently available core metrics and their definitions on Orbiter L2 Data, provided with different statistical granularity (e.g. from launch to date, last day, last month, etc.). With our lists and charts, you can get an development overview of the rollups & dapp, do trend analysis, growth analysis, and ranking Comparison.

**Accounts & Transactions**

"Accounts" refers to the L2 accounts deployed on rollups, "Transactions" refers to the transactions during a specified time period initiated and completed at L2 that have been verified on Ethereum.

**TVL**

"TVL(Total-value-locked)" refers to the overall value of crypto assets deposited in the rollups' contract deployed on the mainnet. Breakdown: The assets are classified into three types:

1. BTC - Only WBTC & ETH are counted.
2. Stable Coins - Only USDT, USDC, BUSD, DAI are counted.
3. Other - ERC20 tokens other than the above.

**Users & User Age**

"User" refers to the L2 accounts (unique address) interacting with dapp/dapp contracts. "User Age" refers to the cumulative days since users started the first transaction on the mainnet.

**Active Users/Accounts**

"Active Users/Accounts" refers to the L2 accounts (unique address) are active (have interacted with the project contract) during a specific time period, such as in the last day /week /month.

**New Users/Accounts**

"New Users/Accounts" refers to the L2 accounts (unique address) that have interacted with the project's contract for the first time during a specified time period, such as in the last day /week /month. Usually, the growth stage or maturity of a project can be observed with the help of its percentage of new users.

**Interactions**

"Interactions" refers to the number of user interactions with a dapp/dapp's contract, to a large extent, it represents the transactions on dapps.

**New Contracts**

"New contracts" refers to the new contracts on the chain that are in high frequency calls within the last day (these contracts exclude ERC20 token addresses and are not included in the dapp contracts known to Orbiter and may be attributed to a new project).

Our principles for on-list are:

1. To meet "launch time within 60 days".
2. To meet "the number of unique addresses interacting with the contracts or the interactions in the top 100 ".
3. Also to meet "number of interactions/number of unique addresses for interactions< 5".


# Other Projects

**Orbiter Module**

Open 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 theSender's needs via RPC data. It is a tool provided to Navigator.

**Dashboard**

Open sourced: <https://github.com/Orbiter-Finance/OrbiterModule>

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: <https://github.com/Orbiter-Finance/OB\\_ReturnCabin>

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: <https://github.com/Orbiter-Finance/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 (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.


# Ultra Bridge

Your First Own Ultra Bridge

## What is Orbiter Ultra Bridge?

**Orbiter Ultra Bridge** is the **gateway** to exploring new worlds (L1s & L2s & more). Here you will easily get your own user-friendly and customizable **Native Bridge** application to begin building new ecosystems.

Your first ultra bridge will **launch** here!

<figure><img src="/files/pbRpKghLZPev04nTPTWB" alt="ENI Mainnet &#x26; ENI Testnet"><figcaption><p><a href="https://eni.orbiter.finance/">L1: ENI Network</a></p></figcaption></figure>

***

## Features

> What **new feature** looking forward to? Contact me [Here](mailto:marilynquan@orbiter.finance).&#x20;

<figure><img src="/files/Pmri3BwDLXsTclYHbRJV" alt=""><figcaption></figcaption></figure>

### **Highlights:**

**Versatility**: Supports L1s, L2s, and more.

**User-friendly** : Premium UX with highly tailored customization

**Pricing**: The most affordable native bridge pricing on the marke

### **Premium:**

**Liquidity**: Rapidly customizable access to liquidity across 100+ networks ([Bridge Protocol](/welcome/bridge-protocol))

**Scalability**: Supports **EVM** and **non-EVM** chains (SVM and more)

**Interoperability**: Orbiter messaging protocol (OMP) and Orbiter Smart transaction protocol (OSTP)

***

## Workflow

> Exploring the Seamless Integration of **Technical Architecture** and **Efficient Services**

<figure><img src="/files/46JtW6UlRs6s1z0HwvRT" alt=""><figcaption></figcaption></figure>

### **Business**

**Requirement Box**: Technology Preferences and Brand Preferences&#x20;

**Solution Pool**: L1 Stack and L2 Stack (EVM or Non-EVM)

**Bridge UX:** Rapid Integration & Rapid Delivery ( On One day)&#x20;

<figure><img src="/files/RNsMljdPlQKbWg8YLkyb" alt=""><figcaption></figcaption></figure>

### Technology

**VM-AL**: Virtual machine adaptation layer (Unified **Paradigm**)&#x20;

**OMP**: Orbiter messaging protocol (Unified **Communication**)&#x20;

**OSIP**: Orbiter Smart Intent protocol (Unified **Intent**)&#x20;

***

## Pricing

> **Premium** **customization** **services**, please contact me [Here](mailto:marilynquan@orbiter.finance).

<table><thead><tr><th width="145.4453125">Stage</th><th width="208.609375">Fixed (Once)</th><th width="274.46484375">Dynamic Subscription (Monthly)</th></tr></thead><tbody><tr><td>Pre</td><td>20,000 USDT/USDC</td><td>/</td></tr><tr><td>0~3 month</td><td>/</td><td>Free</td></tr><tr><td>>3 month</td><td>/</td><td>1000 USDT (Basic)</td></tr></tbody></table>

***

## FAQ

### **What is Native Bridge?**

**Native Bridge** is a cross-chain channel built directly into a blockchain’s core protocol. Instead of handing assets to third-party contracts or relayers, the two related chains (for example a mainnet and its side chain, L2, or shard) use built-in validation logic to “lock and mint / unlock” assets. Security is therefore tied to the consensus and upgrade processes of the chains themselves, rather than to external custodians.

### **What is the difference between Native bridge and Liquidity bridge?**

**Native Bridge** is like an official tunnel directly connecting two railways: the blockchains’ core protocols lock the asset on one side and mint or release it on the other.&#x20;

**Liquidity Bridge** is more like two currency-exchange booths that each keep a cash reserve; you deposit tokens into the bridge’s liquidity pool and immediately receive the equivalent asset already sitting on the target chain—no new tokens are minted. Native bridges inherit the security guarantees of the connected chains but usually handle only the chains’ “official” assets, whereas liquidity bridges are faster and support more assets but depend on the size of their liquidity pools and the security of their smart contracts.

### **Which chains are supported?**&#x20;

**L1**:  Ethereum Bitcoin Solana and more.

**L2**: Arbitrum Optimism Base and more.

**Others:** any [here](mailto:marilynquan@orbiter.finance)


# Supported Chains

All testnet networks and mainnet networks we currently support

## Mainnet

| ChainID                         | Name               | NativeCurrency | VMType    |
| ------------------------------- | ------------------ | -------------- | --------- |
| 1                               | Ethereum           | ETH            | EVM       |
| 10                              | Optimism           | ETH            | EVM       |
| 30                              | Rootstock          | BTC            | EVM       |
| 56                              | BNB Chain          | BNB            | EVM       |
| 130                             | Unichain           | ETH            | EVM       |
| 137                             | Polygon            | MATIC          | EVM       |
| 146                             | Sonic              | S              | EVM       |
| 169                             | Manta              | ETH            | EVM       |
| 173                             | ENI                | EGAS           | EVM       |
| 177                             | HashKey            | HSK            | EVM       |
| 185                             | Mint               | ETH            | EVM       |
| 196                             | X Layer            | OKB            | EVM       |
| 204                             | OPBNB              | BNB            | EVM       |
| 223                             | B² Network         | BTC            | EVM       |
| 252                             | Fraxtal            | FRAX           | EVM       |
| 324                             | ZKSyncEra          | ETH            | EVM       |
| 480                             | World Chain        | ETH            | EVM       |
| 690                             | Redstone           | ETH            | EVM       |
| 1101                            | Polygon zkEVM      | ETH            | EVM       |
| 1116                            | Core Blockchain    | CORE           | EVM       |
| 1135                            | Lisk               | ETH            | EVM       |
| 1514                            | Story              | IP             | EVM       |
| 1625                            | Gravity            | G              | EVM       |
| 1868                            | Soneium            | ETH            | EVM       |
| 2020                            | Ronin              | RON            | EVM       |
| 2741                            | Abstract           | ETH            | EVM       |
| 2818                            | Morph              | ETH            | EVM       |
| 4200                            | Merlin             | BTC            | EVM       |
| 5000                            | Mantle             | MNT            | EVM       |
| 7000                            | ZetaChain          | ZETA           | EVM       |
| 7560                            | Cyber              | ETH            | EVM       |
| 8217                            | Kaia               | KLAY           | EVM       |
| 8453                            | Base               | ETH            | EVM       |
| 9736                            | BomeChain          | BOME           | EVM       |
| 11501                           | BEVM               | BTC            | EVM       |
| 33139                           | ApeChain           | APE            | EVM       |
| 34443                           | Mode               | ETH            | EVM       |
| 42161                           | Arbitrum           | ETH            | EVM       |
| 42170                           | Arbitrum Nova      | ETH            | EVM       |
| 42220                           | Celo               | CELO           | EVM       |
| 42766                           | ZKFair             | USDC           | EVM       |
| 43111                           | Hemi               | ETH            | EVM       |
| 43114                           | Avalanche          | AVAX           | EVM       |
| 48900                           | Zircuit            | ETH            | EVM       |
| 50104                           | Sophon             | SOPH           | EVM       |
| 55244                           | Superposition      | ETH            | EVM       |
| 57073                           | Ink                | ETH            | EVM       |
| 59144                           | Linea              | ETH            | EVM       |
| 60808                           | BOB                | ETH            | EVM       |
| 70700                           | Proof of Play Apex | ETH            | EVM       |
| 80094                           | Berachain          | BERA           | EVM       |
| 81457                           | Blast              | ETH            | EVM       |
| 98865                           | Plume              | ETH            | EVM       |
| 167000                          | Taiko              | ETH            | EVM       |
| 200901                          | Bitlayer           | BTC            | EVM       |
| 534352                          | Scroll             | ETH            | EVM       |
| 543210                          | Zero               | ETH            | EVM       |
| 747474                          | Katana             | ETH            | EVM       |
| 810180                          | zkLink Nova        | ETH            | EVM       |
| 7777777                         | Zora               | ETH            | EVM       |
| 21000000                        | Corn               | BTC            | EVM       |
| 728126428                       | Tron               | TRX            | TRONVM    |
| ECLIPSE\_MAIN                   | Eclipse            | ETH            | SOLANAVM  |
| FUEL\_MAIN                      | Fuel               | ETH            | FUELVM    |
| HYPERLIQUID                     | Hyperliquid        | USDC           | HYPERCORE |
| immutableX                      | Immutable X        | ETH            | IMXVM     |
| MOVEMENT\_MAIN                  | Movement           | MOVE           | APTOSVM   |
| PRIVATE\_SN\_PARACLEAR\_MAINNET | Paradex            | FUEL           | CAIROVM   |
| SN\_MAIN                        | Starknet           | ETH            | CAIROVM   |
| SOLANA\_MAIN                    | Solana             | SOL            | SOLANAVM  |
| SONIC\_MAIN                     | Sonic SVM          | SOL            | SOLANAVM  |
| SUI\_MAIN                       | Sui                | SUI            | SUIVM     |
| TON                             | TON                | TON            | TVM       |
| zksync                          | zkSync Lite        | ETH            | ZKLITEVM  |

## Testnet

<table data-full-width="true"><thead><tr><th>name</th><th width="216" align="center">chainId</th></tr></thead><tbody><tr><td>Starknet Sepolia</td><td align="center">SN_SEPOLIA</td></tr><tr><td>Optimism Sepolia</td><td align="center">11155420</td></tr><tr><td>ImmutableX Sepolia</td><td align="center">immutableX_test</td></tr><tr><td>BSC TestNet</td><td align="center">97</td></tr><tr><td>Polygon Cardona Sepolia</td><td align="center">2442</td></tr><tr><td>Katla</td><td align="center">167008</td></tr><tr><td>Base Sepolia</td><td align="center">84532</td></tr><tr><td>Linea Sepolia</td><td align="center">59141</td></tr><tr><td>OpBSC TestNet</td><td align="center">5611</td></tr><tr><td>Sepolia</td><td align="center">11155111</td></tr><tr><td>X1 Sepolia</td><td align="center">195</td></tr><tr><td>Scroll Sepolia</td><td align="center">534351</td></tr><tr><td>Combo TestNet</td><td align="center">1715</td></tr><tr><td>Zora Sepolia</td><td align="center">999999999</td></tr><tr><td>Stylus Sepolia</td><td align="center">23011913</td></tr><tr><td>Arbitrum Sepolia</td><td align="center">421614</td></tr><tr><td>Kroma Sepolia</td><td align="center">2358</td></tr><tr><td>zkera Sepolia</td><td align="center">300</td></tr><tr><td>Blast Sepolia</td><td align="center">168587773</td></tr><tr><td>Berachain Sepolia</td><td align="center">80085</td></tr><tr><td>BEVM Sepolia</td><td align="center">1502</td></tr><tr><td>Frame Sepolia</td><td align="center">68840142</td></tr><tr><td>B² Haven Testnet</td><td align="center">1123</td></tr><tr><td>zkLink Nova Sepolia</td><td align="center">810181</td></tr><tr><td>Zircuit Sepolia</td><td align="center">48899</td></tr><tr><td>Holesky</td><td align="center">17000</td></tr><tr><td>Solana</td><td align="center">SOLANA_DEV</td></tr><tr><td>Morph Testnet</td><td align="center">2710</td></tr><tr><td>Mint Sepolia</td><td align="center">1687</td></tr><tr><td>TON Testnet</td><td align="center">TON_TEST</td></tr><tr><td>Bob Testnet</td><td align="center">111</td></tr><tr><td>Karak Testnet</td><td align="center">8054</td></tr><tr><td>vizing Testnet</td><td align="center">28516</td></tr><tr><td>Zulu Testnet</td><td align="center">90104</td></tr></tbody></table>


# FAQ

**Token Release Schedule:**

There is currently no official confirmation regarding the Token Generation Event (TGE). We kindly request that you refrain from disseminating or giving credence to any information originating from sources other than Orbiter Finance's official communication channels. Orbiter Finance team's primary focus is currently directed towards product development and enhancing the user experience. Any updates regarding token release will be communicated through official channels such as [Twitter](https://twitter.com/Orbiter_Finance) or [Discord](https://discord.gg/FbztTBvnBT).

**Providing Liquidity on Orbiter Finance:**

Our future plans include the introduction of the Maker system, offering the opportunity to everyone to become a Maker. Makers will be able to contribute liquidity and generate income within Orbiter Finance’s ecosystem. For more in-depth information, please refer to ‘Maker System’ Section.

**Contract Auditing at Orbiter Finance:** Orbiter Fiance recognizes the critical importance of contract auditing. We are committed to engaging a reputable auditing agency to thoroughly assess all contracts prior to the launch, ensuring the utmost security and reliability.

**Assistance Required for Bridge Transaction Issues:**

Should you require assistance with a bridge transaction issue, kindly initiate the process by opening a support ticket through the [Create Ticket](https://discord.gg/FbztTBvnBT). Our team will promptly attend to your query.

Before submitting a ticket, we encourage you to perform a preliminary check by visiting the following link: [History](https://www.orbiter.finance/history). In the webpage, please navigate to the 'Search' tab, where you can search for your transaction history. If you are able to locate your transaction, kindly provide the following details in your support ticket:

* From Network/Chain: \[Your Input]
* To Network/Chain: \[Your Input]
* Transaction-Hash: 0x\[Your Input]
* Wallet Address: 0x\[Your Input] This will expedite the resolution process and assist us in better addressing your specific concern. Thank you.

**About Community Role Inquiry Clarification:**

Kindly take note that all of your transactions have been meticulously documented on the blockchain, even if the Guild's role display does not reflect this information. Rest assured, we possess verifiable evidence of your transaction history, so there is no need for concern. It is important to understand that our Moderators do not possess the authority to grant Discord roles. We kindly request that you refrain from opening support tickets specifically for role-related inquiries.

**Other Tech-wise Questions:**

Please refer to our open resourced [Github](https://github.com/Orbiter-Finance) for detailed information.

**Marketing Collaboration Inquires:**

We are happy to witness good ideas sparkle. Please kindly fill in relevant information in the [form](https://forms.gle/oXXUeQJoTp9VzU3SA) as required, we will get back to you ASAP. Let’s shine together, sky is the limit!


# O-Points

To better serve our users, Orbiter Finance has introduced O-Points, aimed at recognizing and recording user contributions on the platform while effectively tracking each user's loyalty contributions.

#### What are O-Points used for?

You can visit <https://www.orbiter.finance/> and connect your wallet to view the O-Points held by your address as well as the honors of Pilot NFTs on the O-Points dashboard. Historical bridged transactions and third-party platform points will be automatically retroactively applied, with a snapshot taken at the time of O-Points’ initial launch. Contributions from activities such as NFT-related rewards, community services, and early Grant funding will also gradually receive retrospective rewards in the future.

#### Components of O-Points

The calculation of O-Points consists of four parts: Basic Points, Activity Points, Card Points, and Ecosystem Points.

1. **Basic Points**: Basic contribution rewards for using Orbiter Finance’s bridging services.
2. **Activity Points**: Task rewards for participating in Orbiter Finance-related activities.
3. **Card Points**: Completing any 3 transactions (such as Bridge/Swap/Bundle) will earn a card, and the card will randomly provide points within a designated range.
4. **Ecosystem Points**: Rewards for interacting with Orbiter's ecosystem dApp based on the Orbiter Cross-Rollup Protocol.

#### Basic Points and Exchange Standards

All historical transactions you conduct using Orbiter Finance’s bridging service will be converted into Basic Points according to specific standards based on different bridged tokens and destination networks. Following the historical retroactive application of O-Points, each newly added bridged transaction will be recorded and updated to your account’s Basic Points on the same day.

**Sources of Points:**

1. **Transaction Points**: Only **Swap cross-chain transactions**, **basic bridging transactions**, and **Collector transactions** will earn points.
   * **Note**: Same-chain transactions will not earn points for now.
   * Calculation Method: Based on the transaction amount and fees, dynamically calculated and displayed on the page.
2. **Activity Points**: Daily check-ins, regular activities, Quest activities
   * Calculation Method: Calculated according to the rules defined for each activity.
3. **Card Points**:
   * Completing 3 transactions (such as Bridge, Swap, or Bundle) will earn you a card, and the card will randomly reward points within a specific range.
4. **Ecosystem Points**:
   * Interactions with Orbiter’s ecosystem dApp based on the Orbiter Cross-Rollup Protocol will earn rewards.

#### Activity Points and Exchange Standards

For users who have existing points on platforms such as Galxe, TaskOn, and QuestN, we will retrospectively convert those platform points into Activity Points according to the following standards.

**Activity Platforms:**

* **Galxe**: 20:1
* **QuestN**: 10:1
* **TaskOn**: 2:1

We encourage users to actively participate in various activities within Orbiter Finance, especially the tasks presented on the O-Points frontend (official website). During the O-Points activity period, completing relevant cross-chain tasks will not only earn Basic Points but also provide additional Activity Points as rewards. If a transaction fulfills multiple simultaneous activity tasks, the task reward will be received only once (typically for the most recently released activity task).

#### About the Address:

O-Points will be granted based on the "From Address".

For example:

* From **Arbitrum** to any other chain, O-Points will be calculated to the Arbitrum address.
* From **Starknet** to any other chain, O-Points will be calculated to the Starknet address.
* From **Solana** to any other chain, O-Points will be calculated to the Solana address.

#### Conclusion:

The O-Points system is a way for us to recognize user participation and contributions, aimed at promoting a vibrant and interactive community within the Orbiter Finance ecosystem. We will continue to optimize this system, adjusting and refining it based on user feedback, ensuring a fair and mutually beneficial experience for all our users.

For any further details or inquiries about the O-Points system, feel free to contact our support team on Discord.

Orbiter Finance will continue to delve deeper into ZK technology, developing a decentralized cross-Layer2 interoperability protocol, aiming to become the Ethereum Acceleration Engine. We look forward to having all our pilots join us on this journey!


# Maker Addresses

Maker Addresses for Our Cross-Chain Bridge Service

<table><thead><tr><th width="420.0859375">Wallet Address</th><th width="111.41015625" align="center">Token</th><th width="168.45703125">Blockchain Type</th></tr></thead><tbody><tr><td>0x3bdb03ad7363152dfbc185ee23ebc93f0cf93fd1</td><td align="center">ETH</td><td>Ethereum (EVM)</td></tr><tr><td>0xacc517ea627ceb71cf25e002adaa9761623837b9</td><td align="center">USDC</td><td>Ethereum (EVM)</td></tr><tr><td>0x9c6750d463ad17deec97a630af766f0a78f95127</td><td align="center">USDT</td><td>Ethereum (EVM)</td></tr><tr><td><del>0xa383a72e000c056cceaa9305b7b5d2d90887fbfd</del></td><td align="center">ETH</td><td>Ethereum (EVM)</td></tr><tr><td><del>0xa8bd77769c875f8490e4b49f4c02a1dd83d21a18</del></td><td align="center">BTC</td><td>Ethereum (EVM)</td></tr><tr><td>0x095d2918b03b2e86d68551dcf11302121fb626c9</td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0xe4edb277e41dc89ab076a1f049f4a3efa700bce8</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td>0x1c84daa159cf68667a54beb412cdb8b2c193fb32</td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0x8086061cf07c03559fbb4aa58f191f9c4a5df2b2</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0xee73323912a4e3772b74ed0ca1595a152b0ef282</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0x80c67432656d59144ceff962e8faf8926599bcf8</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0x41d3d33156ae7c62c094aae2995003ae63f587b3</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0xd7aa9ba6caac7b0436c91396f22ca5a7f31664fc</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td><del>0xe01a40a0894970fc4c2b06f36f5eb94e73ea502d</del></td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td>0xab0c8fbec583f20c97f9fda6a2af647b94c8e54d</td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td>0x732efacd14b0355999aebb133585787921aba3a9</td><td align="center">OPOOL</td><td>Ethereum (EVM)</td></tr><tr><td>0x34723b92ae9708ba33843120a86035d049da7dfa</td><td align="center"></td><td>Ethereum (EVM)</td></tr><tr><td>TYyMhrXmiAcQcwZPQjPxLwkpaPXaYaJYw5</td><td align="center">USDT</td><td>TRON</td></tr><tr><td>FnPuDRwubjfPKsvcDjU9vnCyExbnTofWikMBXaJcvyZd</td><td align="center">ETH</td><td>Eclipse</td></tr><tr><td>DowTWse9Sjzj1kN1V6zevfGtQ6wWpigug7TPCdTr6UNP</td><td align="center">USDC</td><td>Solana</td></tr><tr><td>Fmfmay8KzgEvF7NGWRjgFcki2Zy79sa8qXCw9pXTJ5Et</td><td align="center">OPOOL</td><td>Solana</td></tr><tr><td>UQBN1z9drcrBbuKgJMYBQdV4c58XymfTooTZ3aZJzdc2IHHN</td><td align="center">USDT，USDC</td><td>TON</td></tr><tr><td>0x6aaf1fec9df603fb18c5d8e9b0a20648a89f3739d87c512ad8ae6f9b45ca2635</td><td align="center">ETH</td><td>Movement</td></tr><tr><td>0x07b393627bd514d2aa4c83e9f0c468939df15ea3c29980cd8e7be3ec847795f0</td><td align="center"></td><td>Starknet</td></tr><tr><td>0x064a24243f2aabae8d2148fa878276e6e6e452e3941b417f3c33b1649ea83e11</td><td align="center">ETH</td><td>Starknet</td></tr><tr><td>0x0411c2a2a4dc7b4d3a33424af3ede7e2e3b66691e22632803e37e2e0de450940</td><td align="center">USDC, USDC</td><td>Starknet</td></tr><tr><td>0xe485bc364e5baf7365e772ce8911d5f67aa983adf8469d92bb7d29c4cd5f459a</td><td align="center">ETH</td><td>Fuel</td></tr><tr><td>0xb4a3550dbf381f2e1c10be840b685f81c2d070d158cab20dc2fb9e0383885d3a</td><td align="center">USDC</td><td>Sui</td></tr><tr><td>0xed01d58fe6433a5fe69720a0aa0ab1d1fdb15212</td><td align="center">ALL-TOKEN</td><td>Ethereum (EVM)</td></tr><tr><td>0x06e18dd81378fd5240704204bccc546f6dfad3d08c4a3a44347bd274659ff328</td><td align="center">ALL_TOKEN</td><td>Starknet</td></tr><tr><td>0xc52f699d2f64349c85071d0b141c8067405481f2ee66c301e712149d6ef1ae22</td><td align="center">ALL-TOKEN</td><td>SUI</td></tr><tr><td>UQAoGjcF5SEakLL3SMmOivnulB5rtmhB6QiANicdqQ3IteMK</td><td align="center">ALL-TOKEN</td><td>Solana</td></tr></tbody></table>


# Security Audits

#### **Security Audits & Contract Verification** **Safeguarding Every Cross-Chain Asset with Uncompromising Security**

🔒 **Why Security Audits Matter?**\
In decentralized cross-chain interactions, smart contracts are the **core safeguard** for user assets. We fully recognize the gravity of this responsibility. That’s why we proactively engage globally renowned security firms to conduct **Slowmist  audits** of our cross-chain bridge contracts, ensuring:

✅ **Zero-vulnerability implementation** of asset locking/release mechanisms\
✅ **Reliability** of multi-signature and permission control systems\
✅ **Robust fault tolerance and rollback capabilities** under extreme scenarios\
✅ **Attack-resistant design** for cross-chain message verification mechanisms

***

#### **Key Features Highlighted**

* **Zero Vulnerabilities**: Rigorous auditing eliminates risks in asset flow logic.
* **Multi-Layer Security**: Combines cryptographic proofs and decentralized governance.
* **Battle-Tested Resilience**: Simulated attacks validate protocol robustness.

***

### *Official Cross-Chain Bridge*

{% file src="/files/vVgLdhpZCdZx6JAiIxva" %}

### *Decentralized Maker*

{% file src="/files/UfC3pmK010KAQ26xbMQV" %}

***

### *Swap & Bridge & OPOOL*

{% file src="/files/lfDOEkrMS9BtchDQEVb6" %}


# Testing Integration

Run test transactions on mainnets.

**Importance of Running Test Transactions on Mainnets**

1. **Real Environment Validation**

* Mainnets provide the most realistic testing scenarios
* Validates actual fund flows and contract interactions
* Ensures all functionalities work properly in production

2. **Testnet Limitations**

* Most bridges and exchanges have limited testnet support
* Extremely low liquidity makes effective testing difficult
* Testnet environments may differ from mainnet

3. **Mainnet Advantages**

* Full liquidity support
* 100% functionality availability
* Direct validation of actual economic models

4. **Testing Recommendations**

* Start with small amounts for initial verification
* Gradually scale up testing volume
* Monitor all transaction statuses

5. **Important Notes**

* Ensure contracts have been audited
* Set appropriate gas limits
* Maintain complete transaction records

We strongly recommend conducting all integration tests on mainnets as this represents the best practice for ensuring system stability and functional integrity.

{% hint style="info" %}
To minimize costs, we recommend testing on chains with low gas fees. Optimism and other Layer 2 (L2) chains are excellent choices for cost-effective testing.
{% endhint %}


# Orbiter Skills — Usage Guide

### Repository

GitHub repository:

```txt
https://github.com/Orbiter-Finance/bridge-skills
```

***

### Overview

Orbiter Finance MCP + Skills + CLI is a toolkit for “one‑click cross‑chain” onboarding. It includes:

* MCP Server
* AI Skills (`skills/`)
* CLI
* Unified API SDK

***

### Installation

#### One‑Command Install

```bash
curl -fsSL https://raw.githubusercontent.com/Orbiter-Finance/bridge-skills/main/install.sh | sh()
```

#### Install via Skills CLI (If You Use It)

```bash
npx skills add Orbiter-Finance/bridge-skills
```

#### Client‑Specific Guides

Client setup guides are provided for:

* Codex
* OpenCode
* Cursor
* Claude
* OpenClaw

#### Supported MCP Clients

* Claude Code
* Cursor
* OpenClaw
* Any MCP‑compatible client (use stdio command)

***

### Environment Variables

Optional variables:

* `ORBITER_API_BASE_URL` (default `https://openapi.orbiter.finance`)
* `ORBITER_API_KEY`
* `ORBITER_PRIVATE_KEY` (only used for local signing in `bridge sign` / `bridge sign-broadcast`)

Security note: the private key is used only for local signing and is never written to disk or sent over the network.&#x20;

***

### MCP Tools

Available MCP tools:

* `orbiter_chains`
* `orbiter_tokens`
* `orbiter_bridge_quote`
* `orbiter_bridge_tx`
* `orbiter_bridge_flow`
* `orbiter_sign_template`
* `orbiter_sign_broadcast`
* `orbiter_transaction`
* `orbiter_wallet_portfolio`
* `orbiter_tx_simulate`
* `orbiter_tx_broadcast`
* `orbiter_rpc_health`

***

### Skills Documentation

Each Skill has its own `SKILL.md` and is the single source of truth for inputs, outputs, and examples.&#x20;

#### Skills Index

* `orbiter-bridge-flow`
* `orbiter-bridge-quote`
* `orbiter-bridge-tx`
* `orbiter-chain-status`
* `orbiter-chains`
* `orbiter-rpc-health`
* `orbiter-sign-broadcast`
* `orbiter-sign-template`
* `orbiter-tokens`
* `orbiter-transaction`
* `orbiter-tx-broadcast`
* `orbiter-tx-simulate`
* `orbiter-tx-track`
* `orbiter-wallet-portfolio`

#### Skills Conventions

* Each `SKILL.md` is the single source of truth.
* Inputs and outputs mirror MCP tool schemas.
* CLI examples use the `orbiter` binary.
* Quotes can include `approve`, `swap`, and `bridge` steps depending on route.
* `orbiter_bridge_flow` can auto‑approve when `autoApprove` and `privateKey` are provided.

***

### CLI — Common Commands

#### Chains and Tokens

```bash
orbiter chains
orbiter chains --raw
orbiter tokens --chain 42161 --prefix ETH
orbiter tokens --chain 42161 --prefix USDC --bridgeable --limit 5
```

#### Quote and Tx

```bash
orbiter bridge quote --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc...
orbiter bridge quote --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount-human 0.0006 --amount-decimals 18 --user 0xabc... --recipient 0xabc... --format summary
orbiter bridge tx --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc...
orbiter bridge tx --source-chain 42161 --dest-chain 42161 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0xaf88d065e77c8cc2239327c5edb3a432268e5831 --amount 600000000000000 --user 0xabc... --recipient 0xabc... --action swap
```

#### Flow (Quote + Signable Tx + Simulate)

```bash
orbiter bridge flow --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc... --chain 42161 --call-on-fail
orbiter bridge flow --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount-human 0.0006 --amount-decimals 18 --user 0xabc... --recipient 0xabc... --format summary
```

#### Auto‑Approve (If Allowance Is Insufficient)

```bash
ORBITER_PRIVATE_KEY=... orbiter bridge flow --source-chain 42161 --dest-chain 8453 --source-token 0x... --dest-token 0x... --amount 1000000 --user 0xabc... --recipient 0xabc... --chain 42161 --auto-approve
```

#### Same‑Chain Swap (ETH → USDC on Arbitrum)

```bash
orbiter bridge quote --source-chain 42161 --dest-chain 42161 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0xaf88d065e77c8cc2239327c5edb3a432268e5831 --amount 600000000000000 --user 0xabc... --recipient 0xabc...
```

#### Sign Template and Broadcast

```bash
orbiter bridge sign-template --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc... --chain 42161
orbiter bridge sign --template-file ./template.json --chain-id 42161
orbiter bridge sign-broadcast --template-file ./template.json --chain-id 42161 --chain 42161
```

#### RPC Health

```bash
orbiter rpc health --chain 42161
```

***

### Local Development

```bash
pnpm install
pnpm -r run build
pnpm -C mcp run dev
pnpm -C cli run dev -- bridge quote --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc...
pnpm -C cli run dev -- bridge tx --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc...
pnpm -C cli run dev -- bridge flow --source-chain 42161 --dest-chain 8453 --source-token 0x0000000000000000000000000000000000000000 --dest-token 0x0000000000000000000000000000000000000000 --amount 300000000000000 --user 0xabc... --recipient 0xabc... --chain 42161 --call-on-fail
```


# REST API


# Overview

Integrate our API directly into your dApp. With our Orbiter REST API, you can easily find the best routes for cross-chain and on-chain swapping and bridging.

### API Endpoints

Production environment APIs:&#x20;

```
https://api.orbiter.finance  /  https://openapi.orbiter.finance
```

#### POST /quote

Get a quote for cross-chain token transactions.

**Request Parameters:**

* `sourceChainId`: Source blockchain network ID
* `destChainId`: Destination blockchain network ID
* `sourceToken`: Source token contract address
* `destToken`: Destination token contract address
* `amount`: Transaction amount in string format
* `userAddress`: User wallet address
* `targetRecipient`: Final transaction recipient address
* `slippage`: Acceptable price fluctuation percentage
* `feeConfig`: Fee configuration object

**Example Request:**

```json
{
  "sourceChainId": "42161",
  "destChainId": "10",
  "sourceToken": "0x0000000000000000000000000000000000000000",
  "destToken": "0x0000000000000000000000000000000000000000",
  "amount": "300000000000000",
  "userAddress": "0xefc6089224068b20197156a91d50132b2a47b908",
  "targetRecipient": "0xefc6089224068b20197156a91d50132b2a47b908",
  "slippage": 0.02,
  "feeConfig": {
    "feeRecipient": "0xefc6089224068b20197156a91d50132b2a47b908",
    "feePercent": "0.1"
  }
}
```

#### GET /chains

Get available blockchain networks.

**Headers:**

* `x-api-key`: API key for authentication

#### GET /transaction/status/{hash}

Query transaction status by hash.

**Path Parameters:**

* `hash`: Transaction hash to query

**Headers:**

* `x-api-key`: API key for authentication (optional)

### Notes for Developers

* All token amounts are represented as strings to preserve precision
* Cross-chain transactions may involve multiple steps shown in the response
* Always check the response status and message fields for success/error information
* Except for the EVM network, the same-chain swap network does not support query transactions


# Execution steps

Performing a cross-chain or swap directly using the API usually requires multiple steps that vary depending on the desired operation and the best path to perform the operation. To simplify the operati

{% stepper %}
{% step %}

### Contact us to get API Key

In most cases, we recommend that you contact us to obtain your API key before going online. You do not need an API key during the integration phase.
{% endstep %}

{% step %}

### Fetching Steps

Call the [Get Quote](https://docs.orbiter.finance/developer/rest-api/api-reference#post-quote) API to start your execution.
{% endstep %}

{% step %}

### Follow the steps in sequence

Iterate over the steps and the items in them and take necessary actions. Steps that do not contain any items or whose array of items is empty should be skipped
{% endstep %}

{% step %}

### Check transaction status

After signing or submitting a step, you should [check the execution progress](https://docs.orbiter.finance/developer/rest-api/api-reference#get-transaction-status-hash)
{% endstep %}

{% step %}

### Success

Once all the steps are complete you can consider the action complete and notify the user.
{% endstep %}
{% endstepper %}


# API Reference

## GET /chains

> Get Chains

```json
{"openapi":"3.0.1","info":{"title":"Default module","version":"1.0.0"},"tags":[{"name":"Third-party Integration API"}],"servers":[{"url":"https://api.orbiter.finance","description":"Production"},{"url":"https://openapi.orbiter.finance","description":"openapi-prod"}],"security":[],"paths":{"/chains":{"get":{"summary":"Get Chains","deprecated":false,"description":"","tags":["Third-party Integration API"],"parameters":[],"responses":{"200":{"description":"","content":{"application/json":{"schema":{"type":"object","properties":{"status":{"type":"string","description":"Request status, 'success' indicates success, 'error' indicates failure"},"message":{"type":"string","description":"Request message, empty when successful, contains error information when failed"},"result":{"type":"array","items":{"type":"object","properties":{"chainId":{"type":"string","description":"Chain ID, unique identifier of the blockchain network"},"internalId":{"type":"integer","description":"Internal ID, chain identifier used within the system"},"name":{"type":"string","description":"Chain name, display name of the blockchain network"},"nativeCurrency":{"type":"object","properties":{"name":{"type":"string"},"symbol":{"type":"string"},"decimals":{"type":"integer"},"coinKey":{"type":"string"},"address":{"type":"string"},"isNative":{"type":"boolean"},"paymaster":{"type":"string"}},"required":["name","symbol","decimals","coinKey","address"]},"vm":{"type":"string"}},"required":["chainId","internalId","name","nativeCurrency","vm"]}}},"required":["status","message","result"]}}},"headers":{}}}}}}}
```

## POST /quote

> Get a Quote

```json
{"openapi":"3.0.1","info":{"title":"Default module","version":"1.0.0"},"tags":[{"name":"Third-party Integration API"}],"servers":[{"url":"https://api.orbiter.finance","description":"Production"},{"url":"https://openapi.orbiter.finance","description":"openapi-prod"}],"security":[],"paths":{"/quote":{"post":{"summary":"Get a Quote","deprecated":false,"description":"","tags":["Third-party Integration API"],"parameters":[],"requestBody":{"content":{"application/json":{"schema":{"type":"object","properties":{"sourceChainId":{"type":"string","description":"Source chain ID, represents the blockchain network ID where the transaction originates"},"destChainId":{"type":"string","description":"Destination chain ID, represents the blockchain network ID where the transaction targets"},"sourceToken":{"type":"string","description":"Source token address, represents the token contract address where the transaction originates"},"destToken":{"type":"string","description":"Destination token address, represents the token contract address where the transaction targets"},"amount":{"type":"string","description":"Transaction amount, represents the token quantity in string format"},"userAddress":{"type":"string","description":"User wallet address, represents the blockchain address of the transaction initiator"},"targetRecipient":{"type":"string","description":"Target recipient address, represents the blockchain address of the final transaction recipient"},"slippage":{"type":"number","description":"Slippage tolerance, represents the acceptable price fluctuation percentage for the user"},"feeConfig":{"type":"object","properties":{"feeRecipient":{"type":"string","description":"Fee recipient address, represents the blockchain address where fees will be sent"},"feePercent":{"type":"string","description":"Fee percentage, represents the fee ratio in string format，"}},"required":["feeRecipient","feePercent"],"description":"Fee configuration, includes fee recipient address and fee percentage,For example, For example,For example, 1=1%"},"channel":{"type":"string","description":"Your dapp name or commission wallet address"}},"required":["sourceChainId","destChainId","sourceToken","destToken","amount","userAddress","targetRecipient"]}}}},"responses":{"200":{"description":"","content":{"application/json":{"schema":{"type":"object","properties":{"status":{"type":"string","description":"Request status, 'success' indicates success, 'error' indicates failure"},"message":{"type":"string","description":"Request message, empty when successful, contains error information when failed"},"result":{"type":"object","properties":{"fees":{"type":"object","properties":{"withholdingFee":{"type":"string","description":"Withholding fee, represents the pre-deducted fee amount in the transaction, formatted as a string number, unit matches feeSymbol"},"withholdingFeeUSD":{"type":"string","description":"Withholding fee USD value, represents the USD amount corresponding to the withholding fee, formatted as a high-precision decimal string"},"swapFee":{"type":"string","description":"Swap fee, represents the fee generated during token exchange, formatted as a string number, '0' indicates no swap fee"},"swapFeeUSD":{"type":"string","description":"Swap fee USD value, represents the USD amount corresponding to the swap fee"},"tradeFee":{"type":"string","description":"Transaction fee, represents the handling fee generated during the transaction, formatted as a string number, unit matches feeSymbol"},"tradeFeeUSD":{"type":"string","description":"Transaction fee USD value, represents the USD amount corresponding to the transaction fee"},"totalFee":{"type":"string","description":"Total fee, represents the sum of all fees (withholding + swap + transaction), formatted as a high-precision decimal string, unit matches feeSymbol"},"priceImpactUSD":{"type":"string","description":"Price impact USD value, represents the degree of impact on market price by the transaction"},"feeSymbol":{"type":"string","description":"Fee token symbol, represents the type of token used for fee collection"}},"required":["withholdingFee","withholdingFeeUSD","swapFee","swapFeeUSD","tradeFee","tradeFeeUSD","totalFee","priceImpactUSD","feeSymbol"]},"steps":{"type":"array","description":"Transaction step details, includes all operation steps required in cross-chain transactions","items":{"type":"object","description":"Detailed information of a single transaction step","properties":{"action":{"type":"string","description":"Transaction action type, e.g. 'bridge' for cross-chain transaction, 'swap' for token exchange"},"tx":{"type":"object","description":"Transaction details, includes transaction data, target address and other information","properties":{"data":{"type":"string","description":"Transaction data, contains encoded transaction parameters, formatted as hexadecimal string"},"to":{"type":"string","description":"Target contract address for the transaction"},"value":{"type":"string","description":"Amount of tokens sent in the transaction"},"gasLimit":{"type":"string","description":"Transaction gas limit"}},"required":["data","to","value","gasLimit"]}}}},"details":{"type":"object","description":"Supplementary information for transaction details","properties":{"sourceTokenAmount":{"type":"string","description":"Source token amount, represents the amount of tokens sent in the transaction, formatted as a string number"},"destTokenAmount":{"type":"string","description":"Destination token amount, represents the amount of tokens received in the transaction"},"rate":{"type":"string","description":"Exchange rate, represents the ratio between source and destination tokens"},"slippageTolerance":{"type":"object","description":"Slippage tolerance configuration","properties":{}},"points":{"type":"integer","description":"Points reward count"},"midTokenSymbol":{"type":"string","description":"Intermediate token symbol, represents the token used during transaction processing"},"minDestTokenAmount":{"type":"string","description":"Minimum destination token amount, represents the minimum acceptable received amount for the user"}},"required":["sourceTokenAmount","destTokenAmount","rate","slippageTolerance","points","midTokenSymbol","minDestTokenAmount"]}},"required":["fees","steps","details"]}},"required":["status","message","result"]}}},"headers":{}}}}}}}
```

## GET /transaction/{hash}

> Query Transaction

```json
{"openapi":"3.0.1","info":{"title":"Default module","version":"1.0.0"},"tags":[{"name":"Third-party Integration API"}],"servers":[{"url":"https://api.orbiter.finance","description":"Production"},{"url":"https://openapi.orbiter.finance","description":"openapi-prod"}],"security":[],"paths":{"/transaction/{hash}":{"get":{"summary":"Query Transaction","deprecated":false,"description":"","tags":["Third-party Integration API"],"parameters":[{"name":"hash","in":"path","description":"User Transaction hash,Query transactions within the last six months","required":true,"schema":{"type":"string"}}],"requestBody":{"content":{"application/json":{"schema":{"type":"object","properties":{}}}}},"responses":{"200":{"description":"","content":{"application/json":{"schema":{"type":"object","properties":{"status":{"type":"string","description":"Request status, 'success' indicates success, 'error' indicates failure"},"message":{"type":"string","description":"Request message, empty when successful, contains error information when failed"},"result":{"type":"object","properties":{"chainId":{"type":"string"},"hash":{"type":"string"},"sender":{"type":"string"},"receiver":{"type":"string"},"amount":{"type":"string"},"symbol":{"type":"string"},"timestamp":{"type":"string"},"status":{"type":"integer","description":"On-chain transaction status: 2=success, 3=failure"},"opStatus":{"type":"integer","description":"0=UserTxPendingConfirm,1 = Waiting for payment, 80 = Refund successful, 96 = Entering payment, 97 = Return waiting for recovery, 98 = Payment successful, pending confirmation, 99 = Payment confirmation successful."},"targetId":{"type":"string"},"targetAmount":{"type":"string"},"targetSymbol":{"type":"string"},"targetChain":{"type":"string"},"points":{"type":"string"},"targetAddress":{"type":"string"}},"required":["chainId","hash","sender","receiver","amount","symbol","timestamp","status","opStatus","targetId","targetAmount","targetSymbol","targetChain","points","targetAddress"]}},"required":["status","message","result"]}}},"headers":{}}}}}}}
```

## GET /transaction/address/{address}

> Query Transaction History

```json
{"openapi":"3.0.1","info":{"title":"Default module","version":"1.0.0"},"tags":[{"name":"Third-party Integration API"}],"servers":[{"url":"https://api.orbiter.finance","description":"Production"},{"url":"https://openapi.orbiter.finance","description":"openapi-prod"}],"security":[],"paths":{"/transaction/address/{address}":{"get":{"summary":"Query Transaction History","deprecated":false,"description":"","tags":["Third-party Integration API"],"parameters":[{"name":"address","in":"path","description":"","required":true,"schema":{"type":"string"}}],"responses":{"200":{"description":"","content":{"application/json":{"schema":{"type":"object","properties":{"status":{"type":"string","description":"Request status, 'success' indicates success, 'error' indicates failure"},"message":{"type":"string","description":"Request message, empty when successful, contains error information when failed"},"result":{"type":"object","properties":{"offset":{"type":"integer"},"limit":{"type":"integer"},"rows":{"type":"array","items":{"type":"object","properties":{"sourceId":{"type":"string"},"targetId":{"type":"string"},"sourceToken":{"type":"string"},"targetToken":{"type":"string"},"sourceChain":{"type":"string"},"targetChain":{"type":"string"},"sourceAmount":{"type":"string"},"targetAmount":{"type":"string"},"finalAmount":{"type":"string","nullable":true},"sourceMaker":{"type":"string"},"sourceAddress":{"type":"string"},"targetAddress":{"type":"string"},"originSymbol":{"type":"string","nullable":true},"originToken":{"type":"string","nullable":true},"originAmount":{"type":"string","nullable":true},"finalSymbol":{"type":"string","nullable":true},"finalToken":{"type":"string","nullable":true},"sourceSymbol":{"type":"string"},"targetSymbol":{"type":"string"},"status":{"type":"integer"},"sourceTime":{"type":"string"},"targetTime":{"type":"string"},"points":{"type":"string"},"txType":{"type":"string"},"sourceTokenInfo":{"type":"object","properties":{"chainId":{"type":"integer"},"address":{"type":"string"},"decimals":{"type":"integer"},"name":{"type":"string"},"symbol":{"type":"string"},"logoURI":{"type":"string"},"coinKey":{"type":"string"}},"required":["chainId","address","decimals","name","symbol","logoURI","coinKey"]},"targetTokenInfo":{"type":"object","properties":{"chainId":{"type":"integer"},"address":{"type":"string"},"decimals":{"type":"integer"},"name":{"type":"string"},"symbol":{"type":"string"},"logoURI":{"type":"string"},"coinKey":{"type":"string"}},"required":["chainId","address","decimals","name","symbol","logoURI","coinKey"]}},"required":["sourceId","targetId","sourceToken","targetToken","sourceChain","targetChain","sourceAmount","targetAmount","finalAmount","sourceMaker","sourceAddress","targetAddress","originSymbol","originToken","originAmount","finalSymbol","finalToken","sourceSymbol","targetSymbol","status","sourceTime","targetTime","points","txType","sourceTokenInfo","targetTokenInfo"]}},"count":{"type":"integer"}},"required":["offset","limit","rows","count"]}},"required":["status","message","result"]}}},"headers":{}}}}}}}
```


# JS SDK

## Orbiter SDK Document

## This SDK is outdated. Please use the API to get a quote.

### 🌕 Overview

* The Orbiter SDK package provides a simplest, out-of-the-box approach to access the Orbiter API to find and execute the best on-chain and cross-chain swapping and bridging.
* For more information about API, please see page: [Orbiter REST API](https://docs.orbiter.finance/developer/rest-api/overview).

### 📦 Installation

You can use following ways to get the latest version of Orbiter SDK.

* npm

  ```shell
  npm install @orbiter-finance/bridge-sdk
  ```
* yarn

  ```shell
  yarn add @orbiter-finance/bridge-sdk
  ```
* pnpm

  ```shell
  pnpm add @orbiter-finance/bridge-sdk
  ```

Feel free to [report](https://discord.com/invite/FbztTBvnBT) if you encounter any problems.

### 👾 Quick Start

* #### Set up the SDK

  ```javascript
  import {  OrbiterClient, ENDPOINT } from "@orbiter-finance/bridge-sdk";
  const orbiter = await OrbiterClient.create({
    apiEndpoint: ENDPOINT.TESTNET,
    apiKey: 'xxxxxx', //optional
    channelId: 'xxxxxx' //optional
  });
  ```
* #### Check Available TradePair

  ```typescript
  const chains: Chain[] = orbiter.getAllChains();

  // choose a chain from list to get availabletokens
  const chain: Chain = { 
    id: '11155111', 
    name: 'Sepolia' 
  };
  const tokens: Token[] = orbiter.getAvailableTokens(chain.id);

  // choose a chain and a token symbol to get available
  const token: Token = { 
    name: "ETH", 
    symbol: "ETH", 
    decimals: 18, 
    address: "0x0000000000000000000000000000000000000000", 
    isNative: true
  };
  const tradePairs: TradePair[] = orbiter.getAvailableTradePairs(chain.id, token.symbol);

  // or directly get all available trade pair

  const tradePairs: TradePair[] = getAllTradePairs();
  ```

  > 💡Tips:
  >
  > * For tradePairs that source chain is EVM type may have 2 kind of router, both EOA and CONTRACT.
  > * For tradePairs that source chain is Starknet and TRON only has CONTRACT router.
  > * For other tardePairs only has EAO router.
* #### Create Router and Send Transaction

  **From EVM Chains**

  ```typescript
  import { Wallet, JsonRpcProvider } from "ethers";

  // choose a tradePair to create router
  const tradePair: TradePair = {
    srcChainId: '11155111',
    dstChainId: '421614',
    srcTokenSymbol: 'ETH',
    dstTokenSymbol: 'ETH',
    routerType: RouterType.EOA
  }
  const router = orbiter.createRouter(tradePair);

  // check min and max value
  const min = router.getMinSendValue();
  const max = router.getMaxSendValue();

  // simulationAmount
  const { sendValue, receiveValue } = router.simulationAmount(min);

  // connect wallet
  const provider = new JsonRpcProvider('https://ethereum-sepolia-rpc.publicnode.com');
  const wallet = new Wallet('privateKey', provider);
  // check if balance sufficient
  const balance = (await provider.getBalance(wallet)).toString();

  // if is erc20 token, need approve
  // const approve = await router.createApprove(account.address, sendValue);
  // const approveResponce = await wallet.sendTransaction(approve);
  // const approveReceipt = await approveRes.wait();

  // create transaction
  const transaction = router.createTransaction(wallet.address, 'receiver', sendValue);
  // send transaction
  const transactionResponce = await wallet.sendTransaction(transaction);
  const transactionReceipt = await transferResponce.wait();

  ```

  **From BTC Chains**

  ```typescript
  import * as bitcoin from 'bitcoinjs-lib'
  import * as ecc from 'tiny-secp256k1';
  import { ECPairFactory, networks } from 'ecpair';

  // choose a tradePair to create router
  const tradePair: TradePair = {
    srcChainId: 'FRACTAL_TEST',
    dstChainId: '11155111',
    srcTokenSymbol: 'BTC',
    dstTokenSymbol: 'BTC',
    routerType: RouterType.EOA
  }
  const router = orbiter.createRouter(tradePair);

  // check min and max value
  const min = router.getMinSendValue();
  const max = router.getMaxSendValue();

  // simulationAmount
  const { sendValue, receiveValue } = router.simulationAmount(min);

  // creat payment
  const network = networks.bitcoin;
  const ECPair = ECPairFactory(ecc); 
  const keyPair = ECPair.fromWIF(btcPrivateKey, network);
  const payment = bitcoin.payments.p2wpkh({
    pubkey: keyPair.publicKey,
    network,
  });

  // create transaction and add output
  const psbt = await router.createTransaction(payment.address, 'receiver', sendValue);
  expect(psbt).toBeDefined();

  // get utxos from chain
  const utxos = ...

  // add inputs
  const script = payment.output;
  utxos.forEach((utxo: any) => {
    const inputData = {
      hash: utxo.txid, 
      index: utxo.vout,
      witnessUtxo: {
        script, 
        value: utxo.satoshi
      },
    }
    psbt.addInput(inputData);
  });

  // estimate fee from oracle or explorer
  const fee = ...

  // add change !!!important!!!
  const change = totalAmount - Number(sendValue) - fee;
  if (change > 0) {
    psbt.addOutput({
      script,
      value: change
    });
  }

  // sign inputs
  for (let i = 0; i < psbt.inputCount; i++) {
    psbt.signInput(i, keyPair);
    psbt.validateSignaturesOfInput(i, (
      pubkey: Buffer,
      msghash: Buffer,
      signature: Buffer,
    ) => ECPair.fromPublicKey(pubkey).verify(msghash, signature));
  }
  psbt.finalizeAllInputs();

  // broadcast
  const broadcastResult = ...

  ```

  **From Tron Chains**

  ```typescript
  import { TronWeb } from 'tronweb';

  // choose a tradePair to create router
  const tradePair: TradePair = {
    srcChainId: '3448148188',
    dstChainId: '11155111',
    srcTokenSymbol: 'JST',
    dstTokenSymbol: 'JST',
    routerType: RouterType.CONTRACT
  }
  const router = orbiter.createRouter(tradePair);

  // check min and max value
  const min = router.getMinSendValue();
  const max = router.getMaxSendValue();

  // simulationAmount
  const { sendValue, receiveValue } = router.simulationAmount(min);


  // connect to tronweb
  const tronWeb = new TronWeb({
    fullHost: 'https://nile.trongrid.io',
    headers: { "TRON-PRO-API-KEY": 'API key' },
    privateKey: 'privateKey'
  })

  // create approve
  const approve = await router.createApprove(address, sendValue);
  // sign and send approve
  const signedApprove = await tronWeb.trx.sign(approve.transaction);
  const approveRes = await tronWeb.trx.sendRawTransaction(signedApprove);

  // create transaction
  const transaction = await router.createTransaction(address, evmAddress, sendValue);
  // sign and send transaction
  const signedTransaction = await tronWeb.trx.sign(transaction.transaction);
  const transferRes = await tronWeb.trx.sendRawTransaction(signedTransaction);

  ```

  **From Starknet Chains**

  ```typescript
  import { Account, Provider, constants, } from 'starknet';

  // choose a tradePair to create router
  const tradePair: TradePair = {
    srcChainId: 'SN_SEPOLIA',
    dstChainId: '11155111',
    srcTokenSymbol: 'ETH',
    dstTokenSymbol: 'ETH',
    routerType: RouterType.CONTRACT
  }
  const router = orbiter.createRouter(tradePair);

  // check min and max value
  const min = router.getMinSendValue();
  const max = router.getMaxSendValue();

  // simulationAmount
  const { sendValue, receiveValue } = router.simulationAmount(min);

  // connect account
  const provider = new Provider({ nodeUrl: constants.NetworkName.SN_SEPOLIA });
  const account = new Account(provider, starknetAddress, privateKey);

  // create approve
  const approve = await router.createApprove(account.address, sendValue);

  // create transaction
  const transaction = router.createTransaction(wallet.address, 'receiver', sendValue);

  // send approve and transaction
  const transactionResponce = await account.execute([approve,transaction]);
  const transactionReceipt = await provider.waitForTransaction(transactionResponce.transaction_hash);

  ```

  **From Solana Chains**

  ```typescript
  import bs58 from "bs58"
  import { Connection, Keypair, TransactionMessage, VersionedTransaction, LAMPORTS_PER_SOL } from '@solana/web3.js'

  // choose a tradePair to create router
  const tradePair: TradePair = {
    srcChainId: 'SOLANA_DEV',
    dstChainId: '11155111',
    srcTokenSymbol: 'USDC',
    dstTokenSymbol: 'USDC',
    routerType: RouterType.EOA
  }
  const router = orbiter.createRouter(tradePair);

  // check min and max value
  const min = router.getMinSendValue();
  const max = router.getMaxSendValue();

  // simulationAmount
  const { sendValue, receiveValue } = router.simulationAmount(min);

  // connect wallet
  const connection = new Connection('solana-endpoint', "confirmed");
  const sender = Keypair.fromSecretKey(bs58.decode('privateKey'));

  // create transaction
  const transfers = await router.createTransaction(sender.publicKey.toString(), 'receiver', sendValue);

  // process transaction
  const blockhash = await connection.getLatestBlockhash();
  const messageV0 = new TransactionMessage({
    payerKey: sender.publicKey,
    recentBlockhash: blockhash.blockhash,
    instructions: [...transfers],
  }).compileToV0Message();
  const transaction = new VersionedTransaction(messageV0);
  transaction.sign([sender]);
  const serializedTransaction = Buffer.from(transaction.serialize());

  // send transaction
  const signature = await connection.sendRawTransaction(
    serializedTransaction
  );

  //check transaction status
  const status = await connection.getSignatureStatus(signature, {
    searchTransactionHistory: false,
  });

  ```

  > 💡Tips:
  >
  > * The function \[createTransfer] will return deferent type of transfer structure which depends on source chain type, for EVM it will be TransactionRequest, for BTC will be a PSBT for Starknet will be Call, etc. For more information please see their official document.
* #### Check Bridge Status

  ```typescript
  const transactionStatus = await orbiter.checkTransactionStatus(hash);
  ```
* #### Check User Opoints and Transaction History

  ```typescript
  // get user Opoints
  const opoints = await orbiter.getUserOpoint(wallet.address);

  // get user transaction history
  const history = await orbiter.getTransactionHistory(wallet.address, 0);
  ```

  > 💡Tips:
  >
  > * For structure of result on these two function, please check [Orbiter REST API](https://docs.orbiter.finance/developer/rest-api/overview).


# Widget

## Coming Soon


# Smart Contract

## Mainnet

<table><thead><tr><th width="140">chainId</th><th width="143">chainName</th><th width="269">OrbiterRouterV3</th><th width="184">OPool</th><th width="227">StarknetOrbiterRouter</th></tr></thead><tbody><tr><td>1</td><td>Ethereum</td><td>0xc741900276cd598060b0fe6594fbe977392928f4</td><td></td><td></td></tr><tr><td>42161</td><td>Arbitrum</td><td>0x6a065083886ec63d274b8e1fe19ae2ddf498bfdd</td><td>0x6285a466a98f513e1f6be29acad27d173d3b3c59</td><td></td></tr><tr><td>zksync</td><td>zkSync Lite</td><td></td><td></td><td></td></tr><tr><td>SN_MAIN</td><td>Starknet</td><td></td><td></td><td>0x058680be0cf3f29c7a33474a218e5fed1ad213051cb2e9eac501a26852d64ca2</td></tr><tr><td>137</td><td>Polygon</td><td>0x653f25dc641544675338cb47057f8ea530c69b78</td><td></td><td></td></tr><tr><td>10</td><td>Optimism</td><td>0x3191f40de6991b1bb1f61b7cec43d62bb337786b</td><td></td><td></td></tr><tr><td>immutableX</td><td>Immutable X</td><td></td><td></td><td></td></tr><tr><td>loopring</td><td>Loopring</td><td></td><td></td><td></td></tr><tr><td>ZKSpace</td><td>ZKSpace</td><td></td><td></td><td></td></tr><tr><td>324</td><td>ZKSyncEra</td><td>0xb4ab2ff34fadc774aff45f1c4566cb5e16bd4867</td><td></td><td></td></tr><tr><td>56</td><td>BSC</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td>0x6285a466a98f513e1f6be29acad27d173d3b3c59</td><td></td></tr><tr><td>42170</td><td>Arbitrum Nova</td><td>0xbea3c3c4f00799b9b053f7ad25024d85e1ad049a</td><td></td><td></td></tr><tr><td>1101</td><td>Polygon zkEVM</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>534352</td><td>Scroll</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>167000</td><td>Taiko</td><td>0x2598d7bc9d3b4b6124f3282e49eee68db270f516</td><td></td><td></td></tr><tr><td>8453</td><td>Base</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>59144</td><td>Linea</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>5000</td><td>Mantle</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>204</td><td>OPBNB</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>196</td><td>X Layer</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>7777777</td><td>Zora</td><td>0x2598d7bc9d3b4b6124f3282e49eee68db270f516</td><td></td><td></td></tr><tr><td>169</td><td>Manta</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>255</td><td>Kroma</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>42766</td><td>ZKFair</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>81457</td><td>Blast</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>7000</td><td>ZetaChain</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>223</td><td>B² Network</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>34443</td><td>Mode</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>810180</td><td>zkLink Nova</td><td>0xb4ab2ff34fadc774aff45f1c4566cb5e16bd4867</td><td></td><td></td></tr><tr><td>SOLANA_MAIN</td><td>Solana</td><td></td><td></td><td></td></tr><tr><td>70700</td><td>Proof of Play Apex</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>4200</td><td>Merlin</td><td>0x4b8a4641c140b3aa6be8d99786fafe47a65869db</td><td></td><td></td></tr><tr><td>11501</td><td>BEVM</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>TON</td><td>TON</td><td></td><td></td><td></td></tr><tr><td>60808</td><td>BOB</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>1116</td><td>Core Blockchain</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>200901</td><td>Bitlayer</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>28518</td><td>Vizing</td><td></td><td></td><td></td></tr><tr><td>6001</td><td>BounceBit</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>62050</td><td>Optopia</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>7560</td><td>Cyber</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>185</td><td>Mint</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>10241024</td><td>AlienxChain</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>48900</td><td>Zircuit</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>252</td><td>Fraxtal</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>122</td><td>Fuse</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr><tr><td>9736</td><td>BomeChain</td><td></td><td>0xbc0e9721c011fc836f518e7e2a759c7220d3d11c</td><td></td></tr><tr><td>2649</td><td>AILayer</td><td></td><td></td><td></td></tr><tr><td>1625</td><td>Gravity</td><td>0x13e46b2a3f8512ed4682a8fb8b560589fe3c2172</td><td></td><td></td></tr></tbody></table>


# Overview


# Aggregator

Aggregator Contract API Documentation

### Overview

The Aggregator contract is a smart contract that handles token swaps, cross-chain bridging, and batch transfers. It implements an upgradeable pattern and includes the following security features:

* Pausable functionality (emergency stop)
* Reentrancy protection
* Access control through ownership

### Core Methods

#### executeSwap

**Function**: Execute token swap

**Parameters**:

```solidity
struct SwapRequest {
    address inputToken;    // Input token address
    address outputToken;   // Output token address
    uint256 inputAmount;   // Input amount
    uint256 minOutputAmount; // Minimum output amount
    uint256 feeAmount;     // Fee amount
    address feeRecipient;  // Fee recipient address
    address recipient;     // Recipient address
    bool unwrapped;        // Whether to unwrap WETH
    bytes extData;        // Extended data
}

struct Call {
    address target;        // Target contract address
    bytes callData;       // Call data
    uint256 value;        // Transfer amount
}
```

**Example**:

```solidity
// Swap ETH to USDC
Aggregator.executeSwap(
    SwapRequest({
        inputToken: address(0),
        outputToken: USDC_ADDRESS,
        inputAmount: 1 ether,
        minOutputAmount: 1900 * 1e6, // 1900 USDC
        feeAmount: 0.01 ether,
        feeRecipient: FEE_RECIPIENT,
        recipient: USER_ADDRESS,
        unwrapped: false,
        extData: ""
    }),
    [Call({
        target: DEX_ADAPTER,
        callData: abi.encodeWithSelector(...),
        value: 0
    })]
){value: 1 ether};
```

**Notes**:

1. Input amount must be greater than 0
2. Fee amount cannot exceed input amount
3. For ETH swaps, msg.value must equal inputAmount
4. Output amount must be greater than minOutputAmount
5. feeAmount can be set to 0 to indicate no fee, in which case feeRecipient must also be set to the 0 address
6. When real-time commission is needed, feeAmount and feeRecipient parameters can be passed

#### executeBridge

**Function**: Execute cross-chain bridge

**Parameters**:

```solidity
struct BridgeRequest {
    address inputToken;    // Input token address
    uint256 inputAmount;   // Input amount
    uint256 feeAmount;     // Fee amount
    address feeRecipient;  // Fee recipient address
    address recipient;     // Recipient address
    bool unwrapped;        // Whether to unwrap WETH
    bytes extData;        // Extended data
}
```

**Example**:

```solidity
// Bridge ETH
Aggregator.executeBridge(
    BridgeRequest({
        inputToken: address(0),
        inputAmount: 1 ether,
        feeAmount: 0.01 ether,
        feeRecipient: FEE_RECIPIENT,
        recipient: USER_ADDRESS,
        unwrapped: false,
        extData: ""
    })
){value: 1 ether};
```

**Notes**:

1. Input amount must be greater than 0
2. Fee amount cannot exceed input amount
3. For ETH bridges, msg.value must equal inputAmount
4. Recipient address cannot be 0
5. feeAmount can be set to 0 to indicate no fee, in which case feeRecipient must also be set to the 0 address
6. When real-time commission is needed, feeAmount and feeRecipient parameters can be passed

### extData Generation Instructions

The extData field is used to pass extended data, formatted as a hexadecimal representation of URL-encoded parameters.

**Field Mapping**:

```typescript
// Field abbreviation to full name mapping
const ContractExtDataField = {
  's': 'slippage', // Slippage
  'app': 'app', // Application/channel (if using 0x00..00, EVM wallet address can be connected to withdraw commission)
  't': 'targetRecipient', // Target recipient
  'c': 'targetChain', // Target chain
  'tt': 'targetToken', // Target token
  'o': 'targetTokenSymbol', // Target token symbol
  'r': 'rebateRate', // Rebate rate
  'e': 'expectValue', // Expected value
  'm': 'minExpectedValue', // Minimum expected value
  'h': 'hash', // Hash
  'ot': 'originToken', // Origin token
  'os': 'originTokenSymbol', // Origin token symbol
  'ov': 'originValue' // Origin value
}
```

**Generation Example**:

```typescript
// Generate extData
function buildExtData(data: Partial<Record<keyof typeof ContractExtDataField, string>>): string {
  const params = new URLSearchParams();

  for (const [key, value] of Object.entries(data)) {
    if (value !== undefined) {
      params.append(key, String(value));
    }
  }

  return Buffer.from(params.toString()).toString('hex');
}

// Usage example
const extData = buildExtData({
  t: '0x123', // Target recipient address
  s: '0.5' // 0.5% slippage
});
```

**Notes**:

1. All values will be converted to string type
2. Empty or undefined fields will be ignored
3. The final result is a hexadecimal string of URL-encoded parameters


# Supported Chains

<table><thead><tr><th width="125.90625">ChainId</th><th width="161.62890625">Name</th><th>Contract</th></tr></thead><tbody><tr><td>1</td><td>Ethereum</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>42161</td><td>Arbitrum</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>zksync</td><td>zkSync Lite</td><td></td></tr><tr><td>SN_MAIN</td><td>Starknet</td><td></td></tr><tr><td>137</td><td>Polygon</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>10</td><td>Optimism</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>immutableX</td><td>Immutable X</td><td></td></tr><tr><td>loopring</td><td>Loopring</td><td></td></tr><tr><td>324</td><td>ZKSyncEra</td><td></td></tr><tr><td>56</td><td>BNB Chain</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>42170</td><td>Arbitrum Nova</td><td></td></tr><tr><td>1101</td><td>Polygon zkEVM</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>534352</td><td>Scroll</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>167000</td><td>Taiko</td><td></td></tr><tr><td>8453</td><td>Base</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>59144</td><td>Linea</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>5000</td><td>Mantle</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>204</td><td>OPBNB</td><td></td></tr><tr><td>196</td><td>X Layer</td><td></td></tr><tr><td>7777777</td><td>Zora</td><td></td></tr><tr><td>169</td><td>Manta</td><td></td></tr><tr><td>255</td><td>Kroma</td><td></td></tr><tr><td>42766</td><td>ZKFair</td><td></td></tr><tr><td>81457</td><td>Blast</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>7000</td><td>ZetaChain</td><td></td></tr><tr><td>223</td><td>B² Network</td><td></td></tr><tr><td>34443</td><td>Mode</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>810180</td><td>zkLink Nova</td><td></td></tr><tr><td>SOLANA_MAIN</td><td>Solana</td><td></td></tr><tr><td>70700</td><td>Proof of Play Apex</td><td></td></tr><tr><td>4200</td><td>Merlin</td><td></td></tr><tr><td>11501</td><td>BEVM</td><td></td></tr><tr><td>TON</td><td>TON</td><td></td></tr><tr><td>60808</td><td>BOB</td><td></td></tr><tr><td>1116</td><td>Core Blockchain</td><td></td></tr><tr><td>200901</td><td>Bitlayer</td><td></td></tr><tr><td>28518</td><td>Vizing</td><td></td></tr><tr><td>62050</td><td>Optopia</td><td></td></tr><tr><td>7560</td><td>Cyber</td><td></td></tr><tr><td>185</td><td>Mint</td><td></td></tr><tr><td>10241024</td><td>AlienxChain</td><td></td></tr><tr><td>48900</td><td>Zircuit</td><td></td></tr><tr><td>252</td><td>Fraxtal</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>122</td><td>Fuse</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>9736</td><td>BomeChain</td><td></td></tr><tr><td>1625</td><td>Gravity</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>728126428</td><td>Tron</td><td></td></tr><tr><td>1135</td><td>Lisk</td><td></td></tr><tr><td>690</td><td>Redstone</td><td></td></tr><tr><td>8217</td><td>Kaia</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>FUEL_MAIN</td><td>Fuel</td><td></td></tr><tr><td>480</td><td>World Chain</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>ECLIPSE_MAIN</td><td>Eclipse</td><td></td></tr><tr><td>2818</td><td>Morph</td><td></td></tr><tr><td>130</td><td>Unichain</td><td>0x70f6060fc8b01b56869feba8361df468f98c2900</td></tr><tr><td>SUI_MAIN</td><td>Sui</td><td></td></tr><tr><td>5545</td><td>DuckChain</td><td></td></tr><tr><td>543210</td><td>Zero</td><td></td></tr><tr><td>33139</td><td>ApeChain</td><td></td></tr><tr><td>21000000</td><td>Corn</td><td></td></tr><tr><td>98865</td><td>Plume</td><td></td></tr><tr><td>177</td><td>HashKey</td><td></td></tr><tr><td>146</td><td>Sonic</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>50104</td><td>Sophon</td><td></td></tr><tr><td>57073</td><td>Ink</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>80094</td><td>Berachain</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>1868</td><td>Soneium</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>1514</td><td>Story</td><td></td></tr><tr><td>2741</td><td>Abstract</td><td></td></tr><tr><td>MOVEMENT_MAIN</td><td>Movement</td><td></td></tr><tr><td>42220</td><td>Celo</td><td>0xe530d28960d48708ccf3e62aa7b42a80bc427aef</td></tr><tr><td>55244</td><td>Superposition</td><td></td></tr><tr><td>2020</td><td>Ronin</td><td></td></tr></tbody></table>


# Orbiter Router

{% hint style="info" %}
OrbiterRouter can be used to initiate cross-chain transactions with us within your contract. Just call: OrbiterRouter contract address in your entry contract and pass the parameters. The latest version of the contract is currently called: OrbiterRouterV3 contract. This contract is backward compatible.
{% endhint %}

{% hint style="info" %}
OBSource and OrbiterRouterV1 are obsolete, please do not use this contract anymore
{% endhint %}

<figure><img src="/files/sgqSJ4N5ShrxsIWTaC0P" alt=""><figcaption><p>OrbiterRouterV3</p></figcaption></figure>

## Mainnet

{% content-ref url="/pages/k7B6yLJN0JOBBBwpcitO" %}
[Smart Contract](/developer/smart-contract)
{% endcontent-ref %}

## Testnet

|   |   |   |
| - | - | - |
|   |   |   |
|   |   |   |
|   |   |   |

## EVMcontract

### EVM OrbiterRouterV3 ABI

```
[
    {
        "anonymous": false,
        "inputs": [
            {
                "indexed": true,
                "internalType": "address",
                "name": "to",
                "type": "address"
            },
            {
                "indexed": false,
                "internalType": "uint256",
                "name": "amount",
                "type": "uint256"
            }
        ],
        "name": "Transfer",
        "type": "event"
    },
    {
        "inputs": [
            {
                "internalType": "address",
                "name": "to",
                "type": "address"
            },
            {
                "internalType": "bytes",
                "name": "data",
                "type": "bytes"
            }
        ],
        "name": "transfer",
        "outputs": [

        ],
        "stateMutability": "payable",
        "type": "function"
    },
    {
        "inputs": [
            {
                "internalType": "contract IERC20",
                "name": "token",
                "type": "address"
            },
            {
                "internalType": "address",
                "name": "to",
                "type": "address"
            },
            {
                "internalType": "uint256",
                "name": "value",
                "type": "uint256"
            },
            {
                "internalType": "bytes",
                "name": "data",
                "type": "bytes"
            }
        ],
        "name": "transferToken",
        "outputs": [

        ],
        "stateMutability": "payable",
        "type": "function"
    },
    {
        "inputs": [
            {
                "internalType": "contract IERC20",
                "name": "token",
                "type": "address"
            },
            {
                "internalType": "address[]",
                "name": "tos",
                "type": "address[]"
            },
            {
                "internalType": "uint256[]",
                "name": "values",
                "type": "uint256[]"
            }
        ],
        "name": "transferTokens",
        "outputs": [

        ],
        "stateMutability": "payable",
        "type": "function"
    },
    {
        "inputs": [
            {
                "internalType": "address[]",
                "name": "tos",
                "type": "address[]"
            },
            {
                "internalType": "uint256[]",
                "name": "values",
                "type": "uint256[]"
            }
        ],
        "name": "transfers",
        "outputs": [

        ],
        "stateMutability": "payable",
        "type": "function"
    }
]
```

#### Introduction to main methods

* Initiate Orbiter Maker cross-chain transaction
* * transferToken
  * * The ERC20 token of the chain where the contract is located cross-chain
    * parameter
      * token=> ERC20 contract address (if not approved, you need to approve it first)
      * to=>address (pass Orbiter Maker address)
      * value=>uint （quantity）
      * data=> bytes (extended parameters that need to be passed, see below for details)Introduction to Data extended parameters）
  * transfer
    * Cross-chain native main currency of the chain where the contract is located
    * parameter
      * to => address (pass Orbiter Maker address)
      * data=> bytes (extended parameters that need to be passed, see below for details)Introduction to Data extended parameters）

### Introduction to Data extended parameters

**Parameter format**

// Parameter text

> t=0x069A775eF31FaE8311B2EE2024243C9F1eE46E63f98A7DCAF3D077C951f5174b

// The hexadecimal encoding is passed into the contract

<https://string-functions.com/string-hex.aspx> hex code

> 743D30783036394137373565463331466145383331314232454532303234323433433946316545343645363366393841374443414633443037374339353 1663531373462

//  Parameter text

> c=9002\&t=0xEFc6089224068b20197156A91D50132b2A47b908

// The hexadecimal encoding is passed into the contract

> 633d3930303226743d307845466336303839323234303638623230313937313536413931443530313332623241343762393038

**Supported parameter list**

| name                | desc                                                                                                                              | default     | required         |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ----------- | ---------------- |
| c                   | Security code, vc parameter obtained through routers interface, if the amount has a mantissa, it does not need to be passed here. |             | false            |
| <p>t</p><p><br></p> | Target link receiving address (can be passed when ToStarknet and cross-address)                                                   |             | false            |
| <p>app<br></p>      | If you enter the evm wallet address, you will get a commission                                                                    | <p><br></p> | <p><br>false</p> |

\
\ <br>

### Starknet contract

{% hint style="info" %}
Mainnet: 0x058680be0cf3f29c7a33474a218e5fed1ad213051cb2e9eac501a26852d64ca2

Testnet: 0x045cf46534ccc555f5f80816b4f842780ad4cedd82825460310ff2e5e9aa999a
{% endhint %}

### &#x20;Starknet OrbiterRouterV3 ABI

````
```typescript
[
    {
        "name": "Uint256",
        "size": 2,
        "type": "struct",
        "members": [
            {
                "name": "low",
                "type": "felt",
                "offset": 0
            },
            {
                "name": "high",
                "type": "felt",
                "offset": 1
            }
        ]
    },
    {
        "data": [
            {
                "name": "to",
                "type": "felt"
            },
            {
                "name": "amount",
                "type": "Uint256"
            },
            {
                "name": "token",
                "type": "felt"
            },
            {
                "name": "ext_len",
                "type": "felt"
            },
            {
                "name": "ext",
                "type": "felt*"
            }
        ],
        "keys": [],
        "name": "Transfer",
        "type": "event"
    },
    {
        "name": "transferERC20",
        "type": "function",
        "inputs": [
            {
                "name": "_token",
                "type": "felt"
            },
            {
                "name": "_to",
                "type": "felt"
            },
            {
                "name": "_amount",
                "type": "Uint256"
            },
            {
                "name": "_ext_len",
                "type": "felt"
            },
            {
                "name": "_ext",
                "type": "felt*"
            }
        ],
        "outputs": []
    }
]
```
````

### test transaction:

<https://sepolia.starkscan.co/tx/0x4e64431da3a475ea77e87adf2d1709f56a2782389039e93596a497e5ce2df7a>

<br>


# OPool

### **Overview**

Orbiter Finance OPool is an open-token cross-chain transfer solution. Through the OPool solution, project parties can easily add their tokens to OPool contracts on various chains and enable users to securely and freely move tokens across different chains via cross-chain transfer mechanisms.

### **OPool Contract**

* The OPool contract is the core component of the cross-chain transfer solution, responsible for managing token liquidity on different chains.
* The contract provides inbox and outbox / outboxBatch methods for cross-chain transfer in and out / batch transfer operations, respectively.
* Addresses of OPool contracts on each chain

  | Chain        | Contract                                   |
  | ------------ | ------------------------------------------ |
  | Arbitrum One | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | BSC          | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | Ethereum     | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | Optimism     | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | BNB          | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | BomeChain    | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | HashKey      | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | Kroma        | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | Base         | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | Vizing       | -                                          |
  | ApeChain     | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |
  | Blast        | 0x68b5a1c02dea0958388eee5361f021018bd8dbe7 |

### **Project Party Workflow**

1. The project party should transfer its tokens (hereinafter referred to as EToken) to the OPool contracts of each chain to provide liquidity. It is necessary to ensure that a sufficient amount of EToken is transferred to the OPool contracts of each chain to meet the demands of cross-chain transfers.
2. The project party needs to monitor the balance of EToken in the OPool contracts on each chain in real-time. When the balance falls below the set threshold, the project party should take immediate action to transfer EToken to the corresponding chain's OPool contract to ensure the continuity of liquidity.
3. Feature: Orbiter Finance will develop a low balance warning service for OPool in the future to timely remind project parties to replenish balances.

### **Cross-Chain Process**

1. Users need to authorize EToken to the OPool contract through the Approve operation before performing cross-chain transactions.

2. Users invoke the inbox method of the OPool contract on the source chain while simultaneously providing Native tokens (such as ETH in Ethereum/layer2s, BNB in BSC, OKB in x-layer) as payment for cross-chain transaction fees<br>

3. Cross-chain transaction fees will be transferred to the Maker address of the Orbiter Finance protocol, while the user's EToken will be locked in the OPool contract on the source chain, triggering the Inbox event.

   im&#x20;

   <figure><img src="/files/wTy1PyvuvAubQRwdhZyP" alt=""><figcaption></figcaption></figure>

4. Upon receiving the Inbox event from the source chain, the Maker node will invoke the outbox / outboxBatch method of the target chain's OPool contract. The outbox method transfers a specified amount of EToken to the user, consuming the EToken balance in the target chain's OPool contract during this process. (Note: If the EToken balance in the target chain's OPool contract is insufficient, the Orbiter Finance protocol will prohibit users from performing cross-chain operations.\
   s v g

   <figure><img src="/files/mM2b03CwYzgn1mwEqmzf" alt=""><figcaption></figcaption></figure>


# Brand Kit

{% file src="/files/3YlKnEfWvsWyuPgJE0eu" %}
Click to download media resources
{% endfile %}

Logos

<figure><img src="/files/c7tXiWyxRYEwA1YdLsXs" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/geEcSQBmA5AkeBXHE3K4" alt=""><figcaption></figcaption></figure>

### Color Palette <a href="#color-palette" id="color-palette"></a>

<figure><img src="/files/frPBRJTOrhDsrWLwGV3x" alt=""><figcaption></figcaption></figure>