Ask or search…

Contract Architecture

Oval consists of a series of smart contracts.
The Oval system has been designed to be modular and composable, enabling integrators to build their own combination of source & destination adapters and controllers for their given use case. This should look as simple as how an ERC20 deployer can choose what ERC20 features they want to enable at deployment time by just changing the inheritance pathing for their contracts.
Oval Contracts Overview
The system consists of four main smart contract interfaces that are compiled into a single Oval contract so they can be customized for each protocol. These are as follows:
  1. 1.
    SourceOracleAdapters: These standardize the incoming interface that is ingested by the Oval system. This wraps Chainlink or other custom middleware used to connect to Chainlink.
  2. 2.
    DestinationOracleAdapters: These standardize the output interface that the Oval system exposes. This is the interface that consumers connect to, enabling them to drop in and replace Chainlink (or custom middleware in front of Chainlink) with an Oval adapter without need to change their contracts.
  3. 3.
    IntegrationControllers: Each deployment of the Oval system can add an optional controller that modifies core Oval permissioning, such as who can change configurations. This can be ignored to make the system immutable but can be enabled if continuous configuration is desired.
  4. 4.
    Oval: This is the primary Oval contract that connects to the source adapter, destination adapter and is governed by the Integration controller. It controls which value is returned from the source adapter to the destination adapter, based on when things were updated.
These 4 discrete components are composed together to form one Oval deployment, per integration, with the deployer choosing what configuration they want at deployment time. This means that each integration can be customized depending on the sources and destination they want to combined for their specific use case.