Inspiration

Making the decentralized apps' (especially lending and borrowing apps) and users' liquidity more secure and more liquid in the matter of multiple chains with a secure way of bridging. Also, liquidity abstraction on multiple chains was an inspiration for us.

What it does

We have 2 types of approaches to cross-chain liquidity providing. Firstly, user perspective. We have 2 different main pools one in Avalanche Fuji as a subnet and one in Optimism Sepolia. Independent users can add liquidity to these pools. The pools can be various with different pairs. By adding liquidity, we aim that users can take all their added liquidity to the system can be taken from one chain themselves. We have 3 different dApps that independent users can add liquidity. Those are deployed on Avalanche C-Chain, Polygon Amoy, and Optimism. Users can add liquidity or borrow liquidity through these dApps and can take everything from one chain. We can call this liquidity abstraction. In the second path, which is for dApps, we're doing work that dApps can create their own pool in our system for securing their liquidity. In this thing main idea is, that every dApp needs to create and deploy its own smart contract. If the liquidity is stored in another protocol's pool and when there is a need, dApps' smart contract is just used for triggering the liquidity pool on which dApp stores their liquidity. In this way, the liquidity is more secure and liquidity provided with CCIP is more efficient. In this product, we used CCIP in between our 2 pools on Avalanche Fuji and Optimism Sepolia. Also, in the manner of triggering the liquidity, we used Data Feeds for taking the transactions' submissions with prices', CCIP for cross-chain messaging and asset transfer processes, and Automation for triggering the smart contracts of dApps. We're taking the price of transactions on the lending and borrowing process, so we decided to give the output token as a stable. In this process, we're using CCTP from Circle to provide the output with the token as USDC.

How we built it

We used Solidity language for smart contract development and for the framework we used Foundry most of the time. Our contracts interact with each other first our CCIP contracts get the price of the token from the EthToUsdc contract which uses Chainlink Data Feeds technology and then our sender contract sends a message to the receiver contract. After the at, the sender withdraws his/her money from the receiver contract that we deployed to another network. In this way, we bridge our money. Last but not least, we use Chainlink Automation technology for the dapps to automate the amount of the tokens in our liquidity pools so we don't have to worry about the amount of the tokens in our liquidity pools which is the contracts we deployed before because we're controlling it with automation.

Challenges we ran into

  • Storing the data of transactions without using a centralized database was a problem for us but we achieved this challenge through the power of messaging with CCIP.
  • Triggering the decentralized apps' smart contracts for needed liquidity was a challenge for us but we achieved this challenge with a pre-defined price amount in the decentralized apps' pools.
  • Selecting the chains that we're planning to use was a challenge for us but we found the best path for it.
  • We want to use the Proof of Reserves but we changed our development path because of the complexity.

Accomplishments that we're proud of

  • Right now, we do now how does Chainlink products like CCIP, Data Feeds, and Automation.
  • We can do work with cross-chain products through smart contracts and Chainlink products.
  • Doing complex cross-chain operations with Chainlink products.

What we learned

  • How to do cross-chain lending and borrowing.
  • Storing data without centralized database but on blockchains.
  • How to work with Chainlink products.

What's next for FusionLink

Our aim is our vision's base. What's next is, securing more decentralized applications through cross-chain liquidity and the next option can be auditing the trigger smart contracts with AI. Also, more complex trigger methodology for this trigger smart contracts is a requirement for us. Besides these; adding more pools, adding more chains, and adding more pairs could be a good development process for us.

Built With

Share this project:

Updates