Identify or setup a fallback price feed

[sajanrajdev]

stETH/wstETH don't have a Tellor (nor any other alternative price feed from CL available on mainnet). Further research into alternatives must be conducted and, if no other safe feed is found, a feed should be developed in collaboration with Tellor. Ideally: wstETH/BTC or stETH/BTC.

[sajanrajdev]

Alternative to Chainlink a few other Oracle Protocols exist that could potentially offer the required price feed. The top contestants are:

• Tellor
• Band
• Api3
• Nest ?

Their decentralization and security profile must be analyzed in order to identify the preferred option.

[sajanrajdev]

Oracle Providers Comparison

Tellor

Technical Overview

• Decentralization ensured through economic incentives (Similar to PoS)
• Prices are proposed and posted permissionessly. Price reporters get compensated with TRB "tips" for it
• Reporters must stake TRB to earn the right to report
• Price consumers must tip the PriceFeed contracts to ensure that the reporters are properly incentivized
• Anybody can lock TRB to dispute any submitted value
• The community votes whether or not to remove the data through governance (meanwhile, another reporter submits data data instead)
• If dispute is successful the disputer takes the Reporter's entire stake
• If dispute is unsuccessful the reporter takes the disputer's dispute locked fee
• Protocols are advised to allow for a certain time buffer >10 min before consuming a freshly posted feed in order to allow for disputes to occur

Integration notes

• Requires the setup and maintenance of "Dripper" to ensure that the feed is always funded with TRB to pay for "tips"
• Smart Contract interaction has already been implemented within PriceFeed.sol

Band

Techincal Overview

• App chain (BandCain) from the Cosmos SDK (PoS)
• Native token BAND
• Node Operators stake BAND (validators) as an economic incentive to report accurate values
• Oracle Data request flow: Data consumers pay a fee to the network. A few staked BandChain validators are chosen randomly (with odds in proportion to their staked amount) to fetch data from the "Oracle script" (predefined sources and aggregating algorithm that all validators use equally). Reports are aggregated and stored on the BandChain state. Once stored, validators sign the accuracy of the data and it can then be relayed to other chains for consumption.
• The process takes 3 to 6 seconds from start to finish.
• As with any other PoS system, the data is confirmed by the rest of the validators before it is finalized and stored on the BandChain. Validators that report or sign inaccurate data are slashed or penalized from their staked BAND amount.
• Currently there are around 72 active validators
• BAND holders can delegate their tokens validating power to validators to increase their stake in return for a portion of the returns. The token is also used to pay for BandChain transaction fees. Additionally, it serves as a governance token for the protocol
• Data Sources (APIs) can also monetize directly on-chain whenever data is fetched from their sources via the oracle scripts

Integration notes

• An Oracle Script will need to be developed and deployed to the BandChain network (tutorial)
• Smart Contract example to consume data within Ethereum Mainnet

[sajanrajdev]

Notes from meeting with Tellor

Recording of meeting: https://drive.google.com/file/d/1NiMmttmxcBXm9hayXOVHp8LluaX4OpJf/view?usp=sharing

• Price feeds must be incentivized via tips of TRB tokens
• Whenever a new price is required to be posted, the reporter will expect a tip in return
• TRB tips should at least cover the gas costs of posting + an additional incentive
• It is recommended to setup an automated service (bot) to monitor the USD gas prices at all times and automatically incentivize feeds appropriately as needed
• An additional bot is recommended to monitor the proposed prices and dispute them if a major discrepancy is detected
• There hasn't been that many cases of disputes and for the most they have been due to wrong prices being posted because of API or scripting errors on the proposer side
• No wrong price has gone undisputed
• Most of time, prices are disputed by the proposers themselves (between them or the same proposer than posted the wrong price)

[sajanrajdev]

Band Protocol engagement

Reached out to Band protocol with regards to certain questions around their infrastructure and integration:

Once the Oracle Script is developed and deployed, how should we make the data request? My understanding is that we should broadcast a MsgRequestData to the BandChain but, if the intention is for this data feed to be updated with a continuous frequency, does that mean that we need to setup a bot to broadcast and pay for this request continuously? Is there a decentralized (or more decentralized) way of handling this? Can it be handled directly from the Ethereum network?

Yes, you will have to set up some bot to request BandChain and relay the result. However, we are working on developing this bot for public use. This bot will relay data along with the proof. So, smart contract itself can verify data through bridge.

What is the average cost per request?

This depends on your oracle script and data sources. You can calculate it roughly by this formula (base_gas + prepare_gas + execute_gas)gas_prices + data_source_fee ask_count. Currently, gas_price is about 0.0025uband. You can also try to request your oracle script in testnet first.

Could you explain a bit better how does the network ensure that no malicious prices are approved?

When you request data in BandChain, you will have to specify ask_count. This value is the number of validators that are required to help get your data by running the data sources. Then, you can add your aggregation logic in oracle script to prevent malicious prices such as median of the price from validators.

[sajanrajdev]

Fall Back Oracles comparison

Notes on API3

• Not very decentralized nor trustless
• They are basically a platform for existing APIs to post data to the chain

Band VS Tellor

A comparison was conducted between the two protocols and a Venn diagram highlighting their pros and cons can be found in the following Miro board.

Recomendation

Based on conversations with both the Band and Tellor teams, an analysis of their architectures and the comparison from above, it is my recommendation to pursue Tellor as the fallback Oracle for the following main reasons:

• Easier integration with full support from their team (they are willing to review our price feed contract to ensure proper integration)
• Cheaper than Band with costs purely on TRB and can be paid only when needed (Can have backup incentives with new ones only added whenever Chainlink begins to fail).
• Has less Web2 dependencies with most of them being more backstop checks rather than actual dependencies:
  • Disputes bot
  • Reporter tipping bot (Can check for Chainlink status and only tip as needed)
• Allows us to become a reporters permissionessly as a fallback for if ever gas prices become too high such as that our holdings of TRB to tip are not enough to compensate. We can always report directly and absorbe the gas cost of posting - we would still be subject to disputes which is a heavily monitored and automated process in which many stakeholders participate.
• Already integrated by more DeFi protocols successfully

[sajanrajdev]

Pursuing Tellor as Fallback Oracle. The following issues were created to track the implementation of the required infrastructure:

• https://github.com/Badger-Finance/ebtc/issues/163
• https://github.com/Badger-Finance/ebtc/issues/267
• https://github.com/Badger-Finance/ebtc/issues/268