> For the complete documentation index, see [llms.txt](https://docs.fetchoracle.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fetchoracle.com/getting-data/user-checklists.md).

# User Checklists

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 <a href="#development-checklist" id="development-checklist"></a>

<details>

<summary><strong>Communicate What Oracle Data is Needed, the Desired Frequency, and How the Feeds Will Be Funded.</strong></summary>

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](https://github.com/fetchoracle/dataSpecs) or by reaching out in the [Fetch Telegram group](https://t.me/fetchoracle).

</details>

<details>

<summary>Review Best Practices.</summary>

[This repository](https://github.com/fetchoracle/sampleUsingFetch) is a reference implementation for integrating Fetch price feed data into your protocol.&#x20;

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.

</details>

<details>

<summary><strong>Build in a Delay to Allow Time for Disputes on Bad Data.</strong></summary>

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`**`);`&#x20;

[This repo](https://github.com/fetchoracle/sampleUsingFetch) is a great reference for integrating Fetch.

</details>

<details>

<summary>Add a Staleness Check.</summary>

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`**`);`

</details>

<details>

<summary><strong>Prevent a "Back-in-Time" Attack.</strong></summary>

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.

</details>

### Maintenance Checklist <a href="#maintenance-checklist" id="maintenance-checklist"></a>

<details>

<summary><strong>Hold FETCH for Disputes.</strong></summary>

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

</details>

<details>

<summary><strong>Hold FETCH for Staking Reporters (as Insurance).</strong></summary>

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

</details>

<details>

<summary><strong>Monitor the Data.</strong></summary>

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](https://app.gitbook.com/o/L4kKvU7jlEjab8TB9Lag/s/uaWlV2rnUpdykVKTSfXx/~/changes/80/reporting-data/installing-telliot))

</details>

<details>

<summary><strong>Become Familiar With Telliot.</strong></summary>

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

</details>

<details>

<summary><strong>Communicate Questions/Concerns</strong></summary>

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

</details>

{% hint style="info" %}
**Remember:** Communication and careful planning are key to a successful integration!
{% endhint %}