|
| 1 | +## Off-chain Routing |
| 2 | + |
| 3 | +Off-chain Routing algorithm computes the most optimal transaction routes. It can be called via the JS SDK, which is the recommended way of interacting with Concero API. The Routing data is then used by the SDK to compute call data for the user's wallet to execute. |
| 4 | + |
| 5 | +## Orchestrator contract |
| 6 | + |
| 7 | +The Orchestrator contract serves as an entrypoint for users or protocols to interact with Concero cross-chain infrastructure. |
| 8 | +It is responsible for managing the entire transaction on a single chain, allowing a user to perform multiple actions with a single function call. |
| 9 | + |
| 10 | +The actions include: |
| 11 | +1. Swaps on decentralised exchanges (single or multiple) |
| 12 | +2. Obtaining bridgeable tokens before bridging |
| 13 | +3. Interactions with other protocols (coming soon) |
| 14 | + |
| 15 | +The Orchestrator exposes the following interface for users and protocols to interact with the infrastructure: |
| 16 | + |
| 17 | +#### Swap |
| 18 | +Suitable for single-hop and multi-hop swaps on a single chain. |
| 19 | + |
| 20 | +[//]: # (todo: add supported DEXes) |
| 21 | +```solidity |
| 22 | + function swap( |
| 23 | + IDexSwap.SwapData[] calldata _swapData, |
| 24 | + address _receiver |
| 25 | + ) external; |
| 26 | +``` |
| 27 | + |
| 28 | +#### Bridge |
| 29 | +Suitable for cross-chain bridging, where no swaps need to be performed on either of the chains. |
| 30 | +```solidity |
| 31 | + function bridge( |
| 32 | + IStorage.BridgeData memory bridgeData, |
| 33 | + IDexSwap.SwapData[] memory dstSwapData |
| 34 | + ) external; |
| 35 | +``` |
| 36 | +#### Swap and Bridge |
| 37 | +Suitable for cross-chain transactions, where both swaps and bridging are required. |
| 38 | +```solidity |
| 39 | + function swapAndBridge( |
| 40 | + IStorage.BridgeData memory bridgeData, |
| 41 | + IDexSwap.SwapData[] calldata srcSwapData, |
| 42 | + IDexSwap.SwapData[] memory dstSwapData |
| 43 | + ) external; |
| 44 | +``` |
| 45 | + |
| 46 | + |
| 47 | +## DexSwap contract |
| 48 | + |
| 49 | +Only takes calls from the `Orchestrator` contract which contain an array of swaps that are required to be performed on the current chain. Executes each swap one-by-one on multiple dexes, in order to obtain a destination token. |
| 50 | + |
| 51 | +## Bridging & Settlement |
| 52 | + |
| 53 | +## Chainlink Functions |
| 54 | + |
| 55 | +Serve the purpose of fast-tracking transactions while CCIP is performing the 24-minute bridging. |
| 56 | + |
| 57 | +### SRC Functions |
| 58 | + |
| 59 | +Calls `addUnconfirmedTX()` function on the DST chain to indicate that a transaction has entered CCIP on the source chain. Uses a private key in DON-Hosted secrets in order to call the function via an allow-listed messenger wallet. The DST contract, which receives such call immediately begins the confirmation process by running an additional set of Chainlink Functions on the destination chain. |
| 60 | + |
| 61 | +### DST Functions |
| 62 | + |
| 63 | +The purpose of Destination chain ChainlinkFunctions is to confirm whether the transaction has indeed been submitted to the source chain and has successfully entered CCIP. Using Alchemy, Infura and other RPC providers inside the JS code, it performs an RPC call to read a specific event, which confirms that the transaction is being sent through CCIP. |
| 64 | + |
| 65 | +Additionally, DST functions are responsible for awaiting a certain amount of block confirmations before submitting a successful callback to the DST contract. The minimum of block confirmations depends on the risk factor of each transaction that enters the bridging infrastructure. This itself is a combination of weighted factors such as the amount of transactions, transaction history of the wallet, and any other anomalies that the transaction might have. |
| 66 | + |
| 67 | +## Chainlink CCIP |
| 68 | + |
| 69 | +Chainlink CCIP is chosen as a reliable and secure settlement layer due to its complex multi-layered architecture. As soon as funds enter CCIP on the SRC chain, a corresponding event is emitted and Chainlink Functions begin the acceleration process. When the funds have been taken from the liquidity pool in a form of a 24-minute loan, CCIP rebalances that pool by completing the transaction. |
| 70 | + |
| 71 | +## Liquidity pools |
| 72 | + |
| 73 | +Liquidity pools are a crucial part of Concero's fast-track solution, as they hold the liquidity necessary to be taken as a loan while CCIP is in process of bridging the assets. As soon as the transaction is confirmed by Chainlink Functions on the DST chain, the Orchestrator contract obtains a loan from the Liquidity pool and proceeds to execute all necessary actions, such as destination chain swaps. This is in order to send the destination asset to the user's wallet. |
| 74 | + |
| 75 | +## Orchestrator contract |
| 76 | + |
| 77 | +The Orchestrator contract serves as an operations manager for the entire on-chain system. It's isolating the environment from malicious actors, by exclusively operating each contract in a predetermined order, such that there is no possibility for the end user or any external entity to directly interact with internal contracts of our infrastructure. The Orchestrator provides a single external point of entry for the end user to facilitate cross-chain transactions. |
0 commit comments