Flux monitor

Price Feeds: FluxMonitor (FM)

The deployment and migration from Runlog to FluxMonitor was a major milestone.

The migration removed the high risks from the Price Feeds' dependence on the Deviator / Utility Node, while also significantly reducing operation costs.

This page will provide information regarding the history, architecture, and operation of FluxMonitor feeds.

Migration to FluxMonitor: ETH / USD

06 Aug 20:  The ETH / USD FluxAggregator.sol contract was deployed at address

• AccessControlledAggregator: 0x00c7A37B03690fb9f41b5C5AF8131735C7275446
• EACAggregatorProxy: 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419

and at transaction hash 0x1697d1bd5ab87a246571186262cf5111cb469b60b9798d70a1fe307d3252c76c

06 Apr 21:  The ETH / USD price feed was formally migrated from Runlog to FluxMonitor contracts.

As Chainlink is extremely risk-averse, they did not want to migrate all of their Price Feed contracts to the new FluxMonitor contracts without a backup plan.

If anything were to happen, the proxy contracts were each pointed at their respective FluxMonitor aggregator contracts.  If anything were to happen, the Chainlink team could fall back to the Runlog contracts in a matter of moments.

 

FluxMonitor Operation

The more noticeable changes from migrating from RunLog to FluxMonitor contracts, were:

• The Deviator / Utility Node was no longer necessary.
  • Monitoring data sources for deviation was pushed out to each Node Operator.
    • If a single Node Operator detected deviation beyond the set threshold, a new round would be fired.
    • The Deviator / Utility Node was no longer a single point of failure.
  • The Deviator / Utility Node no longer sent transactions to each Node Opertor for every price update
    • This resulted in significantly reducing the cost of operating multiple Price Feeds

General Overview of Flux Monitor(FM) (v3) contract operation

(In the explanation below, we will be assuming a standard FM feed with 9 node operators)

Each node operator is assigned three data sources. At a specified pollingInterval, each node will query their assigned data sources. It will then take the median value that is returned from the multiple data sources and provide that value on-chain.

The below diagram illustrates a single Node Operator querying three data sources (CoinGecko, CoinMarketCap, and Nomics) for the price of ETH / USD. The node then calculates the median of the values.

Once a node has detected a price change that is greater than the deviationThreshold (deviation threshold is the minimum percentage change that a node operator must see in order to fire off a new round), it will respond on-chain to provide the new value to the FM contract.

This update will result in a new round request, a new submission, and a call to update the aggregator contract's available funds. As illustrated in the image below, Nop00 has seen a price deviation greater than the deviation threshold, so it is writing to the FluxMonitor contract

In the image below, you can see the first response to a round, as it appears in Etherscan

Once the new round has been initiated, the other eight node operators will receive the request for an updated price.

Once the minimum number of nodes necessary to reach consensus have responded, each of them will update the aggregate value (AnswerUpdated event).

Every node that responds after consensus has been reached, will also call the updateRoundAnswer function to include their value in the aggregate.

As you can see in the image below, the response on the top not only submitted a response and update the available funds, but it also performed AnswerUpdate.

See FluxAggregator contract for how NewRound, AnswerUpdated, SubmissionReceived, AvailableFundsUpdated events are emitted as a result of calls.

Summary of Contract Calls for Each FM Node:

Nop00:

NewRound

SubmissionReceived

AvailableFundsUpdated

Nop01:

SubmissionReceived

AvailableFundsUpdated

Nop02:

SubmissionReceived

AvailableFundsUpdated

Nop03:

SubmissionReceived

AvailableFundsUpdated

Nop04:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop05:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop06:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop07:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Nop08:

SubmissionReceived

AvailableFundsUpdated

AnswerUpdated

Price Feeds: Limitations of FluxMonitor

Issues with Scaling

While FluxMonitor provided a major increase in efficiency over the previous generation Runlog contracts, it was not efficient enough to accommodate for the increasing number of transactions on the Ethereum network.

With the rapid adoption of DeFi in the summer of 2021, the blocks were filling up rapidly and the efficiency of FluxMonitor was not enough to keep up.

Each new round, for each Price Feed still required on-chain transactions from each Node Operator.  This meant that at times of high market volatility, each Price Feed was adding 9+ transactions to the mempool for each Price Feed.

As new DeFi protocols launched with a desire to support new tokens, more price feeds were needed.  FluxMonitor was not enough to meet the demand that Chainlink was experiencing.

If only there were a way to reach consensus off-chain, without risk to the security of the Price Feeds. Offchain reporting.

Flux Monitor resources

XXTEXTXX

---

Timeline

Date	Media	Author	Title
XXXX	XXXX	XXXX	[]
XXXX	XXXX	XXXX	[]

Educational

Date	Media	Author	Title
N/A	Official Docs	Chainlink	Flux Monitor Jobs - Official Chainlink Documentation
XXXX	XXXX	XXXX	[]
XXXX	XXXX	XXXX	[]
XXXX	XXXX	XXXX	[]

‎