User Checklists

Make sure you'e ready to handle live data with Fetch Oracle.

On this page, you'll find two checklists:

• Development: actions for the security of your code and integration.

• Maintenance: actions to help make sure the data flowing into your contracts is properly checked and monitored.

Development Checklist

Communicate What Oracle Data is Needed, the Desired Frequency, and How the Feeds Will Be Funded.

This helps the Fetch community and reporters better understand your needs.

Feel free to ask for help and advice by making an issue in the dataSpecs repo or by reaching out in the Fetch Telegram group.

Review Best Practices.

This repository is a reference implementation for integrating Fetch price feed data into your protocol.

It demonstrates the best practices for using Fetch, including implementing a dispute time buffer and a data staleness check. It also mitigates back-in-time dispute attacks by caching the most recent value and timestamp.

Build in a Delay to Allow Time for Disputes on Bad Data.

A reporter can submit any value at any time if they are willing to forfeit their staked FETCH tokens. By delaying use of a value, or by delaying the finality of functions that use the latest Fetch value, you can prevent the use of inaccurate data.

The best practice for reading Fetch data is to use the_getDataBefore function with a buffer time that allows time for bad values to be disputed:

_getDataBefore(_queryId,block.timestamp - 20 minutes);

This repo is a great reference for integrating Fetch.

Add a Staleness Check.

It's also best practice to require/check that the data is not too old for your use-case. For example:

require(block.timestamp -_timestampRetrieved < 24 hours);

Prevent a "Back-in-Time" Attack.

In the event where a Fetch value is disputed, the disputed value is removed and previous values remain. You can prevent potential attackers from going back in time to find a desired value by including a specific check in your contracts.

Maintenance Checklist

Hold FETCH for Disputes.

This ensures that you are ready to dispute any incorrect values that may occur in the oracle data feed.

Hold FETCH for Staking Reporters (as Insurance).

In the event of a critical situation, this allows you to act as the reporter of last resort for your protocol.

Monitor the Data.

Monitoring clients like the Disputable Values Monitor (DVM) can be found in the Fetch GitHub repos. (Installed by default if you used the install script provided here)

Become Familiar With Telliot.

Telliot is currently the standard open-source tool for reporting and interacting with the Fetch oracle network.

Communicate Questions/Concerns

To address your specific monitoring needs, it is important to communicate any questions or concerns that arise with the Fetch community.

Remember: Communication and careful planning are key to a successful integration!