# Bridge-Dex Module

**Bridge-Dex** is our unified aggregation engine that ensures smooth asset transfer and exchange across the blockchain using third-party bridge and DEX APIs.

#### :brain: Why It Matters

The future of Web3 is **chain-abstracted UX** — users shouldn’t have to think about what network their assets are on.\
\
**Bridge-DEX** turns this vision into reality by:

* Aggregating multiple bridges and DEXes under a single interface
* Automatically calculating the **most optimal path** for cross-chain actions
* Supporting complex multi-steps flows **(**[**ZAPs**](#what-are-zaps)**)**:\
  `Swap → Bridge → Stake`, executed as a **single bundled transaction plan**

***

#### :bulb:**What are Zaps ?**

Zaps (also known as bundled executions) combine multiple DeFi actions into a single operation. In Bridge-DEX, these Zaps are optimized for gas usage and executed via direct smart contract calls for reliable delivery.

***

#### :jigsaw: Modular & Scalable Design

Under the hood, Bridge-DEX is built on a standardized service model, which includes bridge and dex provider interfaces that follow a common format.

According to this:

* Adding a new bridge or DEX doesn’t require changes in aggregator logic.
* Each provider implements a standardized interface (fetching quotes, estimating fees, building transactions).
* The aggregator dynamically detects available services and evaluates the best route based on configuration and live data.
* You only need to provide a config object (e.g. API endpoints, service type, feature flags and etc) — the integration process takes hours, not days.

This design makes the system highly maintainable and future-proof, allowing us to adopt new standards like:

* Chain Abstraction (CA)
* Interop APIs
* Native Account Abstraction bridges

***

### :mag\_right: Route Selection Logic

To determine the most optimal route between multiple third-party providers (bridges, DEXes), \
our `Bridge-DEX` module includes a priority-based route selection algorithm. This ensures that the user always gets the most favorable outcome based on different criteria like **fees**, **return**, or **gas costs**.

#### :gear: How It Works

1. **Iterates** through all available routes.
2. **Calculates** total fees in USD for each route.
3. **Compares** routes based on selected priority (`bestFee`, `bestReturn`, etc.).
4. **Marks** the best route for each priority with a boolean flag.
5. **Sorts** the list by selected priority to return an ordered array.
6. **Returns**:
   * `best`: Service ID with the best result
   * `priority`: The selected priority
   * `routes`: All enriched and sorted routes
   * `routeId`: Cached route identifier

***

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

***

#### :gear: Highlights

| Feature                       | Description                                          |
| ----------------------------- | ---------------------------------------------------- |
| Modular Provider Architecture | Easy to add new Bridges/DEXes via config             |
| Chain-Agnostic Routing        | No dependency on specific networks                   |
| Real-Time Quote API           | Supports full transparency & caching                 |
| Cross-Chain Operations        | Seamless support for chained actions (swap + bridge) |
| Extensible Standards Support  | Built for Chain Abstraction and Interop futures      |

***

#### :scroll: Deployment & Audits

All deployed contract addresses are listed in the [**Deployment Addresses**](/ethring/core/deployment-addresses.md) section.\
Each third-party integration includes a link to its **audit**, ensuring transparency and security.

***

#### List of added services:

<table><thead><tr><th width="234.14453125">Service Name</th><th width="375.90625">Integration Type</th><th data-type="checkbox">Active</th></tr></thead><tbody><tr><td>LiFi</td><td><strong>Bridge, Dex</strong></td><td>true</td></tr><tr><td>Enso</td><td><strong>Dex</strong></td><td>true</td></tr><tr><td>ODOS</td><td><strong>Dex</strong></td><td>false</td></tr><tr><td>Zero-x</td><td><strong>Dex</strong></td><td>false</td></tr><tr><td>Across</td><td><strong>Bridge, Dex</strong></td><td>false</td></tr><tr><td>DeBridge</td><td><strong>Bridge, Dex</strong></td><td>false</td></tr><tr><td>Paraswap</td><td>Dex</td><td>false</td></tr><tr><td>Synapse</td><td><strong>Bridge, Dex</strong></td><td>false</td></tr></tbody></table>

***

#### The list of the main routes that we use

<table><thead><tr><th width="154.33984375"></th><th></th></tr></thead><tbody><tr><td><pre><code>getAllowance
</code></pre></td><td>Get allowance from service</td></tr><tr><td><pre><code>getApproveTx
</code></pre></td><td>Get approve Tx from service</td></tr><tr><td><pre><code>getQuote
</code></pre></td><td>Get Quote from service</td></tr><tr><td><pre><code>getTx
</code></pre></td><td>Get Tx from service</td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ethring.gitbook.io/ethring/core/bridge-dex-module.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.