🔄Protocol
Last updated
Last updated
Phase One: deploying single-chain aggregator contracts on each blockchain to aggregate DEX liquidity on every major blockchain
Phase Two: Multi-chain contract communication interactions via trustless bridge solutions using Connext, Hop (for EVM-compatible chains), Rainbow, Snowfork, Wormhole and many more.
The first phase of Swing is to deploy aggregators to all the major blockchains including Ethereum Layer 1, Ethereum Layer 2s (Arbitrum, Optimism), Polygon, BSC, Avalanche, xDAI, Heco, Fantom, etc.
Swing will work with multiple bridges for cross-chain swaps. A minimum criteria is that it is trust-minimized and a generalized solution for multiple EVM chains.
The above is an example flow of how a cross-chain swap works with one example of a bridge we aggregate across.
The user sends a request to Swing's backend in order to get an expected return from liquidity pools on the same chain and cross-chain. To better demonstrate the process, we assume the user starts from Ethereum and he/she gets a better price from the liquidity pool on Polygon. Once he/she approves the token and triggers swap through Swing frontend, Swing frontend will send a POST request to Swing backend, which connects to our bridge operator. It will trigger the following steps within the bridge:
1. After the bridge router receives requests from Swing backend, it will respond with sealed bids containing commitments to fulfilling the transaction within a certain time and price range.
2. Swing sends a transaction to the bridge's TransactionManager on Ethereum which locks up funds on Ethereum.
3. The bridge router locks up a corresponding amount of liquidity on Polygon.
4. Swing signs a message and sends it to a relayer on Ethereum. The bridge's relayer (which is typically another router) then submits the message to complete the transaction on Polygon and claim the funds locked by the initial router.
5. The relayer will send a request to the contract deployed on Polygon by Swing with the corresponding calldata.
After the bridge triggers the contract deployed on Polygon, it will swap tokens on Polygon based on the path (which is included in the calldata) and deposit the destination token to the user's address (which is the same as their input address) on Polygon.
