Flux docs
Requester Contracts
Overview, requirements, and structure
Request contracts are added to the protocol via proposals to join the Requester Registry (RR) -- a whitelist of the contracts that are allowed to make data requests, curated by the Flux DAO (i.e. a Token Curated Registry). An amount of FLX must be included in a proposal to join the RR, and FLX holders are responsible for approving or rejecting the proposal to include the Request Contract after all requirements are met and the contract's code is audited.


  • Open-source: The source code must be made publicly available with a license that allows modification and redistribution.
  • Timelock for upgradable contracts: smart contracts with upgradable code must possess a verifiable timelock mechanism for contract updates to ensure a grace period between upgrades. The timelock must also be sufficient enough to enable the Flux DAO to propose and vote on removing the contract should the contract upgrade be detrimental to the health of the network.
  • Auditable TVS: The oracle must be able to audit the TVS of the contract in real-time to calculate data request fees that fluctuate due to market dynamics.
Entries to the RR are structured and proposed to the Flux DAO as follows:
contract_name: String,
contract_entry: String,
custom_fee: CustomFeeStakeArgs
code_base_url: String
Where CustomFeeStakeArgs is an enum structured as:
enum CustomFeeStakeArgs {
contract_name: The proposed name of the requester contract.
contract_entry: The NEAR account ID of the proposed requester contract.
custom_fee: The custom fee configuration for the requester contract -- usually set to None.
code_base_url: The URL of the requester contract's source code.
Export as PDF
Copy link