Inspiration

As software professionals and DeFi researchers, we were inspired by how frontrunning problems can be mitigated using Data Streams. But with strong benefits, drawbacks usually also come. Analysing Data Streams from an event-driven architecture perspective, we understand that there can be some edge cases when the system does not perform as expected. To apply Data Streams for financial products, it should be reliable and have an AWS-like uptime service commitment of 99.95% or even more. Another way to mitigate potential issues is to follow the principle “don’t repeat yourself”. Encapsulating and simplifying Data Stream integration with dApps helps avoid integration bugs, saves development effort and keeps the dApp team focused on business instead of infrastructure.

The mission of Fortis is to decrease the complexity of integration with Data streams & feeds and provide a fallback for the case when there is an outage in their work.

What it does

  • Safe Requests Processing.
    • If Chainlink Data Stream fails to deliver data within a predefined period, anyone can call a fallback method and deliver data collected from Chainlink Data Feeds. Keep the fallback method open, allows smooth and simple integration with Account Abstraction.
  • Simple Integration
    • While Chainlink provides highly customizable low-level API to build custom dApp oracles, Fortis Oracle focuses on reusability and simplicity, while preserving the benefits of Chainlink. To interact with Fortis Oracle, dApp should call the addRequest method and implement the consume method that will be called once price data is available.
  • Pay for what you use.
    • Fortis Oracle charges a fee per request in ETH. The fee can be set by dApp based on total gas usage. It removes the necessity to deal with LINK\ETH conversion on the dApp level. Fortis Oracle uses an arbitrage-based approach to automatically convert collected ETH into LINK tokens and fund itself.

How we built it

First, we analyse how Data Streams can be applicable for DeFi, what challenges developers will need to solve and why. At the end of this exercise, we got a list of use cases we want to cover. We picked the most valuable and designed a solution for them in Miro.

We split our solutions into tasks, prioritised them and started to move to our milestones step by step building a solution and improving it! Initially, we planned to build some kind of SDK or library but realized that we could hide complexity and deliver our solution as a service.

Watching the Chainlink Data Streams on YouTube, we decided to base our demo on the provided trading demo app as we believe that it is a great proof of the Fortis applicability. After smart contracts and UI adjustments and integration with our solution, we got a full end-to-end working solution, ready for presentation.

Challenges we ran into

We started participating in the hackathon a couple of weeks later than kick-off was and combined our hackathon activities with our daily work responsibilities. That means time was one of our biggest constraints as we aimed to present in the end working demo application that covers the entire user journey. Our team has a different level of web3 development expertise, and we will need to spend extra time to align our understanding and vision.

From a technical perspective, it turned out (as always with the code from someone else 😁) that reworking the demo app for our needs was not as simple and easygoing as we initially thought, gmx router is not available on arbitrum sepolia, so we had to reimplement our own simple DEX. But this also was a good point to prove our assumptions about how easily Fortis can be integrated with dApps.

Figuring out how to test our Fortis was another hot topic during our journey. It takes time to register a new Upkeeper and validate the e2e user scenario. We ended up with the necessity to split the codebase, cover it with unit tests and implement a simple proxy with migration script.

Writing unit tests for the verification process and upkeep method was also challenging due to the underlying chainlink Data Streams architecture and code complexity.

Accomplishments that we're proud

  • We’ve managed to implement a fully working solution for the ETH/USD pair
  • as well as end-to-end user scenario demo application
  • implement declarative deployment solutions that allow us to configure deployments in a declarative manner in a hardhat config file and deploy only modified and interdependent contracts.
  • introduce custom hardhat tasks for Fortis Oracle, such as setting registry ID, refund automation, trading emulation and deployment.
  • cover critical areas of our solution with a unit test using a foundry (forge).
  • prepare documentation and architecture diagrams.
  • figured out a way to scale this solution so it will work as a generic solution for various pairs

What we learned

We learned how to work with data streams and chainlink automation and integrate them into solutions. We also improved our skills working with web3 technologies such as solidity, its testing, and tools connecting web2 with web3.

What's next for Fortis Oracle

  • Introduce more features:
    1. Permitted fallback handler for AA and Automation
    2. Request TTL configuration instead of hardcoded value.
    3. Fallback request handling TTL
    4. Gas usage optimisation
    5. Generalize the solution to support a wide list of pairs
    6. New upkeep (oracle) full circle registration automation with smart-contracts
  • Quality:
    1. Detailed documentation
    2. Pass through a smart contract audit to ensure its security
    3. Complete unit and integration test coverage
  • Go to market:
    1. Go public on one L2 network
    2. Marketing and feedback strategy development

Contracts used for demo (arbitrum sepolia):

External Libs:

Dashboard: https://automation.chain.link/arbitrum-sepolia/10925400437096127992739706195823699620042093671699188147436276664757832170914

Built With

Share this project:

Updates