Data computation

DIA Lumina employs a flexible and trustless system for processing data into final outputs. After Feeders collect and aggregate data, they're stored in their assigned contract (Pods) on the Lasernet rollup. The final aggregation happens on the meta-contract which collects data from Pods using customizable rules and produces a final value to deliver cross-chain.

Key Components

Lasernet

As the backbone of the system, Lasernet is an optimistic Ethereum Layer-2 rollup. It serves as an open data repository that handles the full lifecycle of data, minimzing trust and supporting full verifiability. The Lasernet chain is built for scalability using the Arbitrum Orbit Stack to handle large oracle transactions at a low cost.

The DIA Lumina oracle consists of two major components:

1. Pods: the collection of key-value smart contract that collect price data from each feeder.

2. Aggregator: a contract that collates these prices from the key-value contracts and provides an automatically refreshed reading of the latest market price.

An exemplary Lumina data flow can be seen here. Feeders scrape trades from exchanges and submit these as last prices into their Pods on Lasernet.

The final aggregation of these values is done through the meta-contract (or the Aggregator). To ensure the accuracy of the final value, the meta-contract uses a threshold to require a minimum number of valid price submissions before considering the data reliable. Additionally, a timeout period in seconds is enforced to discard any outdated price data, so that only fresh and relevant information is used in the final calculation (e.g. 5 data submissions within 1 min).

Data flow from sourcing to final aggregation on Lasernet

Pods

These are smart contracts that securely store on-chain data. They receive regular updates from their assigned Feeders, ensuring that asset prices are accurate and up-to-date. Feeders make price data openly available for all users on the network.

Each decentralized Lumina feeder writes data into its own oracle contract. This feeder contract is a basic key-value store which stores oracle updates accessible by a key, such as BTC/USD. The data stored for each entry is the last price of the asset and the timestamp of that price.

Data Packing

In order to pack the data efficiently, the entries (price and timestamp) are packed into the same uint256 when an update is written to the key-value store.

function setValue(string memory key, uint128 value, uint128 timestamp) 
        public
        onlyRole(UPDATER_ROLE) 
   {
        uint256 cValue = (((uint256)(value)) << 128) + timestamp;
        
        values[key] = cValue;
        
        emit OracleUpdate(key, value, timestamp);
    }

Read Data Updates

You can optionally interact with the individual feeder contracts directly by calling getValue() that returns the latest price update stored for the requested asset.

1. Call getValue(pairName) with pairName being the full pair name such as BTC/USD. The quote asset is always in USD for any asset.

2. The response of the call contains two values:

   • The current asset price in USD with a fix-comma notation of 8 decimals.

   • The UNIX timestamp of the last oracle update.

Aggregator

A smart contract that picks data from multiple Pods and creates a final median value (also referred to as a meta-contract). Multiple Aggregator smart contracts can be deployed, creating a flexible framework for users. Aggregators operate with customizable rulesets (custom sources, aggregation windows, and more), allowing them to cater to different use cases. Aggregators also have the option to benchmark data against external sources for additional security.

The meta-contract exposes a simple Read function called getValue(). It has one parameter pairKey, which consists of the symbol of the queried asset and /USD to denominate its price in US Dollars. For instance, the latest Bitcoin price is queried by calling getValue("BTC/USD").

The function then returns two values:

1. The value of the asset in US Dollars, with 8 decimals.

2. The timestamp of the block with the latest calculation result.

The oracle has several safeguards against becoming stale or having not enough feeders providing updates.

How it works

Price Aggregation Methodology

The current version of the meta-contract supports the median methodology which is calculated by collecting values from all registered Pods (or feeder contracts), filtering out outdated values based on the timeout period, and ensuring a minimum number of valid values (threshold) are available. The remaining valid values are sorted through a Quicksort algorithm, and the middle value is selected as the median.

Later iterations of the meta-contract will allow selecting different methodologies for each price evaluation.

Roles

Each meta-contract has an admin address that can setup the meta-contract for its specific usage. The admin is able to add and remove feeders, set a threshold of required feeders, and set a timeout duration after which a feeder update is considered stale.

Registering Feeders

The meta-contract needs to learn about available Pods in the Distributed Feeder Network. The admin can add as many feeders as they wish to the price evaluation using the addOracle() method. The required parameter of that method is the address of a Pod on Lasernet. After an oracle is added, its latest prices are immediately part of the price evaluation.

Removing Feeders

If needed, oracle feeders can also be removed by the admin. The required parameter of that method is is the address of a feeder contract on Lasernet. Removal is immediate, so any call made to getValue() from the removal block onwards will not include data from the removed feeder any more.

Acceptance Threshold

To make price discovery more robust, a threshold needs to be set by the admin. This threshold corresponds to the number of feeders that need to have submitted a price to reach a valid consensus.

You can find all of the contracts on Lasernet testnet, and oracle testnet deployments here.

Key Benefits

• Full Data Transparency: From data collection, storage and computation, every step in the process is transparent, traceable and verifiable.

• Permissionless Flexibility: Lumina’s modular design allows developers to deploy their own custom Aggregators, offering unmatched flexibility for different data needs. Alternatively, DIA offers the Oracle Builder, a no-code solution for the same purpose.