Oracle Accountability Fault Detection (OAFD)

Autonity’s Oracle Accountability Fault Detection model – reporting mechanism, temporal constraints, and economics for reporting offences and penalties for failures while participating in oracle voting rounds.

Overview

This section describes the Autonity Oracle Accountability Fault Detection protocol. It covers the role of the validator oracle network in fetching and submitting price data to the Oracle protocol contract on-chain for computation of median price data on chain by the Autonity oracle protocol, and the incentives and disincentives applied to consensus committee validators to incentivise accurate and timely price reporting by validators and their oracle servers.

Autonity implements an Oracle Accountability Fault Detection (OAFD) protocol for detecting if consensus committee members are participating in the Autonity oracle protocol in a timely manner.

Autonity provides consensus-computed median price data for a designated set of currency pair (AKA symbols) as an L1 platform feature for primary and secondary consumer use cases. The primary consumer of the data is the Auton Stabilisation Mechanism (ASM), which uses the currency pairs as the FX currency basket in the ACU index. Also, Autonity NTN and ATN protocol assets price data are used for ATN borrowing against NTN collateral by its CDP mechanism. The secondary consumer of the data is the use cases deployed on the Autonity L1.

A median price for the supported currency pair symbols is computed according to the Autonity oracle protocol.

The oracle protocol functions by a continuous cycle of discrete oracle voting rounds in which raw price data for each of the supported symbols is collected from external off-chain data sources and submitted to an Oracle Protocol Contract on-chain by consensus committee members. An aggregated median price for each currency pair symbol is then consensus computed resulting in a price feed cyclically refreshed at voting round intervals.

Provision of the raw price data is a validator responsibility and only validators that are consensus committee members participate in the oracle protocol. Each registered validator node operates an Autonity Oracle Server (AOS) as adjunct software to the Autonity main client (AGC) software. Validator operators configure their oracle server to collect price data from external data sources for each currency pair symbol the oracle protocol supports. This forms a logical validator oracle network responsible for reporting price data in cyclical voting rounds.

For each voting round the validator node retrieves raw price data from its connected oracle server and submits a price report to the Oracle contract on-chain. The Oracle contract aggregates the submitted price reports to compute an aggregated median price for each supported currency pair symbol. That aggregated median price data is then emitted each voting round as round data on-chain. The duration of a voting round is measured in blocks and set as the vote period parameter of the Oracle protocol configuration. If a validator does not submit a price for a symbol in a voting round, then its last submitted price for that symbol will be used instead.

To ensure the maximum accuracy of price reporting committee members should be submitting current (i.e. “fresh” and not out-of-date “stale” prices) and participating in each oracle voting round. OAFD detects failures to do this as an accountable fault and applies penalties to validators for these faults. For example:

Fault	Description	Scenario
voting fault	failing to submit a price report i.e. ’vote in an oracle voting round	“Missing a voting round”. The cause could be Byzantine (e.g. intentional failure to send), a technical accident (e.g. network glitch, vote arrives too late for the round)
inaccurate price reporting fault	submitting a price report that is considered inaccurate	An “outlier” price report falling outside tolerance of the median price reported by the oracle network as a whole. The cause could be Byzantine (e.g. attempt to manipulate the price) or technical accident (e.g. poor quality data source results in submission of “stale” out of date price data).
incomplete price reporting fault	submitting a price report with prices for some but not all of the supported symbols	The cause could be technical - e.g. the oracle could not source with confidence a price for a symbol for that voting round so opted not to submit one. In this scenario, the oracle’s last submitted price for the symbol would be used by the oracle protocol .

The OAFD protocol is based upon the processing of price reports submitted by committee members to the Oracle contract each voting round, and functions to maximise the currency and accuracy properties of the submitted price data:

• currency: the price data is the latest available for the voting round and is not “stale” and out of date
• accuracy: data reported by individual oracles varies within an acceptable tolerance range. I.e. price “outliers” outside that range are accounted for and so not allowed to “skew” computation of the final aggregated median price.

OAFD focuses on the risk from outliers, which addresses both currency and accuracy properties. This makes intuitive sense: the more current a price is, the less likely it is to be an outlier.

Oracles submit price reports with a confidence score for each symbol price reported that represents the reporting validator’s level of trust in the accuracy of the price data it is submitting. If a reporting validator fails to submit a price report for a symbol or symbols in a voting round, then its last submitted price for the symbol(s) will be taken as the validator’s submission for that voting round.

What if that last submitted price was an outlier?

If a validator oracle does not submit a price for a symbol in a voting round, then the oracle’s last submitted price for that symbol will be carried forward and used as the submission for the current round.

The only exception to this is if the last submitted price was detected as an outlier. In this case no votes for any symbols from that oracle will be included in the final price calculation for the voting round. I.e. the validator oracle’s entire price report for the round is ignored. Accordingly, the validator is punished by the opportunity cost of earning no incentive rewards for that round.

Note that this also addresses the price “freshness” i.e. the currency property of price data, and incentivises timely price reporting in voting rounds. If the last submitted price is not get detected as an outlier, then there is no punishment for not submitting a new price. However, the last submitted price will become “stale” and eventually become an outlier as the market moves. Therefore, oracles that are not providing timely prices will ultimately be punished as well.

OAFD detects outliers by a threshold mechanism. A configured outlier detection threshold sets the percentage range that a reported price can differ from a given median price. The median price is computed by creating a sorted index of all reported prices for a currency pair symbol and finding the mid index. The median price is then compared against for outlier detection. If the submitted price for a symbol is determined to be an outlier, then it is excluded from the final price calculation computing the aggregated median price for that symbol.

The confidence score is further used as a weight to influence the OAFD economic incentives and disincentives for price reporting.

OAFD applies an NTN stake slashing penalty to reporting validators determined to have submitted outlier price(s). OAFD makes use of a threshold mechanism to determine if slashing is applied. The maximum slashing amount is capped by the protocol configuration.

The size of the penalty is proportional to the confidence score submitted with the price report for a symbol: the higher the confidence score, the higher the penalty.

Oracle voting incentives are similarly influenced by the confidence score. Each reporting validator is assigned an epoch performance score. This is a summation of the confidence scores for each symbol price they have submitted in an epoch that has been included in the final price calculations for symbols in voting rounds during the epoch. (The epoch performance score naturally excludes any outliers submitted during the epoch.)

Oracle accountability prerequisites

To participate in OAFD a validator must be a consensus committee member.

Oracle Accountability Fault Detection protocol

OAFD roles, core concepts, and the lifecycle of omission accountability processing from detection to applying penalties at epoch end.

Roles

As a consensus committee member the validator may play the roles in the table beneath during OAFD processing.

Role	Description
committee member	as a validator in the consensus committee executing Autonity’s consensus protocol. For OAFD submitting and validating oracle price reports, maintaining system state for epoch performance scores, and computing and applying slashing penalties
reporting validator	as a committee member operating an oracle server and submitting valid oracle price reports for symbol(s) to the Oracle contract on-chain to participate in oracle protocol voting rounds
offending validator	as a committee member that OAFD has detected as submitting an outlier price report for symbol(s) in an epoch and the object of slashing penalties

The economic impact of the OAFD protocol on a validator depends on their role.

Role	Economic impact
offending validator	loss of oracle rewards, validator reputation, slash staking for self-bonded stake slashed per Autonity’s Penalty-Absorbing Stake (PAS) model
reporting validator	gain of OAFD oracle rewards for submitting valid price reports for symbol(s)

The Autonity community is also a beneficiary of OAFD processing. Slashed stake token will be used for community funds.

Protocol primitives

Essential primitives of OAFD are: oracle price report, confidence score, outlier detection threshold, epoch performance score.

Price report

The price report is the raw price data input sourced off-chain and used to compute an aggregated median price for each supported currency pair symbol on-chain by the Autonity Oracle Protocol.

The price report is generated by consensus committee members, i.e. validator nodes in the current consensus committee.

Raw price data is collected from external data providers by oracle servers connected to consensus committee validator nodes.

The oracle server generates a price report:

• performing an off-chain data aggregation to compute a median price for each currency pair symbol it has sourced (i.e. allowing for the scenario of sourcing price data for an individual symbol from multiple sources).
• assigning a confidence score rating to its price for a symbol
• generating a price report containing the price data for all currency pair symbols it has sourced.

The price report is then taken by the connected validator node and submitted to the Oracle protocol contract on-chain for computation of an aggregated median price for each symbol. The gas cost for submitting the price report transaction on-chain is reimbursed by the Autonity network.

The aggregated median price is continually refreshed in a cycle of voting rounds. Each voting round the newly computed price is emitted on-chain and recorded in system state as round data.

Outlier

An outlier is a price for a currency pair symbol submitted in a voting round that is found to be outside the acceptable % range of variance from the median index value of all other prices submitted for that symbol in the voting round.

See protocol primitives price report and thresholds.

Confidence score

The confidence score represents a validator oracle’s level of trust in the accuracy of the data it is submitting for a currency pair symbol in a price report.

For each currency pair symbol in the price report submission there will be a separate confidence score.

See Confidence score calculation.

Epoch performance score

The epoch performance score is the sum of the confidence scores for valid prices submitted by a validator in an epoch.

This confidence summation accounts only for the \(w_{i,j}\) values that contributed to the price calculations during the past epoch, excluding outliers but including any past submissions if they are being re-used.

See Epoch performance score calculation.

See Confidence score calculation for \(w_{i,j}\).

Thresholds

The threshold sets a floor which if broken triggers oracle accountability penalties. OAFD has outlier thresholds:

• The outlier detection threshold how far from the median price a report for a symbol can be before it is flagges as an outlier.
• The outlier slashing threshold how far from the median price a report for a symbol needs to be before the reporting validator gets slashed. For example, if a price reported satisfies the inequality ((price - median)/median)^2 > outlierSlashingThreshold, then it’s eligible for slashing.

See protocol primitive outlier.

Protocol configuration

Protocol parameters

OAFD protocol parameters are set by default to:

Protocol parameter	Description	Value
OutlierDetectionThreshold	defines the threshold for flagging outliers	10 (10%)
OutlierSlashingThreshold	defines the threshold for slashing penalties, controlling the sensitivity of the penalty model	225 (15%)
BaseSlashingRate	defines the base slashing rate for penalizing outliers	10 (0.1%)
OracleRewardRate	defines the percentage of epoch ATN staking and NTN inflation rewards allocated for Oracle voting incentivisation	1000 (10%)
ORACLE_SLASHING_RATE_CAP	the maximum amount of stake that can be slashed for oracle accountability	1_000 (10%)

Confidence score calculation

The confidence score is computed and assigned to price data by the validator according to the validator’s trust in the quality of the data they are submitting to the oracle protocol on-chain.

Formally, for each reporting validator \(j\) and each price \(i\), the submission of a reported price \(p_{i,j}\) should come with a confidence score \(w_{i,j}\) such that \(0<w_i \leq 100\).

The management and the assignment of the confidence score value is not prescribed and is left to the reporting validator’s Oracle Server implementation. For example, it could be manually set in a configuration file or automatically adjusted based on factors such as:

• the number of data sources used to calculate the submitted price.
• the calculated variance of prices from various publishers (e.g. a higher variance could reduce confidence, while lower variance would increase it).

Outlier detection calculation

An outlier is a price determined to be outside an acceptable % range from the median index value of all prices submitted for that symbol in a voting round.

Outliers are detected by means of an outlier detection threshold configuration parameter ( \(O_t\) ) the value of which is in the range \((0,100)\).

If \(m_i\) the median value of all prices submitted by reporting validators \(p_{j,i}\) for a specific symbol price \(p\), then a price submission is deemed as outlier if it satisfies the condition:

\[ \mid p_{j,i}/m_i - 1 \mid > O_t/100 \]

Detected outliers are excluded from the set of prices used to compute the aggregated median price for the symbol by the final price calculation.

Slashing amount calculation

The slashing amount is calculated by the formula:

\[ max(0, ( \frac{p_{j,i} - m_i}{m_i} )^2 - S_t ) * w_i*R \]

Where,

• \(p_{j,i}\) means the reported price \(p\) for each reporting validator \(j\) and each price \(i\).
• \(m_i\) means the median value of all prices \(p\) submitted by all reporting validators for a specific symbol.
• \(S_t\) means the OutlierSlashingThreshold, which defines the threshold for slashing penalties and controls the sensitivity of the penalty model. Setting the threshold to \(0\) would mean that any detected outlier would be penalized.
• \(w_i\) means the confidence score \(w\) price for each reported price \(i\).
• \(R\) means the BaseSlashingRate, which defines the % of bonded stake that will be slashed to penalise outliers.

The NTN slashing penalty is applied proportionally to the confidence score provided for the outlier, discouraging inaccurate submissions with high confidence. To prevent excessively harsh penalties, the maximum slashing rate for a single penalty is capped by the ORACLE_SLASHING_RATE_CAP.

Final price calculation

The final price \(P_i\) is calculated as a weighted average of the submitted prices excluding any detected outliers.

The aggregated median price is calculated by the formula:

\[ P_i=\frac{\sum_j{w_{j,i}p_{j,i}}}{\sum_j{w_{j,i}}} \]

Where,

• \(P_i\) means the final price for a symbol, calculated as the median value of all non-outlier prices \(p\) submitted by reporting validators and weighted by confidence score.
• \(w_j,i\) means the confidence score \(w\) for a reported price for each reporting validator \(j\) and each price \(i\).
• \(p_j,i\) means the reported price \(p\) for a symbol for each reporting validator \(j\) and each price \(i\).

In the edge case where no price reports have been submitted in the current voting round, the aggregated price of the past round is re-used as the current round price.

Epoch performance score calculation

Each reporting validator \(v\) is assigned an epoch performance score that is a summation of the confidence scores for the price reports submitted by \(v\) in an epoch.

The epoch performance score amount is calculated by the formula:

\[ P_v = \sum_{i,j}{w_{i,j}} \]

Where,

• \(P_v\) means the epoch performance score of the validator \(v\)
• \({i,j}\) means the index of summation, i.e. each price \(i\) submitted by each validator \(j\).
• \(w_i,j\) means the confidence score \(w\) for each reporting validator \(j\) and each reported price \(i\).

This confidence summation accounts only for the \(w_{i,j}\) values that contributed to the price calculations during the past epoch, excluding outliers, but including any past submissions if they are being re-used.

Oracle reward calculation

The oracle reward for a validator is a percentage of the ATN staking rewards and NTN inflation rewards earned by stake delegated to a validator for an epoch. The reward originates from ATN staking rewards earned on transactions processed during the epoch, and NTN inflation rewards earned from the Newton inflation mechanism for delegated stake. The amount is dependent upon:

• transactions processed in the epoch: how many transactions were processed and committed to blocks during the epoch
• total stake bonded in the epoch: the total amount of stake delegated to all validators during the epoch
• oracle performance in the epoch: the epoch performance score of an oracle and how accurately the oracle has been reporting prices. See Epoch performance score calculation.

The reward amount is then calculated based on the validator’s epoch performance score for an epoch and the OracleRewardRate configuration parameter. The reward is deducted from the rewards before they are distributed to stake delegation.

The oracle reward amount is calculated by the formula:

\[ B_v = \frac{P_v}{ \sum_j{P_j}} * \text{ORACLE\_REWARD\_RATE} * \text{TOTAL\_EPOCH\_REWARD} \]

Where,

• \(B_v\) means the oracle reward for validator \(v\) in an epoch.
• \(P_v\) means the epoch performance score for the validator \(v\) in an epoch.
• \({\sum_j{P_j}}\) means the summation of the epoch performance score for each validator \(j\) in the epoch.
• \(\text{ORACLE\_REWARD\_RATE}\) means the OracleRewardRate, the % of TOTAL\_EPOCH\_REWARDs that is deducted and allocated for Oracle voting incentivisation.
• \(\text{TOTAL\_EPOCH\_REWARD}\) means the total amount of ATN staking rewards and NTN inflation rewards earned during an epoch.

A note on total rewards and an analogy

The oracle rewards are a portion of the total rewards earned during the epoch - from transaction fees and from Newton inflation. This reward amount is then distributed to the validators in the consensus committee, each validator’s final reward amount influenced by their own oracle reporting performance.

On distributing the rewards:

• a big slice gets redistributed based on stake-based logic
• a small slice gets redistributed based on omission accountability performance
• a small slice gets redistributed based on oracle performance

OAFD economics

There are two aspects to Oracle Accountability Fault Detection economics: outlier penalties for offending validators and oracle rewards for honest validators.

Role	Economic impact
offending validator	loss of oracle rewards, validator reputation, slash staking for detected outliers per Autonity’s Penalty-Absorbing Stake (PAS) model
reporting validator	gain of OAFD oracle rewards for submitting valid price reports for symbol(s)

Outlier penalties

The economic loss to consensus committee members and their delegators from reporting outlier prices covers stake slashing, and per the PAS model potential loss of staking rewards due to PAS slashing self-bonded stake in first priority.

Economic loss	Receiving account	Distribution	Description
Loss of current epoch oracle rewards	n/a	epoch end	The offending validator loses the opportunity to earn oracle rewards for prices flagged as outliers. Oracles earn oracle rewards for reported prices included in the Final price calculation. Outlier prices are excluded from that calculation and from the oracle’s epoch performance score, which influences the amount of the validator’s oracle rewards. See Epoch performance score calculation and Oracle reward calculation.
Slashing of stake token	Autonity Protocol treasury account	epoch end	The offending validator’s bonded stake is slashed for the oracle outlier penalty amount. Slashing is applied at epoch end according to the protocol’s Penalty-Absorbing Stake (PAS) model. Amount determined by the Slashing amount calculation.

Rewards

Economic rewards are provided to reporting validators as an economic incentive to submit prices in an epoch.

Oracle rewards comprise ATN and NTN: ATN staking rewards from transaction fees, and NTN inflation rewards from the Newton inflation mechanism.

The reward amount is influenced by the accuracy and confidence of prices reported by the validator’s oracle in the epoch.

Economic gain	Receiving account	Distribution	Description
oracle rewards	treasury account	epoch end	The ATN staking rewards and NTN inflation rewards earned for price reporting by the validator for the epoch. ATN is transferred to the validator’s treasury account and NTN inflation rewards are auto-bonded to the validator’s treasury account becoming self-bonded stake. Amount determined by the Oracle reward calculation formula.