43 lines
2.5 KiB
Plaintext
43 lines
2.5 KiB
Plaintext
---
|
|
sidebar_position: 15
|
|
title: Feed Operator
|
|
---
|
|
|
|
This page gives an overview on how to configure and operate a Switchboard feed.
|
|
|
|
## Job Consensus
|
|
|
|
Job consensus refers to how individual oracles calculate their result from a feeds assigned job accounts.
|
|
|
|
**_Job Diversity_**
|
|
|
|
Data feeds should source data from a variety of sources when applicable. A feed relying on a single source is at the mercy of that sources uptime and responsiveness.
|
|
|
|
**_Job Weights_**
|
|
|
|
Data feeds should use job weights to calculate the weighted median, which is what the oracle submits on-chain as its final result. A data source that has the majority of an assets price action should be weighted higher than a dead exchange with questionable volume metrics.
|
|
|
|
## Oracle Consensus
|
|
|
|
Oracle consensus refers to how the final on-chain result is calculated from a batch of oracle responses. A feed's `aggregator.oracleRequestBatchSize` is the number of oracles assigned to a request, while `aggregator.minOracleResults` is the number of responses needed to accept a result.
|
|
|
|
**_Increase oracleRequestBatchSize_**
|
|
|
|
The quickest way to increase feed security is to request more oracles each update round because this requires a higher degree of oracle collusion in order to affect the accepted result. In reality, this increases the overall cost of a feed so its a careful consideration for feed operators when configuring a feed.
|
|
|
|
**_ oracleRequestBatchSize $\neq$ minOracleResults _**
|
|
|
|
The number of oracles assigned to an update request should always be less than the number of oracles required to respond. There are a variety of reasons that may cause an oracle response to fail, such as Solana network degradation, individual oracle network issues, or transaction spamming. Your feed's lease is only deducted when an oracle successfully responds and there is no penalty for an oracle who has timed out.
|
|
|
|
## Feed Maintenance
|
|
|
|
The primary maintenance for a feed is ensuring the lease contract has sufficient funds. The [@switchboard-xyz/lease-observer](https://github.com/switchboard-xyz/switchboard-v2/tree/main/packages/lease-observer) demonstrates how to emit PagerDuty events when a lease is low on funds.
|
|
|
|
:::caution
|
|
|
|
When a data feed's lease contract does not have enough funds, it will be automatically removed from its crank. When extending a feed's lease, make sure to also repush the feed back onto any cranks for updates to continue.
|
|
|
|
:::
|
|
|
|
You should also monitor the feed for staleness in case of downstream changes to a data sources endpoint.
|