Price Oracles serve as an essential element in the next-generation Stellar Soroban smart contract system, which leverages the Rust programming language. They are widely applied in lending schemes that incorporate approaches like overcollateralized loans. Decentralized systems require a secure and reliable way to access external data, especially when it comes to financial data that impacts decision-making within the applications (1). Since blockchain networks are typically isolated from the outside world, price oracles act as a bridge between off-chain data and on-chain applications, ensuring accurate and trustworthy information for users and developers.

Major oracle disruptions could endanger billions of dollars stored in Soroban-based agreements. Recognizing the focused risks is crucial, as the ever-expanding assortment of projects within the system typically hinges on a few price oracles. A breakdown in even one of these oracles might trigger a catastrophic ripple effect throughout the entire ecosystem. As a result, the seamless integration of dependable and secure price oracles is crucial for the success of Stellar Soroban.

We previously developed LightEcho.io, an aggregator that compiles pricing data from various sources, including Decentralized Exchanges (DEXs), Centralized Exchanges (CEXs), Instant Exchanges (ICE), and Peer-to-Peer (P2P) exchanges. It collects data from over 50 sources. This platform showcases Stellar pricing information.

For this project, we aim to create two distinct types of oracle contracts within the Stellar Soroban ecosystem:

1. An embedded oracle, in which all prices are stored inside the contract data on-chain, and the prices can be obtained at any time by invoking the contract function directly from another contract.
2. A callback-based oracle, in which a price is requested alongside a contract ID for receiving the price later, then a backend aggregator (off-chain) detects the request via getEvents, and invokes the receiver contract, passing the price as a parameter to the function being invoked.

The sources of the prices that are fed into those contracts will be decentralized, meaning there will be multiple sources, each one controlled by a different trusted market data providing, company or exchange. It's on the consumer (of the contracts) to decide which price source to rely on when retrieving a price.

For the centralized pricing systems we will both investigate using the pricing model from CME(6) and use a hybrid model taking the best of Maker Dao and Cornell University's "Town Crier" model(2).

We have successfully completed all work outlined in the previous competition. This is a new project focused on Soroban.

We have already completed a small proof of concept for this smart contract and a web front end for searching all DEXs on Stellar/Soroban https://lightecho.io.

Our design goals for this project encompass the following key aspects:

• Data Accuracy: We prioritize providing users with reliable and precise information, which is vital for informed decision-making.
• Uptime: Ensuring the system remains highly available is essential; offering users uninterrupted access to crucial data.
• Efficiency: Recognizing the inherent limitations of blockchain data storage, we plan to test high demand on-chain data for XLM-USD pricing. We will also test a request-response model, optimizing storage usage while maintaining access to essential information.
• Diversity: The trading environment lacks a single source of truth. By incorporating multiple oracles focused on Emeging markets, users can select a source that aligns with their unique requirements and preferences.
• No Token: We would prefer the system is to function without the need for a specific token for usage or incentives.
• Resistance to Manipulation: To safeguard the integrity of the system, we aim to build robust mechanisms that prevent price manipulation and ensure the authenticity of the data provided,
• Support Stellar's core mission of Remittance to Emerging markets and global financial access

By addressing these design goals, we strive to create a comprehensive, reliable, and user-friendly system.

For our pilot we have taken the developer discussion from Alex and Orbitens and we believe have made it more flexible. .

An overview of our modifications to the structure proposed by Alex and Orbitens(1):

- Base is of type Symbol instead of Address:

fn base(env: Env) -> Symbol;

- Base will always represent an off-chain currency by their ISO-4217 code, e.g. US Dollar is USD, Euro is EUR, Bitcoin is XBT/BTC (10).

- We renamed "price" to "rate", for simplifying the semantic of the values. A rate of 10 means that for 1 unit of the base asset, you get 10 units of the quote asset.

- Each rate entry will have the following structure:

``` pub struct RateEntry {

pub rate: u128, // unsigned 128-bit integer since it's not impossible to have negative rate

pub decimals: u128, // indicates how many decimals the rate has

pub timestamp: u64, // timestamp in UNIX seconds

}

```

- A decimal rate can be derived from RateEntry by using this formula: rate_d = rate / (10^decimals)

- The reason we put the decimals field inside the RateEntry structure (instead of having it as a global value) is due to how rates can be too high or too low in value. In some other cases we might not need so many decimal places to represent a rate. Therefore we chose to keep each RateEntry with its own decimals indicator.

- The source indicates where the rate is coming from. Each source is independent from the other

- A rate can be retrieved by invoking the get_rates() contract function:

fn get_rates(env: Env, asset_code: Symbol, asset_issuer: Option) -> Option>;

- This function is equivalent to the price() function from the structure proposed by Alex and Orbitlens (3), and the difference is that instead of requiring the asset contract address as a parameter, we require the classic Stellar asset code + asset issuer combination. This is to simplify the usage of the contract, as we intend to support primarily the popular assets from classic Stellar like USDC, BTC, etc, in which their issuers are widely known, but their contract IDs in Soroban are yet undefined. The return value is a Map, where each key represents the rate source, and each value contains the RateEntry for that source. Examples of sources: classic Stellar, Binance, Kraken, Coingecko, etc. Each source is represented by an integer, and sources are independently managed in a decentralized way, where specific accounts are authorized to update only a single source or set of sources. Our goal with this is to provide rates coming from many different sources to allow consumers of the contract to be able to choose which sources they trust, and get rates from trusted sources. This get_rate() structure is yet not definitive and is subject to changes.

- Removed assets(), decimals(), resolution(), prices() and lastprice() functions, as we judge them not necessary due to how each RateEntry is independent with it's own decimals and timestamp values, and we won't store more than one entry per rate (the rate will always be the latest), so there's no point having functions that return an array of rates. We might re-add those functions or add other functions with similar purposes depending on the feedback we receive from the community.

- In order to insert or update a rate, we have the set_rate() function.This function requires authorization depending on the value of source. A restricted list of accounts will be able to update rates, and ideally each source can be updated by an independent trusted account.

- In the future we might add a set_rates() function to set many rates at once.

(1) https://groups.google.com/g/stellar-dev/c/KV2XaQzcPPQ

Question 1) What is your first deliverable (~10% of the total project workload)? What steps will you need to take to complete it successfully?

1. Submit a PR to SEP-40 to allow off-chain prices in the Oracle (May 26, 2023):

The Oracle we are developing will provide prices for off-chain assets as well, but the current proposed contract structure (SEP-40) does not support off-chain prices. To complete this deliverable successfully, we need to submit a pull request (PR) to the Stellar Protocol, which includes the necessary changes to enable off-chain prices in Oracle contracts.

The Oracle needs to support data sources from emerging markets, such as BRL, ARS, CLP, and NGN, by providing off-chain conversion rates to USD. This will enable both lending markets and liquidity pools to utilize this information. Furthermore, we intend to introduce a volatility measure for XLM, a crucial element for managing derivatives contracts. It is essential that our data structures are designed to efficiently and effectively accommodate these data sources.

2. Authentication on Oracle (June 15, 2023):

Since the Oracle will contain functions that allow the setting of prices for a given pair, we cannot allow any account to invoke these functions. Otherwise, anyone would be able to change the prices in the Oracle. Therefore, we need to implement an authentication mechanism that includes a set of rules and conditions requiring the contract invoker to be either a contract admin or an authorized account. The deliverable for this step is the initial commit for an authentication system implemented within the contract and deployed to a specific contract address. By the next deliverable this system will be tested using either our Oracle web app (see item 3) or the Python CLI (see item 4).

3. Oracle web app (June 15, 2023):

In Soroban, when a contract is deployed, we can invoke it from JavaScript using Stellar's Soroban JS SDK. To facilitate the interaction with the deployed contract, we have developed an interactive web app that utilizes the Soroban JS SDK. The web app allows us to directly invoke the contract functions. The deliverable for this item is a publicly accessible web app that enables users to retrieve prices from the deployed contract.

4. Python CLI (June 15, 2023):

To input prices into the deployed Oracle contract, we need to fetch the prices from the market and feed them into the contract by invoking an authenticated contract function. For this purpose, we have created a Python CLI script that provides the necessary functionality. The deliverable for this step is a Python CLI script containing commands to fetch prices from the market and feed them into the contract.

How can a reviewer check you completed your first deliverable?

1. Submit a PR to SEP-40 to allow off-chain prices in the Oracle (May 26, 2023):

We have already submitted the PR, and it is currently undergoing discussion and review (by dmkozh). The reviewer can check the PR at the following link: https://github.com/stellar/stellar-protocol/pull/1357

2. Authentication on Oracle (June 15, 2023):

The reviewer can perform the following checks:

- Review the contract source code at https://github.com/bp-ventures/lightecho-stellar-oracle/blob/trunk/oracle-onchain/contract and confirm that initial authentication code required for invocations has been committed (Alpha).

- Within the next two weeks users will be able to invoke the contract to verify if authentication is enforced. This will be done using our web app (item 3), Python CLI (item 4), or by using a Soroban SDK (Beta).

3. Oracle web app (June 15, 2023):

The reviewer can perform the following checks:

- Test the web app by visiting https://bp-ventures.github.io/lightecho-stellar-oracle/.

- Review the web app source code available at https://github.com/bp-ventures/lightecho-stellar-oracle/tree/trunk/docs.

This currently uses the python sdk and a flask to parse the smart contract results but will be migrated to 100% JS in the future when the JS library has been updated.

4. Python CLI (June 15, 2023)

The reviewer can perform the following checks:

- Check the CLI source code at https://github.com/bp-ventures/lightecho-stellar-oracle/tree/trunk/oracle-onchain/cli

- Run the Python CLI by downloading it and running it. Instructions at https://github.com/bp-ventures/lightecho-stellar-oracle/blob/trunk/oracle-onchain/cli/README.md

‍

• https://p.bpventures.us/about/
• https://bp-ventures.github.io/lightecho-stellar-oracle/onchain.html