# Introduction The world of blockchain is actively evolving, with new projects and technologies constantly bringing innovation to the industry. The immense demand and popularity of cryptocurrencies became a challenge to the industry leaders such as Bitcoin and Ethereum, which were not developed with the expectation of such rapid scalability. The inability to scale quickly resulted in high gas prices, a problem that was addressed by developing sidechains and L2 projects. Unfortunately, this solution has created a new issue: fragmented liquidity. Bridges, a solution often proposed to tackle this problem, have introduced their own set of issues by making wrapped tokens to represent an original asset on a different blockchain. However, this approach creates an attack vector for all involved networks. If an attack is targeted at a specific network or TVL (total value locked on a particular platform), these wrapped tokens can quickly become worthless. If a hacker issues new wrapped tokens instead of stealing locked ones, the situation will still be catastrophic: users' wrapped tokens will still lose their value, and the negative experience will undermine trust in the entire system. Even if a pure zero-knowledge (ZK) bridge were to be built (one that eliminates the need for trusted validators), it would still face significant challenges. One such challenge includes creating and managing wrapped assets that must be stored in pools. These pools, and indeed networks themselves, are susceptible to attacks, including the infamous 51% attack that threatens the integrity of an entire network. Vitalik Buterin has written extensively on the problems of interoperability and scalability in blockchain networks. He specifically warned about security issues with tokens wrapped by bridges and insisted that only native tokens should exist on their respective chains: [\[AMA\] We are the EF's Research Team (Pt. 7: 07 January 2022)](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/). The Swaps.io contributors align with this viewpoint and proposes a system that refrains from intermingling assets between networks or issuing new wrapped tokens. Another crucial aspect that highly affects cross-chain transactions is the Automated Market Makers (AMM) pools in DeFi trading. These pools provide an advantage by allowing users to automatically swap assets without waiting for other network participants. However, this approach comes with multiple critical problems, including price slippage and the potential for MEV (Miner Extractable Value) attacks. The latter occurs when miners collude with hackers to rob users. Another concern is the impermanent losses (IL) and the probable manipulations with prices of low-liquid pairs. Both are possible since AMMs rely on a closed ecosystem and operate according to the pool's formula. The Swaps.io contributors believe this approach is unsuitable for creating a robust and efficient cross-chain solution. It is especially true if you use a combination of a DEX and a bridge or a more complex route (for example, a combination of a DEX, a bridge, and another DEX). In that case, there is a chance that a transaction will not go through due to slippage or high gas fees and get stuck in the intermediate network, which will cause additional costs for withdrawing funds and restarting the transaction again, but at a different price. In conclusion, the Swaps.io contributors believe that omnichain systems are inefficient and insecure since all complex systems present a risk of attacks and increase both execution time and transaction costs. Instead, the Swaps.io contributors introduce an on-chain trading approach to move liquidity cross-chain, allowing native assets to be traded without leaving their respective ecosystems. With this approach, participants can conduct secure transactions directly with each other without creating wrapped assets or storing their original assets locked in a smart contract, thus saving time and money. Trading native coins within their respective network provides a secure future for those networks and all their participants. Moreover, the Swaps.io system does not require users to place trust in validators by employing decentralized proofs that anyone can provide using zero-knowledge technology (ZK will be discussed in more detail in the further description of the protocol). The proposed peer-to-peer approach and the open-source trading smart contract allow Intent Agents to seamlessly create a fair market with customized trading strategies while keeping their developments private on the backend. Intent Agents can also develop next-generation bots using machine learning and thoroughly analyze database sources using artificial intelligence. Thus, Swaps.io Protocol enables Intent Agents to create a new generation of trading bots that further explore the boundaries of DeFi, acquire new technologies by analyzing trading strategies, and connect with the liquidity of centralized and traditional markets. Deep learning of big data can prevent potential attacks and track threats on a higher level, creating a truly decentralized market. # Why Swaps.io? Swaps.io Network presents an innovative approach to solving several existing problems in the field of blockchain. The first task that the team of the Swaps.io contributors solved (unlike many existing systems) was to store assets within the network, eliminating the need to create wrapped tokens. This approach maintains the integrity of the original assets and reduces the vulnerability associated with wrapped tokens. Swaps.io contributors' decision to stop issuing wrapped tokens aligns with our belief that the future belongs to cross-chain technologies without fragmented liquidity. By creating a peer-to-peer platform for trading native assets, we strive to simplify the swap process and make it scalable for any network, eliminating the need to build complex systems with a bunch of code, dependencies, and support for what is unrelated. Our approach is to make swaps secure at the network level itself. Since the tokens do not leave the network, liquidity is stored in Intent Agents' wallets and moves between them and the users. Therefore, Swaps.io Protocol completely prevents TVL attacks. One of the key features of Swaps.io Protocol is the ability to transfer assets instantly. All transactions occur on-chain, contributing to an efficient and seamless user experience. Swaps.io's approach to instant transfers is truly revolutionary, as it removes the need to wait for cross-chain validation. Intent Agents in the Swaps.io system manage the risks of reorganization independently. Furthermore, the notion of instant finality between Layer-2 solutions adds an extra layer of efficiency and security to the system. Intent Agents offer competitive rates, creating a marketplace where they compete for the users' transactions. This competition ensures that the users always get the best rates available. Additionally, Swaps.io Protocol allows Intent Agents to link DeFi with the liquidity from centralized finance (CeFi), increasing the number of available liquidity sources. Swaps.io Protocol employs an optimistic system that optimizes gas usage and costs. Instead of requiring users to pay validators for every transaction, Swaps.io allows users to pay only for the asset transfer itself, eliminating extra costs and creating a more efficient transaction process. However, liquidators and Intent Agents have to pay for generating proofs. Liquidators must send proofs when they want to take an Intent Agent's collateral after liquidation, and Intent Agents must send proofs when they want to withdraw their collaterals. Instead of AMMs that have several issues, Swaps.io Protocol offers a system that allows each market maker to use private developments for their trading strategies and create new-generation smart bots with automatic machine-learning engines to analyze the external environment and all possible risks, generating bot competition between professional market participants. Swaps.io Protocol also allows market makers to use their own liquidity and connect fragmented liquidity between DeFi and CeFi, expanding their capabilities beyond managing a single pool. Such a system will enable market makers to combine their trading potential with machine learning. Current trends show that generative Artificial Intelligence (AI) improves efficiency and provides a much faster response to changes in the market environment. AI uses deep learning algorithms to learn from large data sets in automated processes and decision-making, improving overall customer service and preventing attacks. ### Security of Swaps.io Protocol Swaps.io Protocol was created to protect the users as much as possible with the help of professional market makers (called Intent Agents) that manage all risks connected to trading and blockchain reorganization. Although anyone who provides collateral to ensure security can participate in Swaps.io Protocol, they should take into consideration the said risks and build their trading strategies accordingly. To enhance the security of each transaction, Swaps.io Protocol implements a collateral system, which is the backbone for safe interactions between users and Intent Agents. Each transaction is backed by an Intent Agent's collateral, eliminating the need to trust Intent Agents and ensuring the safety of the users' assets. As swap transactions occur almost instantly, unused collateral can be used for subsequent transactions. This efficient use of collateral further optimizes the system's operation. The main difference of Swaps.io Protocol is completely decentralized ZK-based liquidation that ensures a lack of a single point of control. Swaps.io is designed so that any participant can initiate liquidation of an unfilled order, provide a proof that they have completed it, and take an Intent Agent's collateral. Such a liquidation process creates competition between liquidators, motivating them to act as quickly as possible, further enhancing the stability and security of the system. The liquidation system is completely open and public, which means anybody can liquidate an expired order and claim the collateral assigned to that transaction, which often far exceeds the value of the order. This approach encourages quick filling of orders and adds an extra layer of security to the system. For example, a user wants to swap 1 ETH on the Ethereum network for 1800 xDAI tokens on the Gnosis network, and an Intent Agent allocates 2000 USDT tokens as collateral. If the Intent Agent does not complete the transaction in time, the liquidator will be able to take 2000 USDT at the price of 1800 xDAI while giving the user the xDAI tokens they wanted. Thus, the liquidator is motivated to finish the transaction by the ability to buy a USDT token at a discounted price, which can be used later for arbitrage trading. # About Swaps.io At the beginning of 2023, the team of crypto experts previously known as Kinetex Network launched the first version of the protocol, a meta-aggregator that contained an aggregation of bridges and DEXes, connecting the fragmented liquidity between networks. In order to automate processes and avoid the hassle of storing gas on each intermediate network, a decision was made to create a network of relayers that function as keepers. These relayers would sequentially launch smart contracts in each network, thus ensuring that the entire process is automated from the user's end. The team also developed secure smart contracts that eliminated the need for users to trust or transfer funds under the project's management, ensuring a seamless and decentralized approach to swapping. After some time, statistics showed that user transactions often got stuck between networks due to sudden gas surges or delays on the bridge validators' side, which caused the price slippage to reach maximum values and the swap to freeze, unable to be completed automatically. In such cases, users had to pay gas in intermediate networks, withdraw transactions, and restart them. The team quickly realized the flaws of such a solution and decided to move on. In the summer of 2023, the team, represented by founders Mike Shishko and Tigran Bolshoi, introduced a new approach to cross-chain swaps at the ETHGlobal hackathon in Lisbon, where they modified ZK Light clients from SuccinctLabs. This approach eliminated the need to wait for a response from third-party validators and pay gas and fees on both networks for each transaction. At the same time, the security of cross-chain interactions was ensured on each network's level. Later that summer, at the ETHGlobal hackathon in Paris, the team proposed a new standard based on intents and named it Flash Trade. The main difference between Flash Trade and complex omni-chain solutions is the separation of tasks and their delegation. It leads to ease of execution as there is no need to connect blockchains not initially designed for this. The team believes it is necessary to separate blockchains' operation, developers' requests to write apps on top of the blockchains, and user intents to perform certain actions as independent processes. The team also presented an updated look at moving liquidity between networks using light clients — without wasting time waiting for validators' responses and the mandatory need to pay for proof of each transaction. Instead, Intent Agents provide collateral in advance to a special smart contract that does not participate in the swap process but is only responsible for the maximum possible order size that each Intent Agent can fill. Suppose an Intent Agent has 1 million in the collateral contract. It means that it cannot start filling one or several orders exceeding 1 million. To be able to reuse collateral, the Intent Agent needs to update its state after ensuring that all transactions have been successfully completed and there are no debts left. Intent Agents can update the state of their collaterals at any time; the main advantage is that there is no need to do so every transaction. For example, if an Intent Agent has 1 million in collateral and has made 1000 transactions, they can update the state of all transactions at once. We call this feature "*batch validation*". Thus, the team came up with a model of decentralized P2P trading, where two on-chain transactions are created between a user and an Intent Agent, where the Intent Agent technically has the ability to process the transaction instantly in the first block. Moreover, the Intent Agent fully pays all gas costs and takes on all transaction management and risks for the further sale of the user's asset. On the part of the user, all that is required is to sign with consent to the execution of the intent. As a result, we get the most significant optimization of gas costs, minimizing it to 60-80k gas units, which is a very high gas optimization compared to all current solutions on the market. We also avoid the need to use pools with trading pairs that allow MEV attacks and wrapped or virtual tokens, which bridges create in abundance. Working with user intents is crucial in the existing market, given the current UX and UI problems, which makes it difficult to talk about quick mass adoption. Currently, users need to connect Web3 wallets constantly, own different wallets for different networks, switch to various networks, store gas on each network for any operations, and understand the procedure and consequences of such phenomena as price slippage, price impact, etc. Most users are intimidated by the complexity of the process, especially knowing that hackers often exploit user errors to launch attacks, taking advantage of users' limited understanding of the complex workings of backend systems. As a result, the importance of simplicity cannot be overstated. The idea of Flash Trade was to delegate tasks to professional players, creating a marketplace of user intents. Let's imagine there is a certain level in the form of a decentralized network where users can send their order requests for free to the marketplace of professional players (Intent Agents), who will compete to fulfill them. The decentralized level serves as a filter between user requests and Intent Agents, filtering against spam, malicious intents, or failures from Intent Agents. Thus, we get a pool of intents in the form of an auction, where users place their request for order execution. All Intent Agents are notified of each request and then compete for each request separately. The network appoints a winner for each order and provides the answers back to the users. If the best proposal matches the user's request, the user can sign the intent, permitting the Intent Agent to execute it. In turn, the Intent Agent commits to complete the order by blocking part of the collateral. The team plans to develop the intent-based approach further so that users can send any requests to the auction, including swaps, purchase or sale of NFT collections, direct replenishment to the pool, rebalancing or liquidating orders, etc. The question of forming queries and a standard for intents remains open; at the moment, the team is looking for a suitable solution for standardizing intent queries.\ \ At the end of December 2023, the team uploaded a ZK light client for native Bitcoin called [BTCX](https://alpha.succinct.xyz/@MikeKinetex/btcx) to the SuccinctX platform. The integratino of ZK Light client into the Flash Trade protocol opened access to Bitcoin in DeFi, enabling direct swaps of BTC for ETH and other crypto assets. The main difference is that such a solution does not require pools storing BTC since any participant can deposit collateral and start processing orders as an Intent Agent or send a request for a swap to Intent Agents. The latter are able to connect liquidity between CeFi and DeFi, allowing them to execute routes in one transaction between networks. This way, there is also no need to combine a bridge and a DEX, for example, swapping the native BTC for a stablecoin or any other token in one transaction. The impact of these developments was transformative. The project's scope, ambitions, and community expanded so significantly that it became evident that the original name did not accurately reflect the mission and goals that the community and contributors are striving to achieve. Consequently, the name "Swaps.io" was proposed and enthusiastically embraced. The rebranding marks a new chapter for a vibrant, forward-thinking community united by the mission to innovate and redefine the DeFi space and how humans use crypto. # Swaps.io Protocol In Swaps.io Protocol, users simply select their desired token and enter the amount they wish to swap. Intent Agents then manage the rest of the process. Once a user agrees to the rate, they sign the order, giving an Intent Agent permission to access their assets. The Intent Agent reserves a collateral amount exceeding the user's assets in value, ensuring the safety of the user's funds even if the Intent Agent refuses to execute the order after the user has already transferred the funds. In Swaps.io Protocol, Intent Agents handle all aspects of the transaction, including paying gas fees. This approach creates a gasless flow and relieves users from storing multiple native coins in their wallets. Liquidators play a critical role in monitoring transactions. A liquidation process is initiated when the transaction is not completed within the agreed timeframe. The first step is for liquidators to execute the user's order, after which, by making a request to the on-chain light client and providing proof of execution, they can take the collateral. The current state of the light client is maintained by a distributed network of nodes that constantly provide updates via generated Zk proofs, ensuring the security and transparency of the platform. Users can be sure that their orders will be executed and that they will receive assets according to the signed orders. This approach removes risks from the users and transfers the entire management process and responsibility to Intent Agents while guaranteeing that users will always receive the desired assets. Overcollateralizing each transaction demotivates Intent Agents to avoid responsibility and encourages liquidators to execute liquidations as quickly as possible. Moreover, the architecture of Swaps.io Protocol based on ZK proofs guarantees a decentralized approach where any participant can make liquidations, thus increasing the system's reliability, the integrity of the execution of each transaction, and the security of the entire system. # Roles The main participants in Swaps.io Protocol are the following four categories: **Users**, **Intent Agents**, **Liquidators**, and **Liquidity Providers**. **Users** can make cross-chain swaps just by providing approval for their assets. There are no gas fees for the transactions and no hidden fees from protocol. Users of Swaps.io Protocol receive the best possible rates from Intent Agents, while Intent Agents compete to provide the best swap rate and duration. **Intent Agents** are the key players in Swaps.io Protocol. Intent Agents are supposed to be professional market players. They set the rates, hold the liquidity for executing orders, and provide collateral to ensure the security and timely execution of the orders. Intent Agents must analyze the market, build their trading strategies, hold liquidity between networks, be able to rebalance liquidity, manage their collateral, prevent attacks, and have their own risk management strategy. Each Intent Agent is responsible for its own liquidity and should set rates only after a thorough risk analysis. **Liquidators** ensure that the whole system works fairly for Users and that all transactions are completed on time. If an Intent Agent takes a user's funds but fails to execute an order, their collateral will be liquidated. If a Liquidator finds a transaction that the Intent Agent did not complete on time, they can finish it for a reward. The Liquidator needs to transfer the desired assets to the User and provide a proof of a transaction to be able to unlock the Intent Agent's collateral. The liquidation process is described on the [Liquidation](/swaps.io-protocol/liquidation) page. **Liquidity Providers** can provide liquidity to Liquidity Pool, which offers multi-chain over-collateralized loans and can be used by Intent Agents as additional liquidity to execute the orders. Once the asset is borrowed, an Intent Agent must pay a fee to Liquidity Providers, constantly generating income for them. Due to the multi-chain nature of Liquidity Pool, supported assets are strictly limited and primarily include stablecoins. # Workflow

Swaps.io Protocol overview

1. To be eligible to execute orders, **Intent Agents** need to provide any authorized stablecoin (USDT, USDC, DAI) to a `CollateralManager` contract. 2. **Collateral** can be deposited in an ERC-20 token of authorized stablecoins (USDT, USDC, DAI, etc.) This token can be slashed by **Liquidators** in case the order execution fails. 3. **Intent Agents** can borrow additional liquidity from the **Liquidity Pool** by pledging their collateral. This pool provides multi-chain over-collateralized loans for supported assets (primarily stablecoins). # Swap Process The swap process is initiated by a user. They enter the parameters of a swap (such as tokens, networks, amounts, etc.) and send them to the decentralized query service. This service queries registered Intent Agents for suitable swap orders they can provide. Each Intent Agent can provide its own rates and set faster execution times, securing orders by higher collateral amounts. Each Intent Agent also has a score calculated in a decentralized way, according to order execution success rate, total trading volume, etc. This score, along with the parameters mentioned above, is an important criterion for choosing the most suitable order. Once the best suitable order is chosen, it is important to ensure that the Intent Agent has sufficient unlocked collateral to fulfill it. To achieve this, the `collateralUnlocked` field in the `Order` structure should contain an `unlockCounter` value from the `CollateralManager`. It will enable the `OrderReceiver` contract to verify that the collateral can cover the order. After that, the user signs the order with the private key associated with the address they hold the assets to swap on. The required signature is of EIP-712 standard for the `Order` typed data structure. Next, the signature is passed to the Intent Agent to execute the order via the contracts. In general, the first stage of successful order execution looks like the following: 1. A **User** sets order parameters and sends them to the query service. 2. This service queries the registered **Intent Agents** and pick the best order according to the rate, execution time, and score. 3. If the **User** agrees to this order, they check the collateral state of the **Intent Agent**. 4. If the **Intent Agent** has enough collateral, the **User** can sign the order. 5. The **User** approves the transfer of the order asset to the **Intent Agent**. 6. The **Intent Agent** receives an order from the **User** in the initial network. 7. The order is received by the `OrderReceiver` smart contract that immediately transfers the User asset to the **Intent Agent**. If receive is not performed by the **Intent Agent** (within the deadline specified in the order), the swap is considered canceled. Continuous cancellations can affect the **Intent Agent's** score and limit its ability to execute orders. Once the **Intent Agent** calls the `OrderReceiver` contract, it computes the locked collateral for the order. The locked collateral is the sum of the order amount and the liquidation bounty. The liquidation bounty is an amount set aside to incentivize **Liquidators** to step in and complete the order if the **Intent Agent** fails to do so. The size of the collateral is always higher than one and is calculated depending on the assets and the execution time. If the unlocked collateral (the **Intent Agent's** balance not currently involved in securing transactions) is smaller than the required collateral (collateral to be locked), a transaction revert will occur, and the **Intent Agent** will fail to confirm the order. If the unlocked collateral is bigger than the required collateral amount, the `OrderReceiver` updates the state and emits an `AssetReceive` event, signaling that the order assets have been received successfully. This event may be used as part of the proof of order execution, checked by Swaps.io Light Clients, to unlock the collateral. After successfully receiving the order asset in the initial blockchain, the **Intent Agent** fills the order in the destination blockchain: 1. The **Intent Agent** calls the `OrderSender` contract with the order structure and transfers funds to the contract. 2. The order is checked by the `OrderSender` contract, and then the **Intent Agent’s** assets are transferred to the **User**. 3. After transferring the assets to the **User**, the `OrderSender` emits an `AssetSend` event, signaling that the order assets have been sent successfully. This event may be used as proof to unlock the collateral. # Collateral # Deposit collateral The collateral serves as insurance for orders. By requiring Intent Agents to deposit collateral, the system ensures there is an additional layer of security protecting users' funds. If the Intent Agent fails to process a transaction correctly, liquidators will still execute the order due to the presence of collateral.

Collateral deposit overview

1. Before Intent Agents can begin processing transactions, they are required to deposit authorized ERC-20 stable tokens into the `CollateralManager` smart contract. It is deposited for a specific 'receive' chain. 2. Once the `CollateralManager` receives the Intent Agent's collateral deposit, it updates its records. The `CollateralManager` maintains records of the total collateral amount it is holding and the amount of collateral not currently in use (known as the "unlocked" collateral amount). 3. With each new deposit from the Intent Agent, the `CollateralManager` updates its records, increasing the total collateral amount by the new deposit's amount. Both chains (collateral chain and receive chain) keep track of collateral usage: * *`locked` counter in the receive chain*: increased by collateral amount specified in the executed order. Order must not be executed if the locked amount exceeds the unlocked amount submitted in the order by the user and confirmed by their signature; * *`unlocked` counter in the collateral chain*: increased each time successful order execution is confirmed by Intent Agents by providing corresponding proofs. # Unlock collateral

Collateral unlock process

This sequence of actions illustrates how the Swaps.io system confirms the successful processing of orders. It involves verifying the successful transfer of the order asset, adjusting the collateral status, and confirming the successful processing of the order. 1. **Verify that the transfer took place**: 1. The Intent Agent provides two proofs (`receiveProof` and `sendProof`) by calling the `confirmOrderAssetSend` method of the `OrderResolver` contract. 2. `OrderResolver` verifies both `AssetReceive` and `AssetSend` events with the help of `LightClient`, which signals that the order has been completed. 3. If any of the events is not verified, `OrderResolver` reverts the transaction. 2. **Unlock collateral**: 1. If both events are verified, `CollateralManager` adds the order collateral amount to the unlocked collateral (`unlockCounter`). The unlocked collateral is the amount of collateral that is not currently in use. 2. `CollateralManager` sets the nonce bit of the order to 1, effectively invalidating the nonce. A nonce is a number used once, and in this context, it is used to ensure each transaction is processed only once. 3. `CollateralManager` emits an `OrderSendConfirm` event, signaling that the order asset has been sent and the process has been confirmed successfully. Consequently, collateral for this order gets unlocked and can be reused for further orders. # Withdraw collateral

Collateral withdraw overview

This sequence of actions demonstrates how the Swaps.io system handles the withdrawal of collateral. It includes the preparation for the withdrawal, the withdrawal itself, and the verification of the withdrawal.

Collateral withdraw process

1. **Preparation**: 1. `CollalteralManager` emits a `WithdrawReport` event, signaling that it is prepared for the withdrawal of collateral. 2. The Intent Agent sends an unlocking transaction by calling the `reportWithdraw` method of the `CollalteralManager` contract in the receive chain to prepare a withdrawal. 3. `CollalteralManager` increases the amount of locked collateral by the order amount. Locked collateral is the amount of collateral that is currently locked and cannot be used for other orders. 2. **Withdrawal**: 1. The Intent Agent instructs the `CollateralManager` to withdraw collateral, calling method `withdraw` and providing `reportProof`. 2. `CollateralManager` checks to make sure the amount being withdrawn does not exceed the amount of locked collateral. If it does, the withdrawal is rejected. 3. `CollateralManager`, with the help of Light Clients, verifies the proof of the `Withdraw` event provided with `reportProof`. If the proof is falsified, the withdrawal is rejected. 4. `CollateralManager` decreases the total amount of collateral to reflect the withdrawal and updates its own state to reflect the new total amount. 5. `CollateralManager` emits a `Withdraw` event, signaling that the withdrawal of collateral has occurred. # Liquidation Swaps.io protocol has mechanisms to handle orders that have not been fulfilled within a certain time limit. If an order reaches its timeout and expires uncompleted, a Liquidator can step in to fill this order and refund a User.

Liquidation overview

In this flow, a Liquidator fills the expired order by sending their own assets to a User instead of an Intent Agent. Order liquidation is performed by calling the `sendOrderLiqAsset` method of the `OrderSender` contract. This method sends the Liquidator's `to` asset in the amount specified in the order to the `from` actor address specified there as well. Anyone can be the liquidation caller of this method. When succeeded, the `AssetLiqSend` event is emitted, which should then be proved by `liqSendProof`. The method becomes available once the send deadline is exceeded and until the liquidation send deadline is reached. Slashing collateral is possible when two proofs are provided to `slashOrderLiqCollateral` method of `OrderResolver`: * order asset received on "from" chain (`receiveProof`) * order asset sent on "to" chain by liquidator (`liqSendProof`) Providing valid proofs allows collateral to be slashed in favor of the Liquidator; thus, Liquidators can profit from filling the expired orders. When neither the Intent Agent nor Liquidator sends assets, a slash by the User is activated. In this flow, the User gets the Intent Agent's collateral instead of the "to" asset. To do that, `no-send` event must be reported on the "to" chain (by the User or an arbitrary Liquidator) by calling the corresponding method `slashOrderCollateral`. It allows collateral slash in favor of the User when two proofs are provided to the method `slashOrderCollateral` of the `OrderResolver` contract: * order assets received on the "from" chain (`receiveProof`); * order assets not sent on the "to" chain (`noSendProof`). Note that the Liquidator in this flow may call both report and slash methods. The main share of the order collateral still goes to the User in this case. At the same time, the Liquidator gets rewarded for performing two transactions with a smaller collateral share as specified in the order. ## Liquidation with Flash Loans

Liquidation with a flash loan overview

If the collateral and the `OrderSender` contract are located on the same network, a failed order could be liquidated in a single transaction using a flash loan. A flash loan is a feature in DeFi that allows the Liquidator to borrow assets without any collateral as long as the borrowed assets are returned within the same transaction. Flash loans enable Liquidators to complete the liquidation process more efficiently without the need for additional transactions or collateral. # Proving Mechanism Leveraging Light Clients for validation alongside a collateral-based architecture allows Intent Agents to utilize their capital efficiently for executing swap operations. In an effort to minimize gas costs, Swaps.io Protocol implements a delayed batch validation mechanism. As a result, the process of swapping funds consists of two (`send` and `receive`) extremely cost-effective p2p transactions (slightly more expensive than a regular token transfer due to order structure verification and custom smart-contract events). The Intent Agent can execute such operations to the extent that their collateral allows. Collateral is "locked" for each operation (means that the counter of the swapped volume in the `receive` network increases, ensuring it does not exceed the volume of the Intent Agent's collateral). When no more collateral is available, the Intent Agent needs to “unlock” it. Thus, the sequence of actions looks like this: 1. Collateral deposit, initializing `unlockedCollateral` counter in a `proof` network; 2. Setting `unlockedCollateral` in the order structure; 3. Placing an order that increases the `lockedCollateral` counter in a `receive` network; 4. Filling order in a `send` network; 5. Repeat while `lockedCollateral < unlockedCollateral`; 6. Batch proving with multiple proofs of `receive` and `send` transactions, which increases the value of `unlockedCollateral` counter; 7. Repeat the cycle the required number of times (starting from p.2). Transaction confirmation is the process of calling the `confirmOrderAssetSend` method in the `OrderResolver` contract with the transfer of two types of proofs: `receiveProof` and `sendProof`. Proof verifies that a certain EVM event with specific data has indeed occurred on some chain. The proof events used for all swap scenarios are produced on chains where assets are received and sent and consumed by the collateral manager. Proofs are transferred to the corresponding `ProofVerifier` contract, which must check the validity of the proof and confirm the event that occurred (sending or receiving funds). The `OrderResolver` contract serves to manage Intent Agents' collaterals for swap insurance. This contract supports both the deposit and withdrawal of the authorized collateral assets (ERC-20 stable tokens) by Intent Agents and methods for resolving order states, either as successfully completed or slashed in favor of a liquidator or user. The resolving is based on corresponding proof verification by the constructor-initialized proof verifier contract (`IProofVerifier`). Currently, three types of proofers are supported: **local state**, **event-bridge** (Hashi-based), and **light clients**. ## Local State Proof verifier `LocalStateProofVerifier` serves to prove events that occurred on the same chain where this proof verifier is deployed. It is capable of proving any event by using view methods of the constructor-initialized address of the state source contract (i.e. `KinetexFlash`) on the same chain. ## Event-bridge (Hashi-based) The `EventBridgeProofVerifier` contract serves for proving events that occurred on a chain different from the one on which this proof verifier is deployed. This is achieved by delivering event information from one chain to another using cross-chain transport protocols aggregated by Hashi. The verifier is initialized with the Hashi contract address, which aggregates received event information from multiple pre-configured cross-chain messaging systems with a certain threshold to enhance proving security and robustness. ## Light Client verifier The most efficient gas-wise, this verifier verifies events in the send/receive network through a light client contract located in the proving network. Verification through light clients, unlike the classic cross-chain flow, does not involve calling transactions in send/receive networks. The use of ZK technology, in combination with checkpoint-based updating of light clients using Merkle trees or MMR for blockchain data storage, enables validating completed swap operations as efficiently and securely as possible. ## Proof Routing The Swaps.io architecture allows it to redirect different types of proofs to different proof verifiers using the `ProofVerifierRouterFossil` contract, which aggregates multiple proof verifier variants. Proof verifiers' routes are configured in the constructor in an immutable manner. When requested to verify proof as an `IProofVerifier` implementor, the router gets a configured proof verifier for the requested proof chain and proof variant passed in `ProofHeader`. Then the router either rejects the proof if no route is configured or proceeds by calling the corresponding proofer and passing the whole proof. # Swaps.io Light Clients Swaps.io Light Clients are the core component responsible for validating operations in the Swaps.io ecosystem, providing states of various blockchains on-chain. Implemented as smart contracts, these light clients store blockchain historical data, like a linked sequence of block header hashes. Light clients have a primary function to provide the functionality for validation of transactions, storage states, and events on the respective blockchains. ## ZK Light Clients Light Clients can be implemented using Zero-Knowledge (ZK) technology. In this approach, the logic for validating block headers is executed off-chain within ZK circuits. This approach significantly reduces gas consumption by handling complex consensus rule checks and validator signature verifications off-chain. Consequently, only a single Zero-Knowledge Proof (ZKP) is generated, offering a cost-effective and efficient on-chain verification process. ### Ethereum & Gnosis Swaps.io Network has ZK light clients for Ethereum and Gnosis networks that are based on top of Succinct Labs light clients. These light clients have been adapted for the requirements of Swaps.io Protocol, ensuring faster block header validation with the ability to access the most recent blocks in a blockchain. ### Bitcoin Swaps.io Network also has the ZK light client for Bitcoin (BTCX), which has helped to connect the liquidity of the native Bitcoin to all the supported EVM-like networks. This light client is based on top of the BTC-Warp solution and uses Plonky2 proof reduction to Groth16 to achieve much more efficient on-chain verification in terms of gas. ## Hashi — EVM Hash Oracle Aggregator Alternatively, light clients can be implemented using Hashi, an EVM hash oracle aggregator. Hashi aggregates data from different oracle sources, providing a decentralized answer to queries, such as the hash of the last blocks on a specified blockchain. This method is particularly useful for networks without the ability to use ZK, such as Layer-2 networks. Hashi ensures decentralization by requiring agreement from multiple oracles. If a consensus, for example, of 2/3 or 3/5 oracles, returns the same block hash, it is considered a reliable update for a light client. The ability to receive truly decentralized answers from a set of different oracles can provide a high level of security comparable to ZK-based light clients. ## Aggregation of Light Clients Swaps.io Network has plans to develop its own light clients for networks such as Solana, Tron, Aptos, and others. It is an important and rather lengthy part of the development roadmap, which will allow Swaps.io to maximize networks' coverage in the future, ensuring the best interoperability between them and allowing users to use Swaps.io dApp in the most secure and highly gas-efficient manner. But besides this, Swaps.io Network also involves the aggregation of various ready-made ZK light client solutions, such as: \- zkBridge by Polyhedra ( ); \- Brevis ( ); \- TendermintX ( ); \- DendrETH ( ). Combining different solutions will allow Swaps.io Protocol to validate transactions more efficiently and securely. ## Checkpoint-Based Storage Optimization To enhance the efficiency of smart contract storage, Swaps.io Light Clients utilize a checkpoint-based approach. In this implementation, updates are organized as batches of block headers, interconnected and presented in the form of a Merkle Tree. This method allows for the storage of only three essential hashes: first header, last header, and Merkle root, while retaining the capability to validate any transaction within the specified range of blocks. This is achieved by providing a Merkle proof for the corresponding block. ### Merkle Mountain Range (MMR) A more advanced storage optimization technique involves the utilization of Merkle Mountain Ranges (MMRs) as an alternative to traditional Merkle trees. MMRs offer a highly efficient means of accessing historical blockchain data. The append-only nature of MMRs ensures that elements are added from left to right, with parents introduced as soon as two children exist, creating a compact and efficient data structure. The implementation of MMRs significantly optimizes storage requirements for smart contracts. With MMRs, as few as 10-11 hashes can be stored in the smart contract while providing access to the entire historical blockchain data. This streamlined approach enhances scalability and resource utilization, making it a more efficient solution for smart contract storage in the Swaps.io Light Clients ecosystem. ## Infrastructural Usage Swaps.io Light Clients represent an inclusive and open solution for multi-chain transaction validation. Implemented as on-chain smart contracts, these Light Clients offer a foundational infrastructure for storing blockchain historical data. Importantly, the design is intentionally open and versatile, enabling not only users within the Swaps.io ecosystem but also external users and protocols to seamlessly integrate and leverage their capabilities for the efficient building of multi-chain applications.
# Non-EVM Networks Integrating light clients for validation within a collateral-based architecture provides a unique opportunity to leverage capabilities of the EVM (the Ethereum Virtual Machine) networks for connecting non-EVM networks like Solana, Tron, and even networks without smart-contract logic such as Bitcoin, Cardano, Ripple, etc. ### Bitcoin Bitcoin uses a Proof-of-Work (PoW) consensus mechanism and lacks support for smart contracts, making integrating with the DeFi ecosystem of Ethereum and other networks challenging. Due to Bitcoin's limited scripting capabilities, the swapping scheme differs significantly from the default implementation through `OrderSender` or `OrderReceiver` contracts. Instead, the logic for validating and recording the swap state relies on the EVM-like send or receive (depending on the direction) and proof networks, requiring signatures from both a user and an Intent Agent. Swaps.io contributors has already introduced a [ZK light client for Bitcoin](https://alpha.succinct.xyz/@MikeKinetex/btcx), which is based on [BTC-Warp](https://github.com/succinctlabs/btc-warp) project and uses Plonky2 proof conversion with subsequent verification through the Groth16 verifier. It will allow checking Bitcoin network transactions in any EVM-like network through a light client contract. Unlike light clients for PoS/DPoS networks, which mainly validate validators' signatures, this one checks if proposed updates match the current network difficulty. Since the strongest chain will always be considered correct, it is essential to maintain the current state of the Bitcoin light client by providing valid data from trusted sources. ### Solana Unlike Ethereum, Solana does not use the EVM to execute smart contracts. Solana smart contracts, typically written in languages like Rust or C, are compiled into machine code that runs directly on the Solana blockchain by the SVM (the Solana Virtual Machine). Integrating Solana to Swaps.io Protocol requires porting the logic of `OrderSender` and `OrderReceiver` solidity contracts to Solana-supported languages. The main challenge is creating a proof verifier for validating transactions in Solana. Thus, it is necessary to connect event-bridge transports that support the validation of Solana network events or implement the logic of the Solana light client (for example, [Tinydancer](https://www.tinydancer.io)) using ZK technology. ### Tron Tron uses the Tron Virtual Machine (TVM) to execute smart contracts. TVM is a runtime environment that interprets the bytecode of smart contracts and executes the instructions on the Tron blockchain. It is compatible with the EVM allowing developers to migrate existing Ethereum smart contracts to Tron with minimal modifications. A few minor modifications are required to make `OrderSender` and `OrderReceiver` contracts available on Tron. Currently, there is a lack of solutions for arbitrary cross-chain message protocols between Tron and Ethereum. As a result, the most reliable option would be to create a Tron light client using ZK technology. Tron utilizes a DPoS consensus mechanism, where token holders elect a set of delegates to validate transactions and produce new blocks. These delegates are responsible for reaching a consensus on the state of the blockchain. Thus, the implementation of a light client must fully implement the logic of selecting validators and checking their signatures. # Gasless Swaps.io Protocol adopts a gasless approach, eliminating the need for users to worry about gas fees during transactions. Traditional blockchain transactions require users to hold native coins for gas fees, posing challenges in managing multiple network balances. By implementing intent-based architecture, Swaps.io dApp simplifies this process by defaulting to gasless technology for swaps. Intent Agents manage gas costs and cover them by deducting them from swapped assets. This approach ensures a seamless and intuitive user experience, allowing users to make swaps without worrying about manually initiating the underlying blockchain transactions. This approach is presented in the following steps: 1. For **Users**, the process is simplified so that they only need to provide approval (i.e., token allowance) for the transactions. 2. An order is created off-chain. The order structure includes details like a User's address, token addresses, amount, minimum return, and deadline. 3. The **User's** signature is obtained off-chain using EIP-712 typed structured data hashing and signing. Such an approach replaces the need for the User to call an on-chain function to initiate a transaction and allows the Intent Agent to manage it independently. 4. The **Intent Agent** handles filling and executing the order entirely on its own, initiating all necessary transactions. 5. The gas costs are included in the transaction rate to ensure smooth execution. This design streamlines the user experience and optimizes the process of executing cross-chain transactions. It minimizes the User's active involvement in the process and ensures that all necessary costs are factored in, resulting in a seamless and efficient transaction process. # LP for Intent Agents Swaps.io Liquidity Pools aim to enhance the efficiency of filling orders within Swaps.io Protocol, trying to solve various challenges related to liquidity placement across different networks and collateral capital inefficiency. When aiming to become an Intent Agents, one may encounter challenges such as: * Placing liquidity in various networks requires not only collateral but also the allocation of liquidity across diverse networks. * Storing liquidity in different assets can lead to potential losses due to price fluctuations in various tokens. * Collateral capital is often inefficiently split for different networks, with only a portion (locked for the `receive` network) used during swaps, leaving the rest unused. Swaps.io Pools introduce multi-chain pools that allow borrowing over-collateralized debts. Intent Agents can borrow assets in any network where liquidity providers have deposited to the pool. Intent Agents must pay a small fee for using pools, thus motivating Liquidity Providers to hold their liquidity there and earn extra income. Swaps.io Pools enable more efficient use of collateral capital. With it, the collateral can be used not only to insure a user’s funds during a swap but also to borrow funds from the pool to pay the user in the destination network. In the `receive` network, one part of the collateral is taken from the user, while in the `send` network, liquidity is borrowed from the pool in debt for the previously unused collateral. Initially, it is planned to support only stablecoins. The support for stablecoins enhances security, minimizing price fluctuations and reducing losses during possible liquidation. Swaps.io Pools serve as a powerful tool for effective liquidity management, and despite incurring higher gas costs, it eliminates the need to store a significant amount of liquidity in different networks. Intent Agents can access liquidity from pools when required. Overall, with multi-chain support and a focus on stablecoins, these pools serve as a critical component in the Swaps.io ecosystem for optimized liquidity management and efficient collateral usage, ensuring a high level of security for both liquidity providers and Intent Agents. # Staking In order to become a **Maintainer** in Swaps.io, one is required to stake a certain amount of tokens. This staking mechanism serves as a form of a security deposit and incentivizes **Maintainers** to act in the network's best interests. It ensures internal coordination and protects against possible misconduct or abuse. In any distributed network, there is a risk that malicious actors could attempt to manipulate the system, for instance, by requesting more rewards than they are entitled to. The consensus algorithm and staking mechanism in Swaps.io work together to mitigate these risks. Swaps.io employs a robust consensus algorithm to maintain cooperation among all system participants and safeguard against potential malicious actions. This consensus protocol facilitates secure and efficient coordination within the network, ensuring that all transactions and operations are carried out reliably and accurately. If **Maintainers** fail to provide valid proof for the transactions they are responsible for or constantly refuse to execute assigned tasks, they are penalized accordingly based on their impact on the system's integrity. This fine is deducted from their staked tokens, providing a strong disincentive against malicious behavior and promoting the overall security and reliability of Swaps.io. It is worth noting that **Maintainers** are not responsible for validating transactions or verifying light client updates. The staking does not guarantee the correctness of proofs because they cannot be invalid by design. As the network's security is provided by ZK technology, a transaction fails when someone tries to provide an invalid proof. Therefore, the staking mechanism is designed primarily to distribute the work among the nodes fairly and maintain consensus between them, as well as to ensure the timely provision of proofs and, accordingly, keep the network up to date. # Swaps.io Security The Swaps.io dApp adheres to the basic principles of DeFi systems and fully implements the following properties that ensure maximum security and openness of operations: ### 1. Permissionless: The protocol is completely open and accessible to any participant so that users can make swaps without hindrance. At the same time, any participant can become an Intent Agent, Liquidator, or Liquidity Provider. The conditions for participation are equal for everyone, as they are controlled by a set of open rules implemented in the protocol's smart contracts and the consensus of the distributed network of Swaps.io Nodes. The system is an open ecosystem, has no prior authorization, and includes no intermediaries or a centralized point of control. ### 2. Trustless: The system is designed in such a way that it does not require trust because of the use of smart contracts and the use of ZK technology. Order validation is based on Swaps.io Light Clients, which are updated by a decentralized network of Swaps.io Nodes using ZK proofs. Users can make swaps with confidence by relying on ZKP's cryptographic properties and immutable smart contract logic. ### 3. Decentralized: The core part of the protocol is a set of smart contracts, the workflow and integrity of which are controlled by a distributed blockchain network. These smart contracts are designed so that the system has no admin roles on the contract level. In addition, some contracts include other contract addresses or some sort of security configuration in their constructors, making them immutable (cannot be changed by anyone once deployed). In addition, the use of a decentralized network of nodes responsible for servicing the protocol (Swaps.io Nodes), including order matching and ZKP generation, ensures that the platform operates without a single point of control. Some protocol settings will be managed by a DAO, which will provide a distributed decision-making process. Thus, the decisions made are focused on ensuring maximum security for system participants, and the risk of manipulation and malicious usage of the protocol is also reduced. ### 4. Collateralized: To fully ensure the security of swaps, the protocol requires Intent Agents to post collateral to be able to carry out swaps. This collateral acts as security for the execution of the order, incentivizing the Intent Agent to complete it in full within the agreed-upon time frame. The order cannot be executed if the collateral does not cover the order volume; this check is performed at the smart contract level and cannot be manipulated. ### 5. Resilient: The protocol is designed to be resilient to potential user losses, either unintentionally or due to Intent Agent abuse. If a problem arises, liquidators can step in and execute an order instead of a failed Intent Agent and seize the Intent Agent's collateral, providing proof of the order's execution. This insurance mechanism adds a layer of financial security and risk mitigation for all participants. ### 6. Transparent: Transparency is a fundamental property of the Swaps.io system. All transactions and orders are executed through interaction with smart contracts and are recorded on the blockchain, ensuring complete openness of operations. Additionally, the community will be able to participate in protocol governance decisions through the DAO, promoting an open and transparent approach to system development. # Integrations Swaps.io Network is introducing the [Swaps.io SDK](https://sdk.swaps.io), a comprehensive toolkit for interaction with Swaps.io Protocol. This powerful set of tools is developed to extend the accessibility of Swaps.io Protocol's functionality with external integrations and enhance interactions with the protocol for users, Intent Agents, and liquidators. ## For Developers The [Swaps.io SDK](https://sdk.swaps.io) extends beyond basic interactions, offering developers a range of advanced features for efficient liquidity and collateral management. The interface is intentionally presented to be simple and straightforward, ensuring ease of use. Intent Agents can take advantage of the SDK to easily manage collateral, performing tasks such as deposit, withdrawal, and rebalancing. Additionally, the SDK simplifies the process of order liquidation and collateral slashing, streamlining these critical aspects for users. ## For Integrations [The SDK](https://sdk.swaps.io) is built for easy integration, making it adaptable to different projects and scenarios. Its developer-friendly interface allows external projects to use Swaps.io dApp's features effortlessly, contributing to widespread adoption. Swaps.io Network plans to introduce a widget constructor, making integration even more straightforward. This innovative tool will enable the easy implementation of built-in swap functionality across a variety of projects and ecosystems. # Deployments Smart contracts of the Swaps.io Protocol are deployed on 25 blockchains. The addresses of the main contracts can be found below, namely: * Main [Flash](#flash) `Diamond` - on all chains * [Collateral](#collateral) in [*Stablecoin*](#stablecoin) and [*Bitcoin*](#bitcoin) variants: * `CollateralManager` - on collateral chain 💰 * `CollateralBastion` - on other chains ## Flash Main Flash contract is represented by [`Diamond`](https://github.com/swaps-io/flash-contracts/blob/5df9c13cb637f97a2cd1943d7824334cfed6fab7/contracts/diamond/contracts/Diamond.sol) instance which contains multiple [facets](https://github.com/swaps-io/flash-contracts/tree/5df9c13cb637f97a2cd1943d7824334cfed6fab7/contracts).
IDChainContract
1Ethereum0x5b7bee906B83a1bD76526BeAE9b1061e505743Fd
10OP Mainnet0xDEb460658269D99C7aef30C52736Df55ad109f42
30Rootstock Mainnet0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
56BNB Smart Chain0x997216c1705917718Ab67e04E7E97641cD28678D
100Gnosis0x8271BeCaD4C7114488461BeD1B9193d4A5126797
137Polygon0x375D2c19c7f68be0a3079d049e7fF9dA4a5c0009
146Sonic0x825da3E4B9380E4F560ed84Fef8f5777079d50F4
169Manta Pacific Mainnet0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
223B20xEF7A91B1de94a078Bde4D72f5DC67924b16DEf47
250Fantom0x572a115B866119A406AB733bb883f5800180e446
1101Polygon zkEVM0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
1116Core Dao0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
4200Merlin0x8d2b9AbD965a2c882E51740C9bb44bD301E09367
5000Mantle0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
6001BounceBit Mainnet0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
8453Base0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
34443Mode Mainnet0xd237D60C79009734Dad3a329fD9B452Cb89A4B33
42161Arbitrum One0x9f02A311E5FD06084C224a30E363c8cDB027d68f
43114Avalanche0x78a7cd9F007EdA6ABB893d3694D0cfCc62836346
59144Linea Mainnet0xC0a70e04bD48d3717BFbCE1D62786A3dD1d86162
60808BOB0x825da3E4B9380E4F560ed84Fef8f5777079d50F4
80094Berachain0x825da3E4B9380E4F560ed84Fef8f5777079d50F4
81457Blast0xEF7A91B1de94a078Bde4D72f5DC67924b16DEf47
200901Bitlayer0xEF7A91B1de94a078Bde4D72f5DC67924b16DEf47
534352Scroll0xEF7A91B1de94a078Bde4D72f5DC67924b16DEf47
## Collateral Collateral is represented by [`CollateralManager`](https://github.com/swaps-io/collateral-contracts/blob/78c62641004a162e59f1ff712d0dd52d61863384/contracts/collateral/CollateralManager.sol) contract on collateral chain (marked with 💰) or with [`CollateralBastion`](https://github.com/swaps-io/collateral-contracts/blob/78c62641004a162e59f1ff712d0dd52d61863384/contracts/collateral/CollateralBastion.sol) instance (on other chains). Depending on which asset is used as deposit, a different contract variant should be used: [*Stablecoin*](#stablecoin) or [*Bitcoin*](#bitcoin). ### Stablecoin
IDChainContract
1Ethereum0x27df5A0A07867dd3CBB8d230D0FF86E6392f7575
10OP Mainnet0x8C5472a8822166706E56B4e468B204Da42597C13
30Rootstock Mainnet0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
56BNB Smart Chain0xcf72e926EE2913feD608Fd877abEdde866405C2d
100Gnosis 💰0x003007b9a9DdB1eb4FAB8f8c99DC0De880E1F294
137Polygon0xda510003821dA6Cb9EdC43d06c343fD8B291BB6a
146Sonic0x1B8638b29fd7fC403328794EfA4FD25b791826Ca
169Manta Pacific Mainnet0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
223B20x161a52008E910Cc6c13f627b7344D6089EC5F590
250Fantom0x961764861dE568cdd53E5FF8AC250cE0a5332a98
1101Polygon zkEVM0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
1116Core Dao0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
4200Merlin0x161a52008E910Cc6c13f627b7344D6089EC5F590
5000Mantle0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
6001BounceBit Mainnet0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
8453Base0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
34443Mode Mainnet0x9B867573157148F6c253B757e9dF987A47B22866
42161Arbitrum One0xb5EA8d3DA74ccc9Ef137104c21980784ABF3a7d4
43114Avalanche0x948D668cC1860080616dcd0B422234B47A2B8E3e
59144Linea Mainnet0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
60808BOB0x1B8638b29fd7fC403328794EfA4FD25b791826Ca
80094Berachain0x1B8638b29fd7fC403328794EfA4FD25b791826Ca
81457Blast0x161a52008E910Cc6c13f627b7344D6089EC5F590
200901Bitlayer0x161a52008E910Cc6c13f627b7344D6089EC5F590
534352Scroll0x161a52008E910Cc6c13f627b7344D6089EC5F590
### Bitcoin
IDChainContract
1Ethereum0x0f6864A6f98C7BAD50d33d3eF173056Da03AA072
10OP Mainnet0x652c1FD67e2caB16CdA3DB83A9104D0e87169692
30Rootstock Mainnet0x9B867573157148F6c253B757e9dF987A47B22866
56BNB Smart Chain0x22a2010f2743653052Bd5C1E0027ed68FECc1E42
100Gnosis 💰0xd418993d5f3C43c248bCbB964bBE227C051Ac84a
137Polygon0xbFa3A222A533ddB8f8278372f65Ad49B4950DAae
146Sonic0x87484F07761394D8E208C99FE11F061491EAA943
169Manta Pacific Mainnet0x9B867573157148F6c253B757e9dF987A47B22866
223B20x842307edB8fdD6F1702F320ed6cD2763Ff3b04C4
250Fantom0x26546C6c01410c2A1b5d28597cEc2A702BEE7BF3
1101Polygon zkEVM0x9B867573157148F6c253B757e9dF987A47B22866
1116Core Dao0x9B867573157148F6c253B757e9dF987A47B22866
4200Merlin0x842307edB8fdD6F1702F320ed6cD2763Ff3b04C4
5000Mantle0x9B867573157148F6c253B757e9dF987A47B22866
6001BounceBit Mainnet0x9B867573157148F6c253B757e9dF987A47B22866
8453Base0x9B867573157148F6c253B757e9dF987A47B22866
34443Mode Mainnet0x0B2bD79Ac058315c1D6f8229B577DB9c7a682Fe3
42161Arbitrum One0xe0Af05d1002753bB6ff81868C6439E392F5dCB09
43114Avalanche0x981c9244C7DCc57295455745ab4727B48488247D
59144Linea Mainnet0x9B867573157148F6c253B757e9dF987A47B22866
60808BOB0x87484F07761394D8E208C99FE11F061491EAA943
80094Berachain0x87484F07761394D8E208C99FE11F061491EAA943
81457Blast0x842307edB8fdD6F1702F320ed6cD2763Ff3b04C4
200901Bitlayer0x842307edB8fdD6F1702F320ed6cD2763Ff3b04C4
534352Scroll0x842307edB8fdD6F1702F320ed6cD2763Ff3b04C4
# Flex Liquidity Pools Flex Pools introduces a unified, cross-chain liquidity layer designed for intent-based protocols. Instead of relying on fragmented, self-managed inventories or centralized credit lines, solvers can borrow and return assets through various providers that access liquidity (i.e. borrow and return it) in standardized way. Liquidity providers, in turn, earn additional yield from solver execution flows in a secure, permissionless environment. The system aligns the interests of three core participant groups: * **Solvers** gain instant, on-demand access to liquidity with no need to manage cross-chain inventory or borrow from external creditors. Each interaction follows transparent on-chain contract logic, with the solver accessing liquidity only at the moment it is needed and paying solely for the duration of use. This eliminates long-term debt, fixed interest obligations, and regulatory exposure. The protocol abstracts away inventory management, rebalancing, and cross-chain verification, allowing solvers to focus purely on execution algorithms and routing logic – similar to on-chain solving. * **Liquidity Providers** benefit from a scalable, multi-chain investment model with on-chain guarantees replacing legal liabilities. Flex Pools offer programmable liquidity and capital efficiency that goes beyond what common liquidity pools can offer, enabling LPs to earn additional yield from solvers’ activity. * **Solver-based systems and infrastructures** – including intent-driven protocols and networks, chain-abstraction smart wallets and dapps, fast-fill bridges, and clearing layers – gain access to a shared liquidity infrastructure that lowers entry barrier and improves execution efficiency. By decoupling liquidity from solvers and clearly separating roles, Flex Pools enables greater decentralization and composability across the intent-based stack. # Architecture Flex Pools is a modular liquidity protocol designed for intent-based cross-chain execution. It allows solvers to borrow assets on one chain and return them on another using standardized *borrow-and-return* operations. These operations are carried out through a variety of secure whitelisted *taker* adapters to third-party providers.

Example of workflow of asset-locking protocol

The system is organized into *enclaves* – sets of EIP-4626 tokenized vaults deployed across multiple chains for a single logical asset. Each vault manages deposits, withdrawals, and share accounting on its respective chain. The vaults within an enclave are connected through a common infrastructure that handles cross-chain messaging and verification, leveraging *event verifiers* backed by *oracles* to ensure execution validity. The protocol is designed to be composable, enabling integration with various *taker* adapters, *event verifiers*, and *tuners* defining fee models. # Operations The following operations provide the pool protocol functioning: * **Liquidity Providers** (LPs) deposit their asset ([ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20) token) to pools of interest. In return they receive shares - as per [ERC-4626](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626) standard. Shares increase in asset value as protocol operates. * 3rd-party **protocol adapters** (PAs) are implemented and verified to be secure for pool system by **Decentralized Autonomous Organization** (DAO). The verified adapters are added to pool whitelist, which enables them to use the liquidity. * **Solvers** select 3rd-party protocol adapters from the whitelist according to their solving needs. Taking liquidity comes with *protocol fee*, which is distributed among LPs proportional to their shares. * Pool ensures that liquidity will be (or already) returned back by **solvers** to enclave (same-asset pool on any supported chain). This is one of the security conditions for adapter to be whitelisted. * Pool keeps track of crosschain liquidity balance. Changing the balance in negative way comes with extra *rebalance fee* for **solvers**, meanwhile fixing the imbalances is rewarded from the accumulated rebalance fee - which attracts a special kind of **rebalance solvers**. * **Liquidity Providers** can withdraw their original asset in exchange for the previously issued shares # Roles The main pool [operations](#main-operations) imply the following roles that enable the protocol to function and benefit from it: * **LPs** - Provide liquidity for solvers. Get yield from collected protocol fee. * **Solvers** - Make use of liquidity for solving. May also benefit from rebalance operations. * **PAs** - Receive increase in protocol usage. Attract new users and income. * **DAO** - Extends protocol for more solving possibilities. Ensures security for LPs and solvers. # Infrastructure The protocol deployment organizes each *logical* asset (i.e. asset that has same symbol and market price) into a pool *enclave*. Each enclave is a `FlexPool` contract configured with the asset contract on the current chain and deployed on every supported chain. The `FlexPool` contract contains whitelist of allowed [*takers*](/flex-liquidity-pools/takers) - contracts that can use the deposited liquidity of the pool. The whitelist is managed by *controller*, which is a DAO-controlled contract. The list of supported pool enclaves and corresponding contract addresses can be found in "[Deployments](/flex-liquidity-pools/deployments)" page. Some of the deployment components rely on Flex Proof verifiers. The information on how to obtain the verifier proofs can be found in "[Proofing](/flex-liquidity-pools/proofing)" page. # Takers Takers are adapter contracts responsible for handling the execution logic of a take operation. Each taker is linked to a specific third-party provider or routing system and is approved through the pool’s internal whitelist. Takers receive the borrowed assets from the pool and must guarantee that a corresponding repayment occurs on another chain. > Taker implementation must: > > * *call `take`* of trusted (generally *immutable*) `pool` contract address > * *guarantee* that `minGiveAssets` will be (or already) provided back to the pool enclave > * *provide protection* against pool asset double-spending and call reentrancy attacks > * *return unused* part of received assets to its *caller* (or agreed address from function data) Taker implementation is not bound to any specific interface. However, it's common that the function name starts with `take` prefix and at least accepts `assets` value to pass to the pool. The rest of the function parameters, as well as the list of other functions exposed by the taker contract, depend on specifics of the underlying provider. Takers may rely on paired `Giver` contracts deployed on the opposite chain. These contracts wrap a `give` operation, emitting verifiable events used to confirm that liquidity has been returned. Givers may enforce additional logic or safety checks required by the taker’s provider. # Across Takers based on [Across protocol](https://docs.across.to/introduction/what-is-across). Two primary flows are supported: * *fill* - take pool asset for filling an already deposited order on another chain in exchange for repayment to the origin's pool of the same enclave * *deposit* - take pool asset and immediately deposit it expecting the order to be filled on another chain with the same enclave's pool as recipient ### Across Fill `AcrossFillTaker` implementation of taker provides an ability to take pool asset for filling an already deposited order on another chain in exchange for repayment to the origin's pool of the same enclave. The taker contract expects input and output tokens to *match* tokens managed by pools in corresponding chains. First, Across *deposit* must be committed on the origin chain. This action emits `FundsDeposited` event, the proof of which is expected on the take chain (`depositProof`). Along with the proof, the `takeToFillRelay` function accepts a number of parameters to reconstruct the original event for verification. > Number of `assets` for `take` is allowed to be different from `outputAssets` due to rebalance logic and strict validation of the original event components. The take sufficiency will be validated still and any surplus assets of the operation will be returned to the taker caller. Once event and parameters are verified, `SpokePool`'s `fillRelay` function is called. The taker contract provides the asset for the fill as `msg.sender`, specifying the *repayment* chain to be the origin `giveChain` chain and the *receiver* account to be `givePool`, thus ensuring `givePoolAsset` token will be returned to the enclave eventually. > If any of `take`, verification, or `fillRelay` phases fails, entire `takeToFillRelay` call fails. ### **Across Deposit** `AcrossDepositTaker` implementation of taker provides an ability to take pool asset and immediately deposit it expecting the order to be filled on another chain with the same enclave's pool as recipient. The order created has input and output tokens *matching* the tokens managed by the pools in corresponding chains. As the first step, a solver should call `takeToDeposit` function of the taker. The taker will receive at least `assets` from the pool, which is with the optional surplus should be sufficient to cover `inputAmount` (the rest is returned to the caller). The `outputAmount` value should cover pool-requested `minGiveAssets`. Once deposit is successfully created, the solver should obtain `FundsDeposited` event details and fill the order on the target chain (`giveChain`) using `SpokePool`'s `fillRelay` function. If this part is failed (deadline exceeded), funds are returned to the pool on the origin chain by Across protocol - as specified in the on-chain formed order. # 1inch Fusion+ `FusionTaker` implementation of taker provides an ability to take asset using [1inch Fusion+](https://portal.1inch.dev/documentation/apis/swap/fusion-plus/introduction) protocol. The taker comes with `FusionGiver` contract that serves as starting point of the take process. First, solver calls `fillOrder` contract function, that has the same parameters as the one in `IOrderMixin` interface of Limit Order Protocol. The order must contain post-interaction to deploy `EscrowSrc` via escrow factory with pool asset deposit to it from the maker. The `FusionGiver` becomes 1inch taker of the order, providing the *original* taker with `IEscrowSrc` required functionality - withdraw, cancel, rescue (calls should be to the `FusionGiver` contract). Public phases can be called directly on the escrow contract. Once source escrow is created, the solver obtains proof of `SrcEscrowCreated` event and calls the `take` function of the pool with `FusionTaker` as `taker` and corresponding `takerData`. After validation, `EscrowDst` deploy is called on factory with `FusionTaker` assigned as 1inch order taker. Pool asset is transferred then to the escrow contract. Then the order proceeds according to the 1inch Fusion+ protocol. On success, the maker asset in source chain is transferred to the pool (transiting though `FusionGiver` contract if it's a *public* withdraw), on cancel - back to the maker. On destination chain, cancellation returns asset back to pool (possibly though `FusionTaker`), on success - to a specified receiver. # CCTP `CctpTaker` implementation of taker provides an ability to take pool asset and *burn* it using Circle's [CCTP protocol](https://developers.circle.com/stablecoins/cctp-getting-started). The burned asset then can be *minted* on destination chain using the protocol. The minted asset (except the protocol fee) is automatically directed to the destination chain's pool (configured as recipient during the *burn* phase). > The solver who bridges the asset using CCTP taker benefits from the *surplus* asset, provided by pool to the taker contract and unspent during *burn*. This surplus is part of the pool's rebalance logic. # Transfer `TransferTaker` implementation of taker provides an ability to take available asset from pool *after* giving asset on another chains though. The give operation is performed via `TransferGiver` contract, that emits `TransferGive` event that is verified by the taker. > `TransferTaker` keep record of already `taken` operation so double-takes are not possible. The records are per take asset `receiver` (i.e. taker's `caller`) and `nonce`. > > Managing `nonce`s is `receiver`'s responsibility and should be done with *caution*. Sending asset via *two or more* `give` (or `giveHold`) functions with *the same* `takeChain`, `takeReceiver` and `takeNonce` params will result in only *one* take possible (since subsequent ones will be blocked after the record of a first one). ### Relief Giver There is another variant of `TransferGiver`: `TransferReliefGiver`. It works similarly to the original one, except it's aware of its `IExtraRelief`-capable tuner (such as `ElasticTuner`). After providing asset to pool, the giver collects *possible* surplus assets for the rebalance-beneficial action and sends them back to the caller. # Deployments This page contains list of supported [Flex Liquidity Pool](/flex-liquidity-pools) asset encaves and corresponding contract addresses. ## USDC ### Asset
IDChainContract
10OP Mainnet0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85
130Unichain0x078D782b760474a361dDA0AF3839290b0EF57AD6
8453Base0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
42161Arbitrum One0xaf88d065e77c8cC2239327C5EDb3A432268e5831
### [`FlexPool`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/pool/FlexPool.sol)
IDChainContract
10OP Mainnet0x920a7eDb58A01d310937645a737345E36cEed546
130Unichain0x7f002BB64fa933a84358808A9166f6673f7DC744
8453Base0x99042E7F7Dc24B584F3aAe42De90B26c5a55E7cD
42161Arbitrum One0x2cd5505301AeDf04653B9D4C20af78ddAE48E293
### [`Controller`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/control/Controller.sol)
IDChainContract
10OP Mainnet0x2f5549AE521E698c09518cFF57Eb514374BAE031
130Unichain0xDA719641F7F5506cDA057B9EDDC40b9b158bA71C
8453Base0x3133AdAFB62133b339d35F342F72057f34482025
42161Arbitrum One0xACAf095929dce7f7e3fA529a815470A816cE7795
### Takers #### Transfer [`TransferReliefGiver`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/transfer/TransferReliefGiver.sol)
IDChainContract
10OP Mainnet0xFf532F73dBE2D5FA939a05D387BaBE2fCde36CB6
130Unichain0xb0fA2196AEef80C0fcf221D18f60046e17cC99bb
8453Base0x01D000B85919Bbe4757fd174C214923B48F253dd
42161Arbitrum One0x69B83B56BD15d209a74bF23B6156296702d566e1
[`TransferTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/transfer/TransferTaker.sol) (giver on 10)
IDChainContract
130Unichain0x3609C33DEB75ACf9C74c15A26460919FD527a328
8453Base0xCEF8fb3300970E32C97E6492aCEaAd1f5EA7463E
42161Arbitrum One0x044419774A869d220751C8EEF9e016a46DD7E5Ba
[`TransferTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/transfer/TransferTaker.sol) (giver on 130)
IDChainContract
10OP Mainnet0x3D5D2851b11FaD82E75fcADF4f9E608AbD298a30
8453Base0x4AAa506e7e54a67354f421324Df745ACB6B604ff
42161Arbitrum One0xC67Dce61B320A3192871ca9BBB7ceCF218EB5A7a
[`TransferTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/transfer/TransferTaker.sol) (giver on 8453)
IDChainContract
10OP Mainnet0xc9982D2cA235dC12BB57AE072451732dbb7fa684
130Unichain0x45F420996B02bf4A0858420E706C5b3591357d8e
42161Arbitrum One0x371bE7BBD233a8b255E4D6b96412430D1ba8203F
[`TransferTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/transfer/TransferTaker.sol) (giver on 42161)
IDChainContract
10OP Mainnet0x41ca978DE708a8BB8cB26fCEE02e1350E587f738
130Unichain0xfc818e53fcF040F5aD787F725435a2407F46E962
8453Base0x818314694CCfFEDD17d0E84BF2802b1004C19913
#### CCTP [`CctpTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/cctp/CctpTaker.sol) (from 10)
IDChainContract
130Unichain0x5BB0af4F69c1Db937f6A189Ef8326c7ED1b26f52
8453Base0xa393AC0db4c6b3ae6519573D370C6f4e87cEfFba
42161Arbitrum One0x163520e3eFeeA329e2e17816f03Fe84898eE3eBF
[`CctpTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/cctp/CctpTaker.sol) (from 130)
IDChainContract
10OP Mainnet0x9f02A311E5FD06084C224a30E363c8cDB027d68f
8453Base0x938ec9e3719c9F2606d5BA6100231A4dEc9DCe4B
42161Arbitrum One0xB2be11293e551a3E9a09ebb0d18F0b64c3Cc5F4a
[`CctpTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/cctp/CctpTaker.sol) (from 8453)
IDChainContract
10OP Mainnet0x7c07fC404bE49D333d002D316b61906E3b4E05F0
130Unichain0xcbB8DF8465D1eE0232B41679f4A052aBE4F0eEe3
42161Arbitrum One0x7eE298d5F1d00f84E232f852Eaa1c43526412C91
[`CctpTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/cctp/CctpTaker.sol) (from 42161)
IDChainContract
10OP Mainnet0x8cd7d68feE0f9e4b62aA350408DF05606808DC39
130Unichain0x7fc7eB073F2B8A843bce728562b88A9bf8da73C0
8453Base0xcd1ad5d918bE528C45075d7a10910af25B64a36F
#### Across [`AcrossFillTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossFillTaker.sol) (from 10)
IDChainContract
130Unichain0x9B867573157148F6c253B757e9dF987A47B22866
8453Base0x6d48aC41c66eE2e9b37778a12d12e09F0F3c313e
42161Arbitrum One0x021b78CF39601D4e7DE3D5f5Be0115FAA69FF51b
[`AcrossFillTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossFillTaker.sol) (from 130)
IDChainContract
10OP Mainnet0x5ab3006a3D64c4B988ba8e5b39eC285cb9463Bf6
8453Base0x46597F03c6A8A8135dB5fD69Ee0331BdCe3f93b4
42161Arbitrum One0xD004Cc7fD6242c64F92B738e3B9218Ea08AaEC98
[`AcrossFillTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossFillTaker.sol) (from 8453)
IDChainContract
10OP Mainnet0x3E2b4e11ec652f15f3B94b75E260925aa60b6023
130Unichain0x0B2bD79Ac058315c1D6f8229B577DB9c7a682Fe3
42161Arbitrum One0xc5Cfe002ccfd51faeed79960F23Af37d2f04Bb64
[`AcrossFillTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossFillTaker.sol) (from 42161)
IDChainContract
10OP Mainnet0x6FBbf736C66479ADA6C8D7513E5a6D1c830C7cae
130Unichain0x15521e6BD276b0CaB2814De81b41c05c8E53D7BB
8453Base0x3F38811aFc1b426c2de8DA31D37781346f440D68
[`AcrossDepositTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossDepositTaker.sol) (from 10)
IDChainContract
130Unichain0x2b842bff88A03D2cee3D65e9F6c730c6A17210eC
8453Base0x30E25E15cF945f5bCFa55C4dDDf01f881C137039
42161Arbitrum One0x3dCD128d1efB675742C87b9c2C5fC6352BdBd4F8
[`AcrossDepositTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossDepositTaker.sol) (from 130)
IDChainContract
10OP Mainnet0x58Dfa2Cd5A57f657b3a98F76AB5163ECC9da2823
8453Base0xF5778e1951D7cEaEF58DbA0faf08F4d5E1bB6B76
42161Arbitrum One0x085A4Ad43C306cF9c3BbF715eC8fF1Bf3F6ba3d3
[`AcrossDepositTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossDepositTaker.sol) (from 8453)
IDChainContract
10OP Mainnet0xd006Fe071d519DEC2b4eE2b9646b0bF3aEde926D
130Unichain0x81fE6fdC5903Ae17F11AB491bba0cc76f17dd413
42161Arbitrum One0xF1F1b185B266Fe2ad460a3372eA579Cbb9222950
[`AcrossDepositTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/across/AcrossDepositTaker.sol) (from 42161)
IDChainContract
10OP Mainnet0xeAbb8CD78533A31Bc443726c172e6a726c18D0eb
130Unichain0x8d2b9AbD965a2c882E51740C9bb44bD301E09367
8453Base0xfa6c78642a02766CaA508034AaEac98dDEfC19e4
# Proofing Some of the Flex Liquidity Pool [takers](/flex-liquidity-pools/takers) rely on Flex Proof protocol. The proof protocol provides a way to verify an event occurrence on other chain. The fastest way to prove an event for the pool protocol is using *signature* proof variant. This proof can be issued by Flex Node, which is hosted at [`https://node.swaps.io`](https://node.swaps.io/) . It supports the following HTTP API: * #### Get Chain Proof Info * `GET /api/v0/proof/chain/` , where: * `` *(path param)* - chain ID to get proof info of * #### Get Event Proof * `GET /api/v0/proof?chain=&hash=&log=` , where: * `` *(query param)* - chain ID of the event * `` *(query param)* - hash of the event transaction * `` *(query param)* - log index in the transaction Request & response examples: ```bash # Get proof info for Optimism chain (ID 10): curl 'https://node.swaps.io/api/v0/proof/chain/10' # Example of successful chain proof info response: { "chain": 10, "latestBlock": 138194551, "minConfirmations": 30, "provableBlock": 138194521, "signer": "0xb0baabc608dd2d1704d190ccdeecca624104c6ac" } # Get proof of Arbitrum chain (ID 42161) event occured in transaction with hash # "0xd97a2a1306bfbdde8c0b929c2aa85fae38699af3d1ec581258bd6a936fe50f46" at index #0: curl 'https://node.swaps.io/api/v0/proof?chain=42161&hash=0xd97a2a1306bfbdde8c0b929c2aa85fae38699af3d1ec581258bd6a936fe50f46&log=0' # Example of successful event proof response: { "chain": 42161, "hash": "0xd97a2a1306bfbdde8c0b929c2aa85fae38699af3d1ec581258bd6a936fe50f46", "log": 0, "block": 350395852, "confirmations": 5180366, "minConfirmations": 240, "emitter": "0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9", "topics": [ "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", "0x0000000000000000000000009f6d65052ad5818768fcbac3b799a67f2b8e7170", "0x000000000000000000000000b58b4060745ec6377ea0b65c9f2eb4e1c4068374" ], "data": "0x0000000000000000000000000000000000000000000000000000000028351f10", "proof": "0x000000000000000000000000000000000000000000000000000000000000012c8ad459dfe203ceeec8eed289d95a9c81dc8c810a74dd647f2b9df98b305900a1356b3ee37ac75b752167cbf41427933bf9be4bd15c67680277ea2ddb9eb43f9f1c", "signature": "0x8ad459dfe203ceeec8eed289d95a9c81dc8c810a74dd647f2b9df98b305900a1356b3ee37ac75b752167cbf41427933bf9be4bd15c67680277ea2ddb9eb43f9f1c", "signer": "0xb0baabc608dd2d1704d190ccdeecca624104c6ac" } # Example of an error response (note "error" field presented): { "error": "Block 355577210 of transaction 42161/0x64d1d125349bf365fb42064763274df23c5f21c40bc09a49868bae5d2ec6a4df has only 69 confirmations - at least 240 required to prove log #1 (wait 171 more blocks)" } ``` The result `proof` value can then be passed as `bytes` to a taker that requires it - for example, `giveProof` param of [`TransferTaker`](https://github.com/swaps-io/flex-pool-contracts/blob/f01e565a2f2e6f107c20d76cd2644a055ea7acb1/contracts/taker/transfer/TransferTaker.sol#L53). # FAQ
What is Swaps.io dApp? Swaps.io is a peer-to-peer platform that connects users and Intent Agents, bridging liquidity between decentralized finance (DeFi) and centralized finance (CeFi) ecosystems.
What benefits do users gain from Swaps.io dApp? Users can enjoy fast, secure transactions at the best available rates.
What benefits do Intent Agents get? Intent Agents have the ability to construct their own trading strategies and earn income from transactions.
Does Swaps.io Protocol use wrapped tokens? No, users interact on-chain with Intent Agents and do not need to create extra virtual assets.
Why work directly with Intent Agents instead of using AMMs? Working directly with Intent Agents eliminates slippage and ensures guaranteed transaction execution, unlike automated market makers (AMMs).
How long does a swap take? The average transaction time is 3-5 seconds, depending on each network.
How is the security of the user's swap ensured? For each transaction, an Intent Agent must reserve collateral larger than the order size, ensuring security of user funds.
How is the execution of the order and rate guaranteed? Orders are backed by the Intent Agent's collateral. If the Intent Agent does not execute the order, it is liquidated automatically.
Does the user need to provide a proof that the transaction was not completed? No, liquidation occurs automatically.
Can the user receive the asset in another network? No, the liquidator swaps the collateral for the asset that the user expects.
Why will liquidation occur on time? The collateral is liquidated with a commission for the liquidator. The first to detect a debt and initiate liquidation earns income. Liquidators compete in speed to earn income.
Why are Swaps.io dApp's prices more favorable? Because there is no need to pay validators, Swaps.io employs an optimistic scenario where transactions occur directly between Intent Agents and users without additional expenses, resulting in significant gas optimization.
What is an optimistic scenario? In an optimistic scenario, proof costs are only incurred if a liquidator creates a proposal stating that the Intent Agent did not complete the transaction.
How do Intent Agents set prices? Intent Agents compete with each other on price and offer the best rates. The order is given to the Intent Agent that offers the most favorable rate.
Can I provide liquidity to Swaps.io Protocol? You cannot provide liquidity to Swaps.io Protocol itself, as it does not store liquidity. However, you can provide liquidity to the specialized Liquidity Pool, which offers multi-chain over-collateralized loans to Intent Agents that might want to use it.
What are the fees in Swaps.io dApp? Swaps.io dApp does not charge any fees. The protocol is fully decentralized and non-profit. Intent Agents set their own fees independently.
How can I get an NFT? You can acquire NFTs by completing tasks in the Community Building Program.
How does Swaps.io dApp differ from other projects that offer cross-chain swap solutions? Swaps.io Protocol offers users several advantages that set it apart from other existing solutions: ### Fixed Rates With Swaps.io Protocol, users can forget about price slippages and associated losses. Intent Agents guarantee the execution of instant transactions at fixed prices, providing sufficient collateral for each swap. ### Instant Execution The execution of transactions occurs at the speed of an on-chain transaction, 3-5 seconds, depending on the network. This is possible because Swaps.io Protocol does not rely on third-party validators, utilizing zero-knowledge proofs. ### Gasless Flow With Swaps.io Protocol, users can forget about gas payments. They only provide approval to the Intent Agent, and then the latter conducts a non-custodial p2p swap, receiving the user's asset and giving back the agreed-upon asset. The Intent Agent covers all gas costs, taking the corresponding amount from the user's original token. This is not a final list, though. The more Swaps.io dApp develops, the more unique and helpful features it gets.
What wallets does the Swaps.io dApp support? Currently, it supports MetaMask, Rainbow, Zeal, Rabby Wallet, Ledger, Trust Wallet, Coinbase Wallet, and many others via WalletConnect.