# 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 Kinetex team aligns 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. Kinetex believes 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, Kinetex believes 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, Kinetex introduces 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 Kinetex 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 resolvers to seamlessly create a fair market with customized trading strategies while keeping their developments private on the backend. The resolvers can also develop next-generation bots using machine learning and thoroughly analyze database sources using artificial intelligence. Thus, Kinetex enables resolvers 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 Kinetex? Kinetex presents an innovative approach to solving several existing problems in the field of blockchain. The first task that the Kinetex team 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. Kinetex's 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 resolvers' wallets and moves between them and the users. Therefore, Kinetex completely prevents TVL attacks. One of the key features of Kinetex is the ability to transfer assets instantly. All transactions occur on-chain, contributing to an efficient and seamless user experience. Kinetex's approach to instant transfers is truly revolutionary, as it removes the need to wait for cross-chain validation. Resolvers in the Kinetex 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. Resolvers 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, Kinetex allows resolvers to link DeFi with the liquidity from centralized finance (CeFi), increasing the number of available liquidity sources. The Kinetex protocol employs an optimistic system that optimizes gas usage and costs. Instead of requiring users to pay validators for every transaction, Kinetex allows users to pay only for the asset transfer itself, eliminating extra costs and creating a more efficient transaction process. However, liquidators and resolvers have to pay for generating proofs. Liquidators must send proofs when they want to take a resolver's collateral after liquidation, and resolvers must send proofs when they want to withdraw their collaterals. Instead of AMMs that have several issues, Kinetex 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. Kinetex 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 the Kinetex Protocol The Kinetex protocol was created to protect the users as much as possible with the help of professional market makers (called resolvers) that manage all risks connected to trading and blockchain reorganization. Although anyone who provides collateral to ensure security can participate in the Kinetex protocol, they should take into consideration the said risks and build their trading strategies accordingly. To enhance the security of each transaction, Kinetex implements a collateral system, which is the backbone for safe interactions between users and resolvers. Each transaction is backed by a resolver's collateral, eliminating the need to trust resolvers 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 the Kinetex protocol is completely decentralized ZK-based liquidation that ensures a lack of a single point of control. Kinetex is designed so that any participant can initiate liquidation of an unfilled order, provide a proof that they have completed it, and take a resolver'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 a resolver allocates 2000 USDT tokens as collateral. If the resolver 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 Kinetex At the beginning of 2023, the Kinetex team launched the first version of the protocol, a [meta-aggregator](broken://pages/0PgojoDvULTYGKMCNwfq) 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 Kinetex'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 Kinetex 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 Kinetex 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 Kinetex 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, resolvers 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 resolver can fill. Suppose a resolver 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 resolver needs to update its state after ensuring that all transactions have been successfully completed and there are no debts left. Resolvers 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 a resolver 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 Kinetex team came up with a model of decentralized P2P trading, where two on-chain transactions are created between a user and a resolver, where the resolver technically has the ability to process the transaction instantly in the first block. Moreover, the resolver 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 is 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 (resolvers), who will compete to fulfill them. The decentralized level serves as a filter between user requests and resolvers, filtering against spam, malicious intents, or failures from resolvers. Thus, we get a pool of intents in the form of an auction, where users place their request for order execution. All resolvers 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 resolver to execute it. In turn, the resolver commits to complete the order by blocking part of the collateral. The Kinetex 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 Kinetex team uploaded a ZK light client for native Bitcoin called [BTCX](https://alpha.succinct.xyz/@MikeKinetex/btcx) to the SuccinctX platform. In 2024, the Kinetex team plans to complete the integration of the ZK Light client into the Flash Trade protocol, which will open access to Bitcoin in DeFi, enabling direct swaps of BTC for ETH and other crypto assets. The main difference is that such a solution will not require pools storing BTC since any participant can deposit collateral and start processing orders as a resolver or send a request for a swap to resolvers. Resolvers will be 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. # Roadmap ## Roadmap 1. **Smart bots (analyzers of market and competitors)**: Market analysis is crucial for Kinetex's further development, and a real-time change-tracking system is a key to future success. Smart bots help analyze the state of the market for the reorganization of blockchain blocks, price spikes, and changes in the external economic environment while also calculating gas costs, slippage, and commission losses of market participants. Direct connection to blockchains, data parsing, and search algorithms with market emulation will help Kinetex to see the market clearly and build an effective development strategy. 2. **Launch of the decentralized testnet**: The Kinetex team plans to launch a decentralized testnet with four key entities: * protocol maintainers (computing power required for ZK), * decentralized liquidators, * resolvers, * users. The testnet will run for three months, serving as a testing ground for finding bugs. During this time, the team will work closely with the community and develop profitable strategies for all parties involved together. 3. **Migration to Mainnet**: An important task is to make a smooth transition from the testnet to the mainnet. Running with a limited amount per transaction will help complete debugging on the main network. The primary tasks will be debugging the estimation of gas prices by resolvers, monitoring execution over time, tracking block reorganization, and creating trading strategies for various assets. Public resolvers will be available when the service is fully operational and becomes public. 4. **Public SDK/API Release**: Following the mainnet launch, the team intends to release a public SDK/API. It will enable the integration of the protocol into any project, such as wallets, lending protocols, and more. Aggregators will be able to use Kinetex as a source of liquidity, given the protocol's ability to guarantee both order execution and price stability. Those are two much-needed features in today's DeFi market, particularly for seamless cross-chain operation. 5. **Development of ZK router and network expansion**: The team will focus on the development of the ZK router that will offer the market participants a secure solution for validating transactions between networks. The goal is to expand the use of ZK technology and increase the number of supported networks to provide users with cheaper gas and faster transaction speeds. It is an integral part of the Kinetex community's commitment to continuous improvement and adaptation to the demands of the DeFi market. # Flash Trade Protocol In Flash Trade, users simply select their desired token and enter the amount they wish to swap. The resolvers then manage the rest of the process. Once a user agrees to the rate, they sign the order, giving a resolver permission to access their assets. The resolver reserves an equivalent amount of collateral, ensuring the safety of the user's assets even if the resolver refuses to execute the order after the user has already transferred the funds. In Flash Trade, the resolvers 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. The resolvers have an average 2-minute window to finalize the orders. 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 the resolvers while guaranteeing that users will always receive the desired assets. Overcollateralizing each transaction demotivates the resolvers to avoid responsibility and encourages liquidators to execute liquidations as quickly as possible. Moreover, the architecture of the Flash Trade 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 the Kinetex protocol are the following four categories: **Users**, **Resolvers**, **Maintainers**, **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 the Kinetex protocol receive the best possible rates from **Resolvers**, while Resolvers compete to provide the best swap rate and duration. **Resolvers** are the key players in the Flash Trade protocol. Resolvers 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. Resolvers 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 Resolver is responsible for its own liquidity and should set rates only after a thorough risk analysis. **Maintainers** maintain the protocol and constantly update the state of the **Kinetex Light Clients** (contracts that store the state of a blockchain) of the networks where **Resolvers** perform transactions. By having the current state of the blockchain stored in the `LightClient` contract, Resolvers can validate and confirm their transactions. **Maintainers** can perform several types of tasks, including: Generating proofs for ZK light clients (this task requires sufficient computing power but has a higher reward); Updating light clients based on Hashi (cross-chain adapters); Order matching and aggregation and management of resolvers; Other tasks related to the stable and consistent operation of the system. Anyone with tokens staked in **Kinetex DAO** can become a Maintainer. DAO staking is mandatory because the amount of staked tokens will affect the consensus, the number of tasks executed by the staker’s node, and the share of fees charged to Resolvers and other protocol users of the protocol. These fees can be used to increase the stake in the DAO or withdrawn without any restrictions. In addition, a Maintainer can be penalized with a stake in the DAO in case of the inability to complete a task or an attempt to attack the system trying to appropriate more rewards than they should. **Liquidators** ensure that the whole system works fairly for Users and that all transactions are completed on time. If a Resolver takes a user's funds but fails to execute an order, their collateral will be liquidated. If a Liquidator finds a transaction that the Resolver 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 Resolver's collateral. The liquidation process is described on the [Liquidation](/flash-trade-protocol/liquidation) page. **Liquidity Providers** can provide liquidity to **Liquidity Pool**, which offers multi-chain over-collateralized loans and can be used by resolvers as additional liquidity to execute the orders. Once the asset is borrowed, a resolver 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

Flash Protocol overview

1. To be eligible to execute orders, **Resolvers** 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. **Maintainers** must **stake in Kinetex DAO** to be eligible to maintain the protocol. The DAO stakes serve as a guarantee of a fair distribution of work among Kinetex Maintainers. It can be slashed if a **Maintainer** fails to complete the assigned task or update the state of Light Clients or attempts to abuse the protocol. Maintainers are rewarded for completing different tasks, such as updating the state of Light Clients, providing computing power for ZKP generation, matching orders, and validating the order flow. 4. **Resolvers** pay to the Kinetex DAO pool in the form of a protocol maintenance fee. Fees ensure that **Maintainers** are motivated to complete assigned tasks and keep the system fair, and **Resolvers** always have the actual state of light clients. *Not only Resolvers can use the protocol. Anyone can utilize **Kinetex Light Clients** inside their applications but must pay fees to the protocol maintainer pool.* 5. **Resolvers** 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 query service, which is a part of decentralized Kinetex Nodes powered by Maintainers. This service queries registered resolvers for suitable swap orders they can provide. Each Resolver can provide its own rates and set faster execution times, securing orders by higher collateral amounts. Each Resolver also has a score calculated in a decentralized way by Maintainers, 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 Resolver 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 Resolver 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 **Maintainers**. 2. **Maintainers** query the registered **Resolvers** and pick the best order according to the rate, execution time, and resolver score. 3. If the **User** agrees to this order, they check the collateral state of the **Resolver**. 4. If the **Resolver** has enough collateral, the **User** can sign the order. 5. The **User** approves the transfer of the order asset to the **Resolver**. 6. The **Resolver** 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 **Resolver**. If receive is not performed by the **Resolver** (within the deadline specified in the order), the swap is considered canceled. Continuous cancellations can affect the **Resolver** score and limit its ability to execute orders. Once the **Resolver** 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 **Resolver** 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 **Resolver**'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 **Resolver** 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 Kinetex Light Clients, to unlock the collateral. After successfully receiving the order asset in the initial blockchain, the **Resolver** fills the order in the destination blockchain: 1. The **Resolver** calls the `OrderSender` contract with the order structure and transfers funds to the contract. Usage of **Trusted Forwarders** allows for more complicated transactions involving borrowed liquidity or swapped assets. 2. The order is checked by the `OrderSender` contract, and then the **Resolver**’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 Resolvers to deposit collateral, the system ensures there is an additional layer of security protecting Users' funds. If the Resolver fails to process a transaction correctly, liquidators will still execute the order due to the presence of collateral.

Collateral deposit overview

1. Before the Resolver can begin processing transactions, the Resolver is 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 Resolver'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 Resolver, 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 Resolvers by providing corresponding proofs. # Unlock collateral

Collateral unlock process

This sequence of actions illustrates how the Flash Trade 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 Resolver 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 Flash Trade 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 Resolver 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 Resolver 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 Flash Trade 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 a Resolver. 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 Resolver nor Liquidator sends assets, a slash by the User is activated. In this flow, the User gets the Resolver'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 resolvers to utilize their capital efficiently for executing swap operations. In an effort to minimize gas costs, Flash Trade 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 resolver 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 resolver's collateral). When no more collateral is available, the resolver 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 resolver collaterals for swap insurance. This contract supports both the deposit and withdrawal of the authorized collateral assets (ERC-20 stable tokens) by resolvers 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`, `KinetexFlashLight`) 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 Flash Trade 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. # Kinetex Light Clients Kinetex Light Clients are the core component responsible for validating operations in the Kinetex Flash Trade 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 Kinetex 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 the Flash Trade protocol, ensuring faster block header validation with the ability to access the most recent blocks in a blockchain. ### Bitcoin Kinetex actively works on the ZK light client for Bitcoin, which will help 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 Kinetex 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 Kinetex to maximize networks' coverage in the future, ensuring the best interoperability between them and allowing users to use Flash Trade in the most secure and highly gas-efficient manner. But besides this, Kinetex 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 Kinetex to validate transactions more efficiently and securely. ## Checkpoint-Based Storage Optimization To enhance the efficiency of smart contract storage, Kinetex 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 Kinetex Light Clients ecosystem. ## Infrastructural Usage Kinetex 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 Kinetex 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 a resolver. At the moment, Kinetex is actively working on 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 the Flash Trade 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 Kinetex Flash Trade 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, Kinetex simplifies this process by defaulting to gasless technology for swaps. Resolvers 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 Resolver to manage it independently. 4. The **Resolver** 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. # Trusted Forwarders The standard order execution flow assumes that the executor must be the resolver address specified in the order structure. While this is important for security, it also creates certain restrictions for resolvers since it eliminates the possibility of indirectly calling the order execution method, for example, from custom smart contacts. For this purpose, the **Trusted Forwarders** mechanism ([EIP-2771](https://eips.ethereum.org/EIPS/eip-2771)) was implemented in Flash Trade. The `KinetexForwarder` contract is an `ERC2771Forwarder` implementation based on the OpenZeppelin library. It extends signature-recovery options to allow both meta transactions from externally owned accounts (EOAs) and ERC-1271 signatures from smart contract via the `SignatureChecker` library implemented by OpenZeppelin. Some of the main Kinetex Flash contracts inherit OpenZeppelin's `ERC2771Context`, which allows meta transactions from constructor-initialized trusted forwarder contract addresses. The `KinetexForwarder` contract will be deployed and used as the trusted forwarder in these contexts. # LP for Resolvers Flash Trade Liquidity Pools aim to enhance the efficiency of resolving orders within the Flash Trade protocol, trying to solve various challenges related to liquidity placement across different networks and collateral capital inefficiency. When aiming to become a resolver, 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. Flash Trade Pools introduce multi-chain pools that allow borrowing over-collateralized debts. Resolvers can borrow assets in any network where liquidity providers have deposited to the pool. Resolvers must pay a small fee for using pools, thus motivating Liquidity Providers to hold their liquidity there and earn extra income. Flash Trade 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. Flash Trade 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. Resolvers 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 Flash Trade ecosystem for optimized liquidity management and efficient collateral usage, ensuring a high level of security for both liquidity providers and resolvers. # Staking In order to become a **Maintainer** in Kinetex, 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 Kinetex work together to mitigate these risks. Kinetex 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 Kinetex. 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. # Flash Trade Security The Flash Trade platform 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 a Resolver, Maintainer, 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 Kinetex 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 Kinetex Light Clients, which are updated by a decentralized network of Kinetex 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 (Kinetex Nodes), including order matching and ZKP generation, ensures that the platform operates without a single point of control. Some protocol settings are managed by a DAO, which provides 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 resolvers to post collateral to be able to carry out swaps. This collateral acts as security for the execution of the order, incentivizing the resolver 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 resolver abuse. If a problem arises, liquidators can step in and execute an order instead of a failed resolver and seize the resolver'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 Flash Trade 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 can participate in protocol governance decisions through the DAO, promoting an open and transparent approach to system development. # Integrations Kinetex is introducing the Flash Trade SDK, a comprehensive toolkit for interaction with the Kinetex Flash protocol. This powerful set of tools is developed to extend the accessibility of Flash Trade functionality with external integrations and enhance interactions with the protocol for users, resolvers, and liquidators. ## For Developers The Flash Trade SDK 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. Resolvers 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 is built for easy integration, making it adaptable to different projects and scenarios. Its developer-friendly interface allows external projects to use Flash Trade features effortlessly, contributing to widespread adoption. Kinetex 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. # Aggregation Protocol The Kinetex Aggregation mode works on multi-layer architecture. The aggregation layer collects trading liquidity solutions such as DEXes, DEX aggregators, bridges, limit order protocols, etc. Kinetex algorithms build routes between existing protocols and automatically select the best option, also allowing users to view a list of other possible routes if needed. In addition, Kinetex algorithms analyze the depth of existing liquidity, simulate various scenarios, and calculate gas costs and other fees, providing the most user-friendly experience. This functionality is well suited for swapping rare tokens because Kinetex algorithms can find the most favorable routes even for the rarest crypto assets traded on DEXes. #### Automation Kinetex uses a network of relay nodes that provides the ability to automate any swap route, eliminating the need for users to confirm transactions at intermediate stages. The nodes also calculate gas needed for intermediate parts of the routes and pay for it automatically, executing the swap process autonomously. #### Liquidity aggregation Kinetex serves as a multi-chain liquidity aggregator, executing swap transfers along routes created with unique algorithms that work like search engines, finding the fastest, cheapest, and safest swap routes. By integrating popular DEX aggregators, numerous multi-chain bridges, limit order protocols, and liquidity from multi-chain market makers, Kinetex provides the ultimate asset coverage of the crypto market, including over 15,000 tokens and coins across numerous networks and blockchains. #### Gasless transactions The most convenient swap process is achieved in combination with the Multi-chain Gasless technology, which allows users to pay for gas automatically with any token in any network (even if a swap route passes through several networks). # Architecture

Kinetex Aggregation Architecture

The Kinetex Aggregation solution has a multi-layered implementation with an architecture divided into four layers. **The Aggregation Layer** is a set of aggregated solutions for providing trading liquidity, such as DEXex and DEX aggregators, bridges, limit order protocols, and other sources of liquidity. The combination of many liquidity sources allows Kinetex to offer users the most favorable rates for the requested exchanges. **The Routing Layer** is responsible for building optimal exchange routes. At this stage, all the necessary data (quotes, commissions, liquidity volumes, etc.) is collected, analyzed, and then used to build exchange routes and generate data to launch the Kinetex Aggregation on-chain infrastructure. This layer uses the internal backend infrastructure, which includes a set of services such as *Quote Fetcher, Route Finder, Calldata Builder*, and *API Gateway*. See the [Route Building](broken://pages/bPl9qrh1lvXQKEPOScqu) section for more information. **The UI Layer** defines user interaction with the Kinetex Aggregation product by providing a flexible and user-friendly interface (a dApp widget). At this level, the users can effortlessly go through all steps of the exchange process. These steps include, but are not limited to, the selection of assets for the exchange, flexible configuration of exchange parameters (gas, slippage, liquidity sources used, etc.), viewing of the detailed routing and all fees charged, monitoring the status of the exchange, a history of completed exchanges, etc. The web application has a static open-source implementation and can be deployed on decentralized Web3 storage hostings (such as IPFS), which ensures the security and integrity of all displayed data. There is also the possibility of external integration as an embeddable widget. The purpose of the **Execution Layer** is to conduct the exchange. This layer consists of a set of smart contracts and the infrastructure necessary for their launch. The network of relay nodes is used for this, and its task is to run Kinetex Aggregation contracts on supported networks. The Kinetex Aggregation contracts themselves, in turn, interact with the contracts of the swap and bridging protocols, passing the users' exchanged assets through them, according to the given EIP-712 signatures. # Smart-contracts Kinetex Aggregation contracts: ``` Ethereum (1): 0x54562f3ca0A957FE5d6bD8Fa1a96e84E2c957F56 Optimism (10): 0x8f9489136b26448c066B9faA30b275bb446633D4 Binance (56): 0xD73C27e629dd365702f78fEcA684d705D6311656 Gnosis (100): 0x8F41C31acC5e3eCF2FBbe6e36F3d28ccE99ffBFE Polygon (137): 0x7fF0D32453a15d6114b60DE9de8e3dd7a303E2fF Fantom (250): 0xF1138297B7654d0e955a461C26Af11741638A54F Arbitrum (42161): 0xb5AaD6f62E181B98877A8135505E013206688851 Avalanche (43114): 0xCc2CC14e235AD822f9AE34800362EE5bd8Ab5A9d ```
# Liquidity Sources Nowadays, a majority of DeFi services offering cross-chain transactions have a rather inconvenient and inefficient algorithm of actions for users. As the DeFi industry strives to be decomposable, there are a lot of individual projects that perform swaps and bridging. Therefore, users need to sort through many projects on different networks, select the DEXes and bridges necessary for the exchange, analyze liquidity and rates, and carry out all the exchange steps manually using different and often unfamiliar interfaces. In addition, all DEXes have their own separate liquidity and pools that cannot be conveniently and simultaneously accessed. The problem is that each pool has different prices and sometimes insufficient liquidity to ensure low slippage, especially when users make high-volume trades. Bridges have similar problems as most do not provide support for an adequate variety of networks and may also have limited liquidity. All this leads to the lack of a universal solution for cross-chain asset exchange in the DeFi sector. Acting as a meta cross-chain aggregator, Kinetex solves these problems by combining many sources of liquidity across all supported networks. Such sources include, but are not limited to: * DEXes and DEX aggregators (*that combine more than 80 DEXes across different networks*); * Bridges (*more than 20*); * Limit order protocols (*1inch Limit Order protocol, 0x etc*.); * Market makers liquidity

Kinetex liquidity sources

The combination of all the liquidity sources mentioned above allows users to use all the exchange options in one interface and receive the most favorable rates. We constantly integrate new sources of liquidity based on the community's wants and needs. # Route Building

Kinetex route building

The route building procedure is implemented by three components of the Kinetex internal infrastructure: * Quote Fetcher * Route Finder * Calldata Builder If users intend to make a deal, they generate a request to exchange assets, passing it through the **API Gateway** to the internal search and routing services. The **Quote Fetcher** service is launched first, the main task of which is to collect rates, liquidity volume, and other parameters necessary for further analysis. All collected quotes are transferred to the **Route Finder** service, which determines the best way to exchange any given token between blockchains. The service performs a deep analysis of possible routes using data collected by Quote Fetcher and builds the most optimal route in terms of profitability, speed, and security. Each integrated DEX and bridge has its own layer in the quote engine that returns the best possible trade option. The Kinetex service compiles them into a list of routes with various combinations of different DEX and bridge quotes. As a result, the user can choose the most suitable route according to their specified priority criteria. Additionally, Kinetex strives to use existing aggregation solutions to achieve the best results.By integrating popular DEX aggregators whose algorithms search for, prioritize, and optimize routes and distribute liquidity among different DEXes, Kinetex allows users to maximize the overall profit from the transaction. Besides, Kinetex enables analysis of liquidity volumes in all networks in order to make more profitable intra-chain transactions. Thus, the exchanged asset can be bridged to a neighboring network, exchanged with less slippage, and then returned to the original network. The Kinetex algorithms take into account that the number of tokens supported by each bridge is limited; therefore, an exchange from a user's asset to a bridge-backed token is often required. Based on this, the algorithms automatically determine which intermediate token should be used for maximum capital efficiency. After the route has been built, **Calldata Builder** helps to form a data package necessary for the transaction. This package is a data structure that stores a set of structures such as SwapStep. The generated data package is signed by the user following the EIP-712 standard to enable further on-chain route verification. # Advanced Routing

Kinetex advanced routing

A complex multi-part exchange route (one including many liquidity sources) requires calling each of the route’s smart contracts separately. It makes achieving the atomicity of the whole operation impossible, causes additional gas costs, and requires confirmation of several transactions. This problem is solved by exchanging assets through **Kinetex Advanced Router**. The router is designed as a smart contract to combine several exchange points within the same network, thus ensuring the atomicity of the operation from start to finish within that network. The use of one smart contract call reduces gas costs and eliminates the need to confirm every step of the exchange (be it a DEX swap transaction or an execution of a bridge's smart contract). The key feature of the router is the ability to automatically connect the liquidity of bridges, DEXes, market makers, and limit order protocols, achieving the best deals. In addition, Kinetex Advanced Router may split the exchanged amount and exchange it on several bridges or other liquidity sources in parallel, thus increasing the depth of the available liquidity and minimizing the price impact. The router's functionality will be completely transparent: the source code will be made public and audited by independent security companies. It is planned to deploy the router’s smart contract on all supported EVM networks. # Automated Execution ### Purpose Suppose an exchange is made along a route that includes two or more networks. Such a route can take quite a long time, considering the transfer of assets through bridges. One bridge transfer can take up to 15-30 minutes, depending on the technology and the time of a block confirmation in each network. Thus, the manual control of this process can be quite tedious. Relay nodes serve to provide complete **automation of the exchange process**, eliminating the need to be online throughout the entire exchange and confirm each step. Specifically, such steps as confirmation of transactions, gas payments, search for routes, and processing of intermediate assets are performed automatically without user interaction. This solution will offer the possibility of automated liquidity management and execution of various tasks, such as the purchase and sale of goods and services, trading strategies, and NFT transfer in games and marketplaces. ### Workflow

Kinetex automated exchange flow

Initiation of the automatic exchange requires only allowance to the exchanged token's balance at the beginning of the exchange and user-signed route data. After providing a signature to the relay network, it is safe to leave the app without waiting for the exchange to be fully complete. Relay nodes schedule jobs to monitor the receipt of the exchanged asset on the balance and send signals to the network of nodes. After the user signs the route and confirms the exchange, the rest of the work is taken over by Relay Nodes Network. The nodes launch smart contracts with the allowance to the balances of the tokens involved in the exchange. As a result, the exchange takes place in a completely automatic mode. At the same time, users no longer need to worry about gas since all gas fees are charged from the exchanged asset, making the process of calculating the rate and the final amount received more transparent. ### Security The nodes act as executors of smart contracts and transaction relays, excluding direct interaction with liquidity and account balances. Funds are securely protected by validation mechanisms in Kinetex Advanced Router’s smart contract. Assets are sent only to the points indicated in a user-signed route (DEXes, bridges) and returned directly to the user's balance after an exchange. ### Networks coverage Automation is currently supported on the following networks: Ethereum, BNB Chain, Polygon, Arbitrum, Optimism, Avalanche, Fantom, Gnosis Chain, Cronos, Moonriver and Moonbeam. ### Automation vs. Bridges with callbacks The standard scenario for making a one-click exchange is to use bridges that can make a callback to the target network simultaneously with the token transfer. Thus, using the capabilities of the cross-chain messaging protocol for transferring liquidity and data in one transaction, it is possible to pass further instructions for the exchange. However, this approach has several disadvantages: * Exchange uses a limited set of bridges that support the ability to transfer data along with liquidity; * There are additional gas costs since the data transmitted to the target network is stored in on-chain storage; * The entire exchange route is initially available to third parties, simplifying and stimulating MEV attacks. Automation through relayers has enabled us to eliminate all of the above problems. Relay nodes help interact with funds coming from any bridge to a user-owned minimal proxy smart contract. Relayer's next task is to launch the subsequent steps of the exchange following the route signed by the user. The route is divided into as many parts as networks it combines to avoid disclosing the full route during exchange initialization. Then, each part is given to the corresponding network as the exchange continues (see [Security](/aggregation-protocol/aggregation-security) section for more details). # Gasless Transactions Blockchain technology requires keeping native coins for paying gas fees on every blockchain used in the exchange to be able to complete a transaction. Otherwise, the funds may get frozen. However, keeping track of the balances of all coins required for payments in various networks is quite difficult. The procedure becomes even more complicated when exchanging assets through intermediate networks in the absence of a direct bridge between the original and target blockchains. Gas payments, a technical feature of blockchain, should not bother users, making their experience with crypto more stressful. Therefore, Kinetex has decided to offer all users a gasless approach. The gasless technology works by default during automated exchanges. Nodes take over all gas costs, subtracting them from the exchanged assets along with the commission for the completed request. Currently, relayer's network accepts a variety of tokens as a payment for further gas expenses and uses its own fee calculations. At Kinetex, gasless transactions are implemented in two ways: "permit"-approach and Gas Escrow service. ### Gasless flow with "permit" > Arguably one of the main reasons for the success of EIP-20 tokens lies in the interplay between approve and transferFrom, which allows for tokens to not only be transferred between externally owned accounts (EOA), but to be used in other contracts under application-specific conditions by abstracting away msg.sender as the defining mechanism for token access control. > > However, a limiting factor in this design stems from the fact that the EIP-20 approve function itself is defined in terms of msg.sender. This means that the user’s initial action involving EIP-20 tokens must be performed by an EOA. If the user needs to interact with a smart contract, then they need to make 2 transactions (approve and the smart contract call which will internally call transferFrom). Even in the simple use case of paying another person, they need to hold ETH to pay for transaction gas costs. At the protocol level, the functionality of ERC-20 tokens remains rather limited due to the lack of abstraction in their “approve” method. Simply put, users must hold ETH in their balances in order to be able to interact with any smart contract on Ethereum. ETH is required to pay gas costs when sending an additional transaction, also known as approval, allowing a specific smart contract to use your token. The issue was addressed in the EIP-2612, and the neat solution is a so-called “permit“ method added to the token structure that allows users to change the permission mapping via a signed message rather than via msg.sender. #### **Implementation**

Gasless flow with "permit"-complied tokens

Tokens that comply with the EIP-2612 standard can be transferred into a contract without using a network’s native coin. To do this, a user generates an EIP-712 signature containing the parameters needed to run the permit method. The message with the signature and parameters is included in the swap calldata, intended for transmission to the network of relay nodes. Thus, using this signature, both the necessary approval and the launch of the exchange process occur in one call to the contract. At the same time, a commission is charged from the exchanged token, which reimburses the cost of gas. In the same transaction, this commission is transferred to the Fee Collector, where it is further distributed among the node holders. ### Gas Escrow service Kinetex aims to provide the best user experience for transactions in DeFi and eliminate any inconvenience associated with the use of gas. Suppose a user has a token in a network where they do not have a native coin. Moreover, this token does not support the EIP-2612 standard, which is true for the majority of stablecoins and many other popular tokens. To perform any transaction with the token, the user needs to replenish their balance in a required native coin to pay for gas or give the signed transaction to the relayer (which cannot be done through Metamask, for example). To solve this problem, Kinetex offers the Gas Escrow Service that can make gas payments for users in any supported network, requiring a small deposit in return (available for withdrawal at any time). This service has a structure similar to lending solutions but works cross-chain and has the possibility to lend users native coins of supported networks. On average, the deposit amount can range from $1 to $15, depending on selected networks, the price of native coins, the size of the gas fee, and the maximum gas limit. There is no minimum or maximum amount, though. For an escrow can be used: * positive slippage from exchange operations; * NFT received in Kinetex Test Flight program; * locked / unlocked KIX tokens; * any other supported token on any supported network. Withdrawal is available at any time if the user has no outstanding debts. Funds placed in escrow are not spent and remain unchanged, provided there are no debts. Users can request any amount of gas their escrow can cover, with the obligation to pay it back. When repaying, the user needs to pay in full the previously spent amount, the gas fee spent for the transfer of a native coin, and the GasTank fee. #### Implementation

Gas Escrow service flow

This service is completely decentralized and consists of two modules: **GasEscrow** and **GasTank**, which are smart contracts located on all supported EVM networks. **GasEscrow** is responsible for escrow deposits and withdrawals. When making a deposit, each user specifies the token to be deposited, its amount, and the networks where they need to pay gas. Given that gas costs vary from network to network, the received amount is distributed among the gas pools for the chosen networks in a way it is enough for the same number of operations. Chainlink Price Feeds are used to calculate the amount deposited in each pool, and manual calculation is also possible. The deposit division and its consequent placement in different pools are necessary to protect against double-spend attacks when gas is requested simultaneously in several networks. **GasTank** is responsible for storing and distributing gas. It stores information about the amounts of gas issued to each user and accepts repayments for previously issued gas along with a commission for its use. Chainlink Price Feeds are also used to calculate gas lent to users. GasEscrow and GasTank modules can be used in different networks. So, a user can have an escrow in USDC on the Ethereum network and request gas for the Fantom network. At the same time, communication between modules is implemented through Chainlink Oracles that make eth\_call requests to blockchain nodes to obtain the results of the view-methods of contracts responsible for displaying the current state of the escrow and the user's debts. A request to pay for gas from a GasTank is made using the relay nodes API or the internal Kinetex executor. In the future, it is planned to switch to a distributed network of Kinetex Relay Nodes for all networks. In addition, a request for gas loans can be made from a GasEscrow contract using cross-chain messaging protocols (Celer IM, Layerzero, etc.). # Aggregation Security {% hint style="warning" %} Note: despite all the security measures taken, it should be taken into consideration that independent audits of the contract are still in progress. Moreover, we cannot guarantee the security of external bridging protocols. There is currently a $10,000 transfer limit. {% endhint %} In Kinetex Aggregation, great attention is paid to the security of transferred assets and maintaining the user's control over them throughout the exchange process. The protocol implements a set of measures designed to ensure the reliability of the exchange operation and the safety of funds throughout the exchange route.
### User-signed routing parameters When initiating the exchange, the user signs the `SwapStep[]` structure, which includes an order of exchange steps. This structure includes such data as chain id, swapper contract address, account address, deadline, checking inputs and outputs for minimum and maximum thresholds, and parameters for the used bridging protocols. All parameters are securely validated inside the smart contract, and the user's signature guarantees their integrity and validity. To verify the signatures, the `SwapSignatureValidator` auxiliary contract is used, which works with signatures of the EIP-712 format. The user's signature guarantees the correct exchange within the specified parameters in all networks and using all necessary protocols, as well as excludes any distortion of the selected parameters by third parties. ### Routing through user-owned contracts When intermediate assets come from the bridge to the target network, their direct owners need to maintain control over them. One solution is to transfer funds directly to the users' wallets, but then it becomes necessary to approve the contract in each network for each token used in the exchange. For the Kinetex protocol, a different approach was chosen: **user-owned delegate contracts** implemented as **minimal proxies**. Such contracts are deployed on a per-user basis in a deterministic manner, using the **`CREATE2`** opcode and the user's address as a salt, which means that each address of the generated contract can be known in advance. At the same time, no one can create this contract except for the xSwap contract during the exchange or users themselves. This contract is deployed as `Ownable` and `Initializable`, and ownership is transferred to the user during initialization. The contract also has methods for withdrawing funds from the balance available only to the user, which ensures their safety and availability to the user even in the most exceptional situations. The deterministic nature of such contracts' deployment allows users to transfer funds to their addresses even when the contracts have not yet been created. Thus, users can save both gas and time by creating a contract during the exchange after receiving funds for it. # Risks Mitigation # Slippage and Rates The initial rate is calculated using the DEX price quote at the time of the route building. However, on decentralized exchanges, the problems of **price slippage** and **price impact** are very acute. These problems are especially typical for cross-chain exchange, where atomicity is not guaranteed, and both price slippage and price impact get out of control. ### **Bridgeless cross-chain swaps** Direct cross-chain transactions with a fixed rate eliminate the effects of price slippage, thus allowing users to avoid losses during the exchange. Kinetex implements such transactions by using bridgeless cross-chain swaps (namely, its own Kinetex atomic cross-chain exchange protocol and integration with Hashflow). The Kinetex algorithms always give priority to building routes through them. ### Slippage tolerance and gas level In the case of building routes through traditional sources of liquidity, Kinetex has an effective tool for handling slippages. This feature, called "**Slippage Tolerance**", can be accessed within the swap settings and allows users to set the slippage percentage they can tolerate during the trade. The recommended minimum slippage is 2-4%, and the default setting is **2%**. Another important setting is the gas level. It must be taken into account that a low gas level increases the chance of a transaction not being included in the next block and, consequently, the slippage being unsuitable. Therefore, we recommend setting at least a "**Medium**" gas level. ### Intermediate exchange assets To reduce the impact of these metrics on a trade, Kinetex prioritizes routes with the same asset or stablecoins as intermediate assets. With such an approach, when the exchange fails within the established slippage tolerance, a user's asset is fixed in the original asset or in one of the stablecoins, reducing the risk of volatility and significant price changes throughout the exchange process. ### Failed Transactions A transaction will fail if the received amount of tokens at some stage does not pass the set slippage tolerance. If it happens at the first step of the exchange, the original asset will be returned. In other cases, the exchange amount will be returned fully in one of the stablecoins. Even though gas fees for failed transactions cannot be returned, such a method prevents a further loss of funds. Additionally, Kinetex introduces a deadline parameter during which a failed exchange will be automatically retried by relay nodes when better market conditions occur. The default deadline time is set to 20 minutes. ### Reducing risks The influence of price slippage and price impact is significantly reduced in the following cases: * exchange through bridgeless cross-chain exchange protocols; * exchange within the same network when using the Kinetex Advanced Router; * the exchange route includes no more than two networks, while the bridge is the last exchange point; * bridging: exchange of stablecoins or same assets in the different networks (for example, *COMP.ETH -> COMP.BNB, USDC.MATIC -> USDC.ETH*). # MEV Protection The MEV (Maximal Extracted Value) phenomenon has a huge and diverse impact on the DeFi market. The technological features of the blockchain operation and decentralized trading mechanisms allow manipulations with transactions of ordinary users that lead to the minimization of their potential profit during the exchange. MEV is especially easy to achieve when performing complex cross-chain exchanges on aggregators that automate them. During the initiation of the exchange, the entire planned route is published to the public. Additionally, sufficiently large slippage values ​​are set to increase the chances of a successful exchange. All this leads to the maximum insecurity of cross-chain payments made through aggregators and their potential unprofitability. Kinetex Aggregation has taken a set of measures aimed at significantly reducing the influencing factor of MEV attacks. The main methods are discussed below. ### Flashbots All transactions in Kinetex Aggregation go through relay nodes, making it possible to manage their publication in the mempool. The networks most affected by MEVs, mainly Ethereum, often resort to using private mining capabilities. So, at the moment, Kinetex publishes transactions through the infrastructure of the Flashbots organization, thus helping to avoid the disclosure of transaction details before they appear in the mined blocks and therefore exclude their analysis by MEV search engines. In the future, as Kinetex transitions to its own network of nodes, the development team will continue to use every opportunity to reduce the impact of MEV attacks on our users' transactions. ### Preventing premature route disclosure All exchanges in Kinetex Aggregation are based on a signed user message that includes details of transactions in each of the route's networks. This message has the format of a Swap structure, which contains an array of SwapStep structures and is incorporated in the SwapParams structure. The SwapStep structure has a chainID field, so each step is applied separately to each network. When this message is published to the public, it becomes possible to carry out MEV attacks, foreseeing the entire exchange route in advance. In order to reduce this risk, the contract was upgraded using the SwapStealth structure. When using it, only the user-signed set of hashes of each SwapStep structure is published with the first transaction, and the data of each step itself is published directly during the exchange. These measures are designed to complicate the extraction of MEV and therefore reduce its risk significantly. # Control of Approvals The user needs to keep track of the issued approvals. In Kinetex Aggregation, there are two token allowance options: a one-time approval for the exact amount of the current exchange and an infinite approval that frees users from re-issuing approvals. We recommend using the first method as it provides more security without giving access to the entire balance of the token in the user's wallet. At the same time, it is clear that infinite approvals allow for a more convenient user flow, reducing the user's actions in the Metamask wallet. Moreover, such approvals enable users to save gas. As most users prefer to issue an infinite approval, Kinetex plans to introduce an interface in which they will see all the approvals issued to the Kinetex contract and have the ability to change or cancel these approvals. # FAQ
What is Kinetex? Kinetex is a peer-to-peer platform that connects users and professional resolvers, bridging liquidity between decentralized finance (DeFi) and centralized finance (CeFi) ecosystems.
What benefits do users gain from Kinetex? Users can enjoy fast, secure transactions at the best available rates. Security is ensured by the Kinetex network itself as it allows transactions to be executed on-chain.
What benefits do resolvers get? Resolvers have the ability to construct their own trading strategies and earn income from transactions.
What benefits do protocol maintainers get? Protocol maintainers perform the computational tasks associated with Zk proofs and sell these services to resolvers, earning income in the process.
Do users need to pay for gas? No, resolvers fully manage the transaction and pay the gas fees for the users.
Does Kinetex use wrapped tokens? No, the user interacts on-chain with the resolver and does not create extra virtual assets.
Why work directly with resolvers instead of using AMMs? Working directly with resolvers eliminates slippage and ensures guaranteed transaction execution, unlike automated market makers (AMMs).
How long does a swap take? The average transaction time is 10-15 seconds, with a maximum time for the resolver of 2 minutes. After this period, liquidation is triggered, closing the order as quickly as possible.
How is the security of the user's swap ensured? Each resolver reserves collateral for the transaction larger than the order size, ensuring security.
How is the execution of the order and rate guaranteed? Orders are backed by the resolver's collateral. If the resolver does not execute the order within 2 minutes, automatic liquidation occurs.
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.
How does order liquidation occur? Order liquidation is fully decentralized. Anyone who provides a deposit of $100 can create a proposal, provide a proof that the resolver did not complete the transaction, and unlock the collateral.
What happens if a liquidator creates a false proposal? They will lose their deposit.
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.
At what price does liquidation occur? Chainlink oracles ensure a minimum price at which an order can be liquidated.
Why are Kinetex's prices more favorable? Because there is no need to pay validators, Kinetex employs an optimistic scenario where transactions occur directly between resolvers 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 resolver did not complete the transaction.
How do resolvers set prices? Resolvers compete with each other on price and offer the best rates. The order is given to the resolver that offers the most favorable rate.
Who manages the order system? Orders are managed by a distributed network of protocol maintainers, ensuring the security of the network and the rates provided by resolvers.
Do resolvers need to perform Zk proofs themselves? Protocol maintainers perform the computational tasks associated with Zk proofs and sell these services to resolvers for state updates.
Can I provide liquidity to Kinetex? Kinetex does not store liquidity.
What are the fees for Kinetex? Kinetex does not charge any fees. The protocol is fully decentralized and non-profit. Resolvers set their own fees independently.
What are Kinetex NFTs? NFTs are used for staking to gain voting power for decision-making.
Can I sell my NFTs? No, NFTs are non-transferable and are created to serve the network, not for speculation.
How can I get an NFT? You can acquire an NFT by completing tasks in the Kinetex Ambassador and Testnet programs.
How does Kinetex differ from other projects that offer exchange solutions? Kinetex has several unique features: * The first one is automation. Kinetex offers an automatic exchange that is performed regardless of the route's length, so users do not need to stay online to confirm each transaction. * The second distinctive feature is a variety of supported crypto assets. Kinetex aggregates numerous tokens and coins (over 15,000), including native ones, and enables their trading with the help of tokenization protocols. * The third distinction is the Multi-chain Gasless technology that eliminates the need to care about storing gas. This is not a final list, though. The more Kinetex develops, the more unique and helpful features it gets.
What does automation through relay nodes mean? Relay nodes automate the execution of smart contracts. They allow users to complete the entire route automatically without the need to stay online and confirm each transaction.
How does the gasless technology work? The Gasless technology eliminates the need to store native coins for each network and to worry about their shortage. This technology helps to travel through the universe via interdimensional swaps while holding only one EIP-2612-compliant token (including any such stablecoin). If you do not have a permission-enabled token, place a small staking deposit of $5-20 in escrow so relay nodes can always pay gas for you and top up the deposit with assets you exchange.
Do I need to replenish the escrow deposit myself again? The escrow deposit does not need to be replenished again. It is restored automatically through the relay nodes using the exchanged tokens.
Can I withdraw the deposit from the escrow? Yes. You can request your deposit from the escrow service at any time. An oracle will check that you have no debts in other networks, and your assets will be transferred to you.
What is a native coin tokenization gateway? Kinetex utilizes native coin tokenization protocols that create wrapped tokens and bring them to the nearest bridges using the route-building algorithms, thereby transferring transactions into the required networks. Such an approach allows you to exchange any asset quickly and reliably.
How does the exchange of native coins such as Bitcoin work? Support for native coins (BTC, LTC, BCH, etc.) is implemented in the form of wrapped tokens through the integration of such tokenization protocols as Ren Protocol, tBTC, and a multi-chain DEX (THORChain).
How does cross-chain work at Kinetex? Inside Kinetex, we combine dozens of reliable bridges and providers that are whitelisted and manually added to the ecosystem. Thus, users can safely cross the space between different networks in two ways: by using stablecoins for the intermediate stages or by exchanging assets directly. Priority is given to identical tokens on different networks. If such a route cannot be found or there is not enough liquidity, then the original asset will be exchanged for a stablecoin, bridged to another network, and finally to the desired asset. To reduce the impact on the price, Kinetex chooses assets with high liquidity.
What is liquidity aggregation? How does it work at Kinetex? **Kinetex does not use its own liquidity.** The specially-designed exchange algorithms aggregate liquidity from various protocols to transfer assets between networks and build the most efficient routes. Liquidity is drawn from many sources, including decentralized exchanges, bridges, market makers (public and private), limit order protocols, Layer-2 networks, etc.
What wallets does the Kinetex project support? Supported wallets: MetaMask, WalletConnect, and XDeFi Wallet. Coming Soon: BinanceChain Wallet, Coinbase Wallet, Liquality Wallet, and Bitkeep Wallet.