If you want to learn how to deploy a data request contract and interact with the Flux Oracle here is what you need to know. If you want your data to be backed by a decentralized group of validators putting their own money on the line. This is going to be the most useful for the following cases:
In the document section, there is more information on the Flux Oracle and data requestor link
Although you should already be comfortable with using the command line, shell commands, have some experience with crypto wallets and cryptocurrencies in general, it also helps have some experience in rust code but it’s not required for this case.
Note that this is a testnet version and will not be directly representative of how the mainnet version will function. In order to make testing easily accessible request, your contracts will not be whitelisted in the testnet version.
If you haven’t already deployed a smart contract on Near and you do not have rust the near wallet you can follow the tutorial of how to set it up from scratch.
Once we’ve set up everything for the request contract it’s time to download it from the GitHub link. Follow the link and click the green code button to download the zip version of the requester sample contract.
Unzip it and place it in a directory of your choosing. Once it’s done we’ve got the contract let’s build it. The Flux team has provided a set of scripts to make it easy to compile deploy and make requests to the contracts so you can start running the build script located at the top level of the repo.
Once everything has been compiled and the wasm file has been made we are ready to deploy.
If you run the deploy requester script with your account id, it will first set up your testnet account with our wrapped near token contract and the oracle contract.
It’ll convert your testnet Near into wrapped near to be able to use the oracle and it’ll deploy your request contract on the Near testnet with your account.
Now that your contract is set up and running on the testnet it’s time to fire up your first data request.
It takes two arguments amount and payload amount represents the validity bond amount (how many tokens the requester needs to post in order for their request to be accepted by the Oracle).
The second one is the payload (the mean of the request, that contains all the data needed for the request to be processed by Oracle and to be answered by the Validator)
The new data request args in the lib file shows all of the required and optional fields that needs to be added to the payload:
sources: for api DR types, can be left as “[]” if arbitrator DR type
tags: (optional) for searching DR types
description: (optional) human-readable question for the arbitrator type, details
outcomes: (optional) for providing multiple choices for predefining outcomes of DR
challenge_period: milliseconds, duration validators can challenge top outcome
data_type: type of data DR outcome: String or Number
creator: creator of DR
Once you are done with the setup, this will result in creating your first Data Request. In order to check your Data Request, you will need to open the Oracle explorer to find all the requests that have been made to the Oracle.
You should be able to find your request at the top:
That’s it for now! Next time we will learn how to check the answers provided and how the read the outcome when it has been reached by the Validator.
As usual, please check Flux resources for more details:
